2010-03-25 7 views
4

Notre application .NET 3.5 C# crée plusieurs domaines d'application. Chaque domaine d'application charge la même DLL tierce non gérée. Cette DLL lit un fichier de configuration lors de l'initialisation. Si la configuration change pendant l'exécution, la DLL doit être déchargée et chargée à nouveau. Cette DLL n'est pas dans notre portée pour réécrire correctement.Plusieurs domaines d'application appelant la même DLL non gérée

Chaque domaine d'application a-t-il accès à une copie séparée de cette DLL non gérée? Windows conserve-t-elle une copie de la DLL et conserve-t-elle un compte d'utilisation? Si tel est le cas, comment obtenons-nous que chaque instance de la DLL non gérée reflète sa configuration unique?

+0

Lorsque vous dites 'Load', voulez-vous dire via 'LoadLibrary'? – leppie

+0

Pour en savoir plus sur les circonstances exactes dans lesquelles le fichier de configuration change: qu'est-ce qui le modifie: impliquez-vous que, à des intervalles arbitraires, vous créez un nouveau domaine, puis lisez le fichier de configuration qui a été modifié par l'application le progrès ? Donc, à chaque fois que le fichier de configuration change, toutes les DLL chargées avec un fichier de configuration précédent doivent être déchargées et rechargées? Donc, un 'dll donné n'a pas la possibilité de se re-configurer lui-même lorsque notifié le fichier de configuration a changé? On dirait un cauchemar de design. – BillW

+0

Leppie - par "Load" Je veux dire LoadLibrary. BillW - Je suis d'accord, c'est un cauchemar de design hors de notre portée de contrôle. Nous devons travailler avec pour l'instant. Le fichier de configuration change chaque fois qu'un utilisateur doit basculer entre "projets" (ce qui n'est pas important dans ce contexte) et cela peut arriver à tout moment. –

Répondre

0

Je pense que dll non gérés sont chargés qu'une seule fois par processus par le système d'exploitation, de sorte que chaque application domaine aura la même instance chargée. Pour décharger une DLL, utilisez la fonction FreeLibrary. Cependant, étant donné que plusieurs domaines d'application sont susceptibles d'avoir chargé la DLL, il n'y a aucune garantie que FreeLibrary d'un domaine d'application libérera/déchargera réellement la DLL. Comme le dit BillW, cela me semble aussi un cauchemar de design!

Questions connexes