引用DLL时忽略版本号 [英] Ignoring build number when referencing dll
问题描述
我有一个解决方案，与.NET 4.0的项目（C＃）产生延迟签署的DLL，我dotfuscate并签字。
I have one solution with a .NET 4.0 project (C#) that produces a delayed signed dll, that I dotfuscate and sign.
修改：这就是我的版本的dll：
EDIT: This is how I version the dll:
[assembly: AssemblyVersion("0.7.0.*")]
[assembly: AssemblyFileVersion("0.7.0.0")]
我有一个.NET 4.0的项目（C ++ / CLI）引用签署的dll，并产生一个签名的dll另一种解决方案（实际上，延迟签署并签署了，因为的在C ++的缺陷构建系统）。
的问题是，在参照该dll包含特定的版本号，其中包括连版本号（我想有一个版本号）。
The problem is that the reference to the dll contains a specific version number, which includes even the build number (I want to have a build number).
我每次建立参考DLL，我必须要改变项目设置文件（.vcxproj），所以它引用新版本的DLL。自从我与源代码管理工作，这是非常不方便的（不同的计算机上可能有不同的版本号，因为每个电脑建立自己的参考DLL - 引用的DLL是不是在源代码控制）。
Every time I build the referenced dll, I have to change the project settings file (.vcxproj) so it reference the new version dll. Since I work with source control, this is very inconvenient (different computers might have different build numbers since each computer build its own referenced dll - the referenced dll is not in the source control).
如果我不改变的参考，我得到一个警告：
If I don't change the reference, I get a warning:
警告MSB3245：无法解析 此引用。无法找到 装配...
warning MSB3245: Could not resolve this reference. Could not locate the assembly...
和这样的许多错误：
错误C3083：'富'：符号到 留下了::必须是一个类型
error C3083: 'Foo': the symbol to the left of a '::' must be a type
有一次我改变参考这些都解决了。
These are resolved once I change the reference.
如何让我参考忽略内部版本号，甚至整个版本号？
How do I make the reference ignore the build number or even the entire version number?
推荐答案
C＃的IDE具有该选项，特定版本=假。不可用在C ++ / CLI IDE。坦率地说，这不是一个真正的问题。您可能正在使用的[的AssemblyVersion]属性不正确。该版本与公开的类中集关联。如果您在这些类中的公共成员的任何变化，那么你已经有了一个潜在的重大更改，可以使code，有一个依赖于这些类失败。
The C# IDE has an option for that, "Specific Version = False". Not available in the C++/CLI IDE. Frankly, this is not a real problem. You are probably using the [AssemblyVersion] attribute incorrectly. That version is associated with the publicly visible classes in the assembly. If you make any changes in the public members of those classes then you've got a potentially breaking change that can make code that has a dependency on those classes fail.
目前的这一点的应该改变[的AssemblyVersion。和使用该组件的任何项目都必须得到他们的引用程序集更新，必须重新编译。
At that point should you change the [AssemblyVersion]. And any project that uses the assembly must get their reference assembly updated and must be recompiled.
这是其他非重大更改，如错误修正或在非可见类一个调整产生一个新的文件，该文件是否则完全兼容与使用它的任何项目。您应该更新[AssemblyFileVersion]号。这在C ++ / CLI项目需要更新的非托管版本的资源。更改相应的rc文件可以自动化，或者你可以使用＃定义。
An otherwise non-breaking change, like a bug fix or a tweak in the non-visible classes produces a new file that is otherwise completely compatible with any project that uses it. You should update the [AssemblyFileVersion] number. Which in a C++/CLI project requires updating the unmanaged Version resource. Changing the corresponding .rc file could be automated, or you could use a #define.
请注意如何在2.0版.NET基集表现了同样的方式。他们[的AssemblyVersion]在2.0.0.0住整个3.0，3.5和3.5 SP1版本。他们的文件版本开始在2.0.50727.42。并得到了在过去5年里增加很多倍，达2.0.50727.4927，给予或采取。
Note how the .NET base assemblies in version 2.0 behaved the same way. Their [AssemblyVersion] stayed at 2.0.0.0 throughout the 3.0, 3.5 and 3.5 SP1 releases. Their file version started at 2.0.50727.42. And got incremented many times over the past 5 years, up to 2.0.50727.4927, give or take.
有关的记录，您链接到VS2010的错误是不是一个错误。它只是从来没有工作过，失败是沉默。这是在C ++的缺陷构建系统，mt.exe嵌入清单的在的程序集是强命名。并打破了强名称的过程中，因为更改文件哈希值。 VS2010实际上是一种进步，它警告它，而不是静静地让一个破碎的强名称去。你不必耽误签收，只能用-Ra辞职后生成事件。
For the record, that VS2010 bug you linked to is not a bug. It just never worked before, failure was silent. It is a flaw in the C++ build system, mt.exe embeds the manifest after the assembly is strong named. And breaks the strong name in the process because that changes the file hash. VS2010 is actually an improvement, it warns about it rather than silently letting a broken strong name go through. You don't have to delay-sign, only resign with -Ra in a post build event.
这篇关于引用DLL时忽略版本号的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
