Comment développer un modèle d'objet API public dans une application de bureau WPF permettant une automatisation hors processus à partir d'une autre application de bureau .NET

Question

Nous développons une grande application de bureau à l'aide de Windows Presentation Foundation. Actuellement, l'application est destinée à un usage interne mais sera éventuellement vendue comme un produit commercial. J'utilise actuellement une variante du modèle de conception M-V-VM pour garder autant de code hors des composants de l'interface utilisateur (c'est-à-dire les fenêtres, les contrôles utilisateur). Je sais qu'à un moment donné, nous allons vouloir exposer une API publique pour permettre aux clients d'étendre l'application, et peut-être même automatiser l'application hors processus en utilisant l'API publique d'une autre application .NET. Je n'ai pas beaucoup d'expérience dans la conception d'une API publique pour une application de bureau, donc je cherche des informations sur les meilleures pratiques.

Voici quelques questions que j'ai actuellement:

1) Comment puis-je concevoir l'application WPF pour pouvoir être automatisé hors processus d'une autre application .NET en cours d'exécution dans son propre processus? Par exemple, disons qu'un client a une application console en cours d'exécution et qu'il souhaite automatiser l'ouverture de l'application WPF, puis ouvrir une fenêtre spécifique dans l'application WPF. Je ne suis pas sûr de comment cela peut être accompli. Si une application de console est en cours d'exécution et que j'essaie de créer une nouvelle instance de mon application WPF via le code, l'erreur suivante s'affiche: "Impossible de créer plusieurs instances System.Windows.Application dans le même AppDomain". Je comprends que cette erreur se produit car l'application console ne permettra pas à l'application WPF de démarrer dans son AppDomain actuel, mais ce que je veux vraiment, c'est que l'application WPF s'exécute dans son propre processus pendant que l'application console .NET la contrôle via l'API publique .

2) Je comprends que ce que je demande est quelque peu similaire à l'automatisation Excel qui utilise COM + pour permettre à Excel de fonctionner hors processus. Cependant, Excel est écrit en code non managé et notre application WPF est évidemment 100% du code managé. Aurais-je vraiment besoin de recourir à COM + pour permettre à une application de bureau WPF d'être contrôlée hors processus via un modèle d'objet API public à partir d'une autre application .NET?

3) Si je veux autoriser l'automatisation de mon application via une API publique, devrais-je examiner le .NET Remoting? Ou, est .NET Remoting considéré comme obsolète?

4) Je comprends bien comment autoriser l'utilisation de compléments dynamiques chargés au moment de l'exécution. Cependant, je dois toujours avoir une API publique que le code dans les compléments peut utiliser pour manipuler l'application WPF. Quelles sont les bonnes ressources sur la conception d'API pour les applications de bureau?

J'apprécie toute réaction. Il a été très difficile de trouver des informations sur le développement d'une application de bureau .NET avec une API publique qui permet l'automatisation à partir d'une autre application .NET.

Merci, Chris.

Answer 1

Oui, le modèle Office Automation est toujours le moyen dominant d'implémenter l'automatisation hors processus. Surtout parce que presque n'importe quelle langue le supporte. Il n'est pas si facile à implémenter dans .NET, il ne supporte pas l'activation COM hors-processus. Lancez reading here pour savoir comment le faire avec COM +. Oui, Remoting fonctionnerait certainement aussi si votre client est une application .NET. Ce n'est pas exactement obsolète mais il a été effectivement remplacé par WCF.