在公司外面，我们使用NuGet对内部库进行版本控制。对库的每次提交都会触发构建服务器，该服务器将生成一个新的NuGet软件包并将其上传到我们的内部提要中。
这对我们来说效果很好，但是我们经常遇到WinForms设计器的问题，在WinForms设计器中，它拒绝加载带有以下错误消息的表单：
找不到文件或程序集“ UILib，版本= 1.0.0.906，区域性=中性，PublicKeyToken = null”或没有相关性。系统找不到指定的文件。
（大致：找不到文件或程序集“ UILib，版本= 1.0.0.906，文化=中性，PublicKeyToken =空”或其依赖项之一。系统找不到此文件。）
不过，这只是一个设计者的问题-该应用程序将毫无问题地构建并且将按预期运行。
这就是问题所在，但是现在您需要一些有价值的上下文来使它变得毫无道理。我要打开的表单是应用程序的一部分（简称为App），它包含一个UserControl，它是我们特定于产品的UI库（ProductUILib）的一部分。该库又引用了我们的通用UI库（UILib）。但是，应用程序本身也直接依赖于UILib。
UILib和ProductUILib均通过其自己的NuGet包提供。因此，简化的依赖图如下所示：
App ----> ProductUILib ----> UILib
| ^
------------------------------|
只要ProductUILib和App引用相同版本的UILib（例如1.0.0.906），一切都很好。但是，如果我修改UILib，然后在App中更新我的NuGet依赖项，则App将获取并引用UILib的最新版本（例如1.0.0.932）。ProductUILib是针对较早的UILib构建的，但这应该没问题，因为对UILib的所有更改都是向后兼容的，而且这些库也没有强名称。实际上，构建和运行App可以正常工作。但是，设计者现在无法使用受影响的表单，并显示了我上面提到的错误消息。
为了解决该问题，我们还必须更新ProductUILib的NuGet包，以便它反过来根据最新的UILib构建，然后再次更新App的依赖项以获得新的ProductUILib。但是，这很快变得很乏味，尤其是在具有更多库和依赖项的情况下。
我在VS 2010和最新的VS 2013中都进行了测试，新版本显示了完全相同的行为。
您对我们如何避免此问题有任何建议？
我们设法通过改变我们的战略使用来解决问题AssemblyVersion，AssemblyFileVersion和AssemblyInformationalVersion。
通过将其设置为当前SVN修订版号，我们会在每次构建时自动生成版本号的最后一部分。此生成的版本号（例如1.0.0.906）用于同时加入AssemblyVersion和AssemblyFileVersion。
设计师显然会遇到不匹配的问题，AssemblyVersion因为具有不同AssemblyVersion的程序集被认为是不兼容的。但是，没有强名的程序集的正常加载过程并不介意不匹配，因此可以构建和运行程序。所以设计师有点挑剔。
解决方案是使用一个固定值，AssemblyVersion因为我们只会在重大更改时进行更新。现在，生成的版本号同时指向AssemblyFileVersion和AssemblyInformationalVersion。最后一个很重要，因为NuGet始终会从其中填充.nuspec $ version $占位符，AssemblyVersion除非AssemblyInformationalVersion存在该占位符以覆盖它，并且我们想生成要用于NuGet软件包的版本号。
因此，总而言之：
AssemblyVersion重大更改AssemblyInformationalVersion该号码应该进入你的NuGet包本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句