Assemblages fortement signés

Question

Je ne suis pas un développeur .NET, donc il y a peut-être des choses de base que je ne connais pas.

J'ai un peu d'expérience en codage en C#, mais maintenant j'ai une question. Un de mes projets (A) fait référence à un autre ptoject (B), avec "local copy" défini. Lorsque B.dll est au même endroit que A.exe tout fonctionne. Mais lorsque B.dll est placé dans un répertoire commun à partir de PATH, cela ne fonctionne pas.

Un de mes collègues a dit qu'il pensé Je devrais faire B fortement signé. Est-il correct? Est-ce la raison pour laquelle on voudrait fortement signer une assemblée? J'ai lu un peu à propos de dans Internet mais tout ce que j'ai vu était sur la sécurité ... Si oui, comment signer un assemblage et quelles conséquences cela a-t-il? Veuillez noter que j'utilise VS2003 .Net 1.1.

Edit: Merci à tous pour vos réponses, cependant tous les liens que vous avez fournis se référer aux versions ultérieures de VS et .NET qui ont une sorte de signature onglet dans les propriétés du projet. Est-ce que quelqu'un sait (ou donne un lien) comment nommer fortement l'assembly dans VS2003 .Net1.1?

Answer 1

Je pense que ce que votre collègue pourrait faire référence est "Strong Naming" un assemblage. Strong Naming est ce qui vous permet de déployer votre assembly dans le GAC.

Une fois qu'il est dans le GAC, toute application utilisant cet assembly peut toujours le localiser. Les chemins ne sont pas pertinents et c'est la manière préférée de déployer des assemblys partagés. Pour nommer fortement un assembly, vous pouvez utiliser le sn.exe tool fourni avec Visual Studio pour générer un nom fort, puis signer l'assembly à l'aide du fichier de clés généré via sn.exe.

EDIT: Exemple de la façon d'utiliser Sn.exe pour nom fort est un ensemble here

Aussi, je pense que vous devriez comprendre comment les ensembles de charges d'exécution. De MSDN

Le moteur d'exécution utilise les étapes suivantes pour résoudre une référence d'assemblage:

Détermine la version de montage correcte en examinant applicables les fichiers de configuration, y compris le fichier de configuration de l'application, fichier de stratégie d'éditeur et configuration de la machine fichier.

Si le fichier de configuration se trouve sur une machine distante, le
runtime doit localiser et télécharger le fichier de configuration d'application premier.

Vérifie si le nom de l'assembly a été lié auparavant et, si c'est le cas, utilise l'assembly précédemment chargé.

Vérifie le cache de l'assembly global. Si l'assembly est trouvé là, l'exécution utilise cet assembly.

sondes pour l'assemblage en procédant comme suit: Si la configuration et la politique de l'éditeur ne compromet pas la référence originale et si la création demande de liaison en utilisant la méthode Assembly.LoadFrom, les contrôles d'exécution pour des notes de localisation.

Si une base de code est trouvée dans les fichiers de configuration, l'environnement d'exécution vérifie uniquement cet emplacement. Si cette vérification échoue, le moteur d'exécution détermine que la demande de liaison a échoué et aucune autre vérification se produit.

Sondes pour l'assemblage utilisant les heuristiques décrites dans la section de sondage . Si l'assembly n'est pas trouvé après la vérification, le moteur d'exécution demande à Windows Installer de fournir l'assembly. Cela agit comme une fonctionnalité d'installation à la demande.

Remarque: Il n'y a pas de vérification de version pour les assemblys sans noms forts, et le runtime ne vérifie pas dans le cache d'assembly global pour les assemblages sans noms forts.

Answer 2

La meilleure façon de procéder consiste à déployer votre fichier .dll dans le GAC. http://support.microsoft.com/kb/815808

Answer 3

Votre problème n'est pas lié à la signature d'assembly en premier lieu. .NET n'utilise pas la variable d'environnement PATH pour charger les assemblys. Le processus est en fait un peu plus complexe et vous mieux lire tous les détails dans MSDN (voir aussi les étapes 1 à 4):

How the Runtime Locates Assemblies

Dans votre cas, il est peut-être le meilleur d'installer l'assembly partagé au GAC. L'installation sur le GAC nécessite que votre assembly ait un nom fort, c'est donc probablement ce que votre collègue a appelé.

Mise à jour:

Comme vous avez demandé spécifiquement de forte nommer un assemblage .NET 1.1 Je vous suggère de vérifier la question suivante:

How to give a .NET 1.1 dll a strong name in VS2003

Answer 4

Quelle est la raison pour laquelle vous voulez mettre le B.dll dans un répertoire commun? est-ce parce qu'il peut être utilisé par un autre programme? Si c'est le cas, l'ajouter au GAC est la meilleure option. Voir this un

Answer 5

Comme 0xA3 déjà mentionné, vous devriez lire l'article sur MSDN. Mais ce qui n'est pas si bien expliqué dans l'article est l'utilisation de l'événement AssemblyResolve. Il sera lancé si le Framework ne trouve pas l'assembly à n'importe quel endroit, vous donnant ainsi la possibilité de lancer une recherche sur vous-même (peut-être dans votre dossier commun) et de retourner l'assemblage nécessaire.

Un exemple sur la façon d'utiliser ceci, peut être trouvé dans my question here.