生成服务器中的Gitlab msbuild问题-无法解决此引用.找不到程序集

Question

我有一个在本地系统中运行良好的解决方案。但当生成在生成服务器中触发时，相同的代码会引发以下错误。你能帮忙吗？

C:Program Files (x86)Microsoft Visual Studio2017BuildToolsMSBuild15.0BinMicrosoft.Common.CurrentVersion.targets(1988,5): warning MSB3245: **Could not resolve this reference. Could not locate the assembly "Company.Common.SC.Data, Version=2.5.3.32715, Culture=neutral, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.** [C:glrbuilds7a6e3c3eCompanyProductCompany-sm-mvcCompany.Product.MVC.ModelsCompany.Product.MVC.Models.csproj]
For SearchPath "C:glrbuilds7a6e3c3eCompanyProductCompany-sm-mvcpackagesCompany.Common.SC.MVC.Library.1.7.0libnet45".
Considered "C:glrbuilds7a6e3c3eCompanyProductCompany-sm-mvcpackagesCompany.Common.SC.MVC.Library.1.7.0libnet45Company.Common.SC.Data.winmd", but it didn't exist.
Considered "C:glrbuilds7a6e3c3eCompanyProductCompany-sm-mvcpackagesCompany.Common.SC.MVC.Library.1.7.0libnet45Company.Common.SC.Data.dll", but it didn't exist.
Considered "C:glrbuilds7a6e3c3eCompanyProductCompany-sm-mvcpackagesCompany.Common.SC.MVC.Library.1.7.0libnet45Company.Common.SC.Data.exe", but it didn't exist.
For SearchPath "{HintPathFromItem}".
Considered "..packagesCompany.Common.SC.Data.2.5.3libnet45Company.Common.SC.Data.dll",
but its name "Company.Common.SC.Data, Version=2.5.3.23193, Culture=neutral, PublicKeyToken=null"
didn't match the expected name "Company.Common.SC.Data, Version=2.5.3.32715, Culture=neutral, processorArchitecture=MSIL".

我认为Company.Common.SC.Datanuget库有问题。nugetlib是使用nuget包管理器创建的，在创建包时，我们给出了版本号2.5.3，但不确定如何添加subversion。请查看错误的最后一行。

Considered "..packagesCompany.Common.SC.Data.2.5.3libnet45Company.Common.SC.Data.dll",
but its name "Company.Common.SC.Data, Version=2.5.3.23193, Culture=neutral, PublicKeyToken=null"
didn't match the expected name "Company.Common.SC.Data, Version=2.5.3.32715, Culture=neutral, processorArchitecture=MSIL".

更新1:

Nuspec for Company.Common.SC.Data

<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>$description$</description>
<releaseNotes>Updated for 8.0 and includes additional library code related to Dacron, Terathane and other sites that added to core capabilities.</releaseNotes>
<copyright>$copyright$</copyright>
<tags>sitecore data website common</tags>
</metadata>
</package> 

Answer 1

我发现了这个问题并能够修复它。问题是使用AssemblyVersion编号构建的nuget项目dll。像这样的东西。

[assembly: AssemblyVersion("1.7.1.*")]
[assembly: AssemblyFileVersion("1.7.0")]

因此，当我们通过nugetfeed将subversion添加到我们的项目中时，在项目参考中添加了subversion(1.7.1.354567)。

我刚刚删除了*并构建了nuget解决方案，然后创建了Company.Common.SC.Data的nuget包，然后在我的项目中再次引用了它。它奏效了。

Answer 2

我们遇到了同样的问题，但没有使用NuGet(对我们来说不可行)。在我们的情况下，这是由于项目X引用DLL Y，而DLL Y又引用DLL Z(X不直接引用Z)。我们有本地的true&所有参考文献中的特定版本为false。我们只是将所有依赖的DLL输出到一个公共bin文件夹中。

考虑Z的当前版本是1.1.1.1。我们构建Y，它也将其版本(1.1.1.1)放入bin文件夹中。我们再次构建Z——它的版本现在是1.1.1.2，并复制到bin文件夹中——所以我们有Y=1.1.1.1(在构建Z时，它应该是Z的1.1.1.1)如果现在构建了X，那么它将从bin文件夹(1.1.1.2)中获取Y的DLL，而不是Z。

Visual Studio构建通过获取最新版本的Y&来自bin文件夹的Z，不关心版本，因为"特定版本"设置为false。

然而，msbuild抱怨道，因为它似乎忽略了这一点，并期望Y的当前版本所期望的Z的特定版本(1.1.1.1)，并记录"与期望的名称不匹配"错误。如果我们再次构建Y(为了刷新它现在需要Z的1.1.1.2)，那么X包含DLL fine。