J'ai une demande (a) qui doit lancer une autre application (B). J'ai besoin de transmettre des données entre les applications. Je peux penser à deux approches. Le premier est d'ouvrir une prise. La seconde consiste à partager des données via une DLL.
L'approche d'ouverture de la prise est simple.
L'approche DLL J'ai quelques questions? Je peux charger des dlls enfichables dans B. Je souhaite créer une DLL que A peut utiliser pour réussir les données à B. Lors du chargement de DLL, est une seule instance de la DLL chargée? Si tel est le cas, cela signifie-t-il que des données peuvent être partagées entre les applications qui chargent la DLL?
Quel est le meilleur choix?
Y a-t-il d'autres façons de faire cela?
6 Réponses :
Vous ne pouvez pas partager efficacement aux données via une DLL. Autres façons:
Quelle est la question du partage des données via une DLL?
@ZOO Il est très difficile de contrôler, ne fonctionne pas si la DLL est déchargée et nécessite une compilation spéciale de la DLL - données dans les DLL n'est pas partagée par défaut.
Regardez dans #pragma data_seg pour plus d'informations sur le partage des données entre DLLS
Vous pouvez avoir un cache partagé (exemple d'un service Windows ou d'un processus masqué) pouvant être écouter - renvoyer des données à tous les abonnés. Ceci utilisant une approche de modèle d'observateur.
La méthode la plus simple (en supposant que Windows puisque vous mentionnez une DLL) est probablement d'utiliser CreateProcess et d'ouvrir un tuyau pour le processus enfant, comme décrit ici sous la forme simplifiée ici: http://msdn.microsoft.com/en-us/library/ms682499.aspx
Les tuyaux nommés peuvent être une alternative, surtout si vous ne contrôlez pas la durée de vie de tous les processus. http://msdn.microsoft.com/en-us/library/aa365590. ASPX
Pour les cas simples, les gamelles de messagerie peuvent être une alternative suffisante.
http://msdn.microsoft.com/fr -Us / Bibliothèque / AA365574.ASPX # BASE.USION_A_MAILSLOT_FOR_IPC
Voici une liste plus longue de diverses techniques de communication interprocesses pour Windows. http://msdn.microsoft.com/en-us/library/aa365574. ASPX
Pour quelque chose qui se passe localement, l'utilisation de sockets semble une sorte de surpuissance. De plus, vous devez mettre en œuvre votre propre mécanisme de sécurité pour empêcher les attaques d'usurpation, plutôt que en fonction du mécanisme de sécurité intégré de la plupart des autres méthodes IPC.
Saviez-vous que vous avez posté de vieux liens?
Non, ils sont tous venus de nouvelles requêtes Google quand j'ai posté ... Ah, je vois que la version VS est spécifiée dans elles. Je ne pense pas que le contenu a changé cependant.
C'est toujours bon d'explorer des solutions alternatives possibles, mais je crois personnellement que l'utilisation de sockets comme une couche de transport pour les données entre les applications est non seulement la preuve future, mais également évolutive. L'utilisation de sockets éliminera la nécessité de rédiger des quantités copieuses de code spécifique du système d'exploitation, ce qui pourrait vous défier de porter votre application à l'avenir aux systèmes d'exploitation non-Windows.
Je suggérerais des sockets.
Cependant, il exigera de rédiger des quantités copieuses de code neutre du système d'exploitation, puis de le maintenir.
Je serais un peu d'accord avec Juan Zamora M sauf que le service fournissant les données devrait avoir une API qui peut être demandé si nécessaire n'est pas poussé lorsqu'il est modifié via des auditeurs.