11
votes

Comment une assemblée est-elle résolue dans .NET?

Comment les assemblages sont résolus dans .NET. Je veux dire, comment une assemblée est-elle résolue avec un nom pleinement qualifié. Je suis confus sur les jetons clés publics / privés et la nommée solide. Merci

edit: J'ai également lu sur la signature et des trucs retardés comme ça. Les gens l'utilisent-ils vraiment? (Quelqu'un a-t-il réellement utilisé la signature de retard) qui génère la clé de signer un assemblage. Je suis désolé si je demande trop de questions. Mais je suis confus à ce sujet.


0 commentaires

3 Réponses :


1
votes

Les assemblages Résolution peuvent impliquer un certain nombre d'étapes, en fonction de l'endroit où l'ensemble qu'il tente de charger est (GAC, dossier de base d'applications, des dossiers sous ou un autre dossier à partir de votre dossier d'application de base).

Ceci est un bon article sur la manière dont vous pouvez spécifier où .NET recherche vos assemblages. Article MSDN

Si vous souhaitez que l'exécution résolve un assemblage non stocké dans votre dossier de base d'application ou le GAC, vous devez vous inscrire à l'événement AppDomain qui est soulevé lorsqu'il ne peut pas trouver l'assemblage. Vous réagiriez ensuite sur cet événement en vérifiant si le fichier existe dans votre autre emplacement, puis retournez-le à l'aide de l'assemblage.Loadfrom (ThePath).

Juste pour ajouter à cette réponse est en outre ce lien de craquage qui devrait résumer l'ensemble de la nommée solide avec des clés très bien pour vous: Nommage solide - Clés, etc.

Des questions de cela, demandez simplement!


1 commentaires

Qui génère la clé pour signer un assemblée?



2
votes

L'article suivant sur MSDN devrait vous aider à sortir:

http://msdn.microsoft. COM / EN-US / Bibliothèque / YX7XEZCF (vs.71) .aspx

La résolution de montage dans .NET peut être assez complexe, car les assemblages peuvent être situés dans une variété d'emplacements, y compris le GAC, colocaté avec l'assemblage d'exécution, l'ombre copiée, etc. Le processus général est appelé processus de fusion et garantit que Les mesures de sécurité appropriées sont remplies lors du chargement des assemblages.


0 commentaires

16
votes

La nommage forte est utilisée avec un "jeton clé publique" pour produire un assemblage nom d'affichage complet ( mscorlib, version = 2.0.0.0, culture = neutre, PublickeyToken = B4778 ,. .... ). Cela nous permet d'avoir plusieurs versions du même assemblage côte à côte dans le même répertoire d'applications.

Un jeton clé publique (et, par conséquent, la technique de nommage de chaîne) permet également au chargeur .NET de détecter si quelqu'un a altéré de votre contenu de mon assemblage puisque vous l'avez distribuée. Cela est vrai parce que lorsque vous signez un assemblage avec votre "jeton privé", le compilateur générera une valeur de hachage qu'elle intégrée aux métadonnées d'assemblage décrivant la partie publique de votre "jeton privé". Le chargeur peut ensuite utiliser cette valeur pour déterminer si votre assembly a été modifié ou non.

En ce qui concerne la résolution des assemblées, il y a quelques éléments de base à considérer:

  • sondage Le chargeur tente de localiser des assemblages à l'aide d'une technique de base "Probing". Cela signifie qu'il tentera de localiser " myassembly.dll " (par exemple) dans le répertoire de démarrage de l'application, sinon là, dans les sous-répertoires ci-dessous. Si la sondage ne parvient pas à localiser " myassembly.dll ", alors le appdomain 's assemblageResolve est tiré.

  • configuration machine / utilisateur / système Le machine.config , user.config et system.config sont des fichiers de configuration stockés localement sur le système que l'on peut utiliser pour modifier le comportement de Le résolveur de l'assemblage sur une "machine", "utilisateur" ou "système" -Wide -Wide.

  • Politique d'éditeur On peut utiliser le jeton XML " " dans le fichier de configuration de votre application (par exemple, " myapp.exe.config ") pour pointer sur résolveur à une certaine version d'un assemblage ou de charger un assemblage d'un emplacement différent.

  • résolution personnalisée Gérer le " AssemblyResolve " Event du AppDomain . Cet événement est soulevé chaque fois qu'un assemblage ne pouvait pas être résolu via des méthodes "traditionnelles"

    De loin, le mécanisme le moins compliqué est de gérer l'événement "AssemblyResolve".

    Pour résumer, le résolveur regarde dans le répertoire actuel ou dans le cache de montage global, la stratégie traite, puis permet une résolution personnalisée.


5 commentaires

"Permet au chargeur .NET de détecter si quelqu'un a altéré avec votre contenu de montage ..." N'avez-vous pas vraiment compris cela.


Sûr. Fondamentalement, lorsque vous compilez votre montage avec une valeur de hachage de noms forte (vous pouvez également utiliser l'utilitaire de commande Sn.exe), la valeur de hachage est écrite aux métadonnées de l'Assemblée qui décrit sa version, sa valeur de culture, de nom et de jeton. Lorsque le chargeur charge votre montage, il vérifie si votre assemblage dispose d'un jeton de clé publique et, dans l'affirment, exécute le même algorithme de hachage sur votre assemblée, le compare avec ce qui est dans les métadonnées d'assemblage et refuse de charger l'assemblage si elles diffèrent. C'est ainsi que le chargé détecte "altérer". C'est très limité que vous pouvez voir, mais suffisant pour le moment.


Sur la surface, cela ressemble à un moyen de protéger notre code .NET. Mais hélas, l'excitation s'arrête rapidement et vous réaliserez bientôt que l'obfuscation est la meilleure chose à faire.


Et je n'ai pas la partie de "..it ressemble à un moyen de protéger notre code .NET". J'ai toujours pensé que la signature d'un assemblée garantit que nous utilisons l'assemblage qui était initialement destiné à être utilisé. (Mais existe-t-il une situation lorsque cela pourrait échouer?) Et pas pour protéger le code source (pour lequel l'obfuscation sert le but).


Oui Signature Assurez-vous que nous ne chargons que des assemblages que nous avons construits (il permet également de verrer la version à côte et partageant notre assemblée mondialement via le cache de montage global). En outre, la stratégie d'éditeur nous permet de "rediriger" une référence d'une version d'un assemblage à une autre version. Y a-t-il des situations où cela échouerait? Sûr. Mais si des assemblages référencés ne parviennent pas à charger, il est généralement lié à la localisation de chemin, à une version non valide des problèmes d'assemblage ou de permission de sécurité (tels que le chargement à partir d'un lecteur réseau partagé).