2010-08-11 6 views
0

J'ai 2 assemblages. Assembly2 est référencé par Assembly1. Pourquoi Assembly2 est-il verrouillé?Pourquoi les assemblages référencés sont-ils verrouillés?

Je pensais que l'ensemble de l'ensemble est chargé dans la RAM par le compilateur JIT, n'est-ce pas?

Comment fonctionne le machinisme lorsqu'un assemblage référencé est appelé?

+1

Parce qu'il peut y avoir un processus qui les * verrouille *. Quel genre de question est-ce? Attendez-vous vraiment des réponses utiles? –

+2

@Darin Dimitrov; S'ils posaient la question, peut-être espéraient-ils une réponse utile? Peut-être leur dire * pourquoi * c'est une mauvaise question. :-) –

+0

Vous avez plus d'informations sur votre question, l'assemblage de la sorcière est verrouillé quand, pourquoi est-ce un problème? – Ivo

Répondre

3

(oui, la question aurait pu être mieux, quand même ...)

ensembles sont chargés dans Référencés le processus et sont ainsi verrouillés. Vous pouvez contourner ceci avec la copie d'ombre, ou assurez-vous juste de fermer chaque processus qui utilise vos assemblées avant que vous essayiez de les modifier.

+0

Je pensais que tout l'assemblage est dans la RAM, n'est-ce pas? – Rookian

+0

@Rookian C'est une bonne question. Je me demande si tout l'assemblage est chargé en mémoire ou seulement les parties qui doivent être référencées par d'autres applications, c'est-à-dire les parties marquées 'public'. –

1

J'ai été confronté à une situation lors de l'écriture d'un composant .NET à consommer dans une application VB6 où je ne pouvais pas déployer mon assembly .NET recompilé alors que l'éditeur VB6 était ouvert. Cela m'a vraiment frustré parce que je voulais juste faire un changement rapide et que le changement apparaisse dans mon éditeur VB6. Je recevais un message d'erreur indiquant que l'assembly était verrouillé par un autre processus ou thread. J'ai ensuite réalisé que cela avait beaucoup de sens. Si l'application de référencement (dans mon cas, l'EDI VB6) fait confiance à cette bibliothèque pour qu'elle soit la même à chaque fois qu'elle va la consommer, elle va rencontrer de sérieux problèmes si la DLL change pendant que l'application est en mémoire. Dans mon cas, la fermeture de l'IDE VB6, la mise à jour de la DLL et la réouverture de l'IDE VB6 ont très bien fonctionné. C'était un peu gênant dans mon flux de travail, mais une fois que j'ai compris pourquoi cela se passait, je m'en suis remis.

Questions connexes