Ignorer le numéro de build lors de la référence dll

Question

J'ai une solution avec un projet .NET 4.0 (C#) qui produit une DLL signée retardée, que je dotfuscate et signe.

EDIT: Voici comment version que je le dll:

[assembly: AssemblyVersion("0.7.0.*")] 
[assembly: AssemblyFileVersion("0.7.0.0")] 

J'ai une autre solution avec un projet .NET 4.0 (C++/CLI) qui fait référence à la dll signé et produit un dll signé (en fait , retardé signé et signé dans une publication de poste en raison de a flaw in the C++ build system).

Le problème est que la référence à la DLL contient un numéro de version spécifique, qui inclut même le numéro de build (je veux avoir un numéro de build).

Chaque fois que je compile la DLL référencée, je dois modifier le fichier de paramètres du projet (.vcxproj) afin qu'il fasse référence à la nouvelle version dll. Depuis que je travaille avec le contrôle de la source, c'est très gênant (différents ordinateurs peuvent avoir différents numéros de construction puisque chaque ordinateur construit sa propre DLL référencée - la DLL référencée n'est pas dans le contrôle de source).

Si je ne change pas la référence, je reçois un avertissement:

avertissement MSB3245: Impossible de résoudre cette référence. Impossible de localiser l'ensemble ...

Et beaucoup d'erreurs comme ceci:

erreur C3083: 'Foo': le symbole à gauche d'un '::' doit être un type

Ceux-ci sont résolus une fois que je change la référence.

Comment faire en sorte que la référence ignore le numéro de version ou même le numéro de version complet?

Answer 1

L'IDE C# a une option pour cela, "Version Spécifique = Faux". Non disponible dans l'IDE C++/CLI. Franchement, ce n'est pas un vrai problème. Vous utilisez probablement l'attribut [AssemblyVersion] de manière incorrecte. Cette version est associée aux classes visibles publiquement dans l'assembly. Si vous apportez des modifications dans les membres publics de ces classes, vous pouvez modifier le code qui a une dépendance sur ces classes.

A point si vous modifiez [AssemblyVersion]. Et tout projet qui utilise l'assembly doit mettre à jour son assembly de référence et doit être recompilé. Un changement autrement insécable, comme un correctif de bogue ou un tweak dans les classes non visibles produit un nouveau fichier qui est par ailleurs complètement compatible avec n'importe quel projet qui l'utilise. Vous devez mettre à jour le numéro [AssemblyFileVersion]. Ce qui dans un projet C++/CLI nécessite la mise à jour de la ressource Version non managée. Changer le fichier .rc correspondant pourrait être automatisé, ou vous pourriez utiliser un #define.

Notez comment les assemblys de base .NET dans la version 2.0 se sont comportés de la même manière. Leur [AssemblyVersion] est resté à 2.0.0.0 tout au long des versions 3.0, 3.5 et 3.5 SP1. Leur version du fichier a commencé à 2.0.50727.42. Et a été incrémenté de nombreuses fois au cours des 5 dernières années, jusqu'à 2.0.50727.4927, donner ou prendre.Pour l'anecdote, ce bogue VS2010 auquel vous avez lié n'est pas un bug. Cela n'a jamais fonctionné auparavant, l'échec était silencieux. C'est une faille dans le système de construction C++, mt.exe intègre le manifeste après l'assembly est fort nommé. Et casse le nom fort dans le processus, car cela modifie le hachage du fichier. VS2010 est en fait une amélioration, il avertit à ce sujet plutôt que de laisser passer silencieusement un nom fort brisé. Vous n'êtes pas obligé de signer un délai, mais seulement de signer avec -Ra dans un événement de génération de message.