部署的dll文件不是由TFS构建的文件

我有一个最近开始出现奇怪现象的TFS 2013构建定义。它已经工作了一年多，现在没有任何问题。部署的dll文件不是由TFS构建的文件

它构建了4个不同的项目。其中两个是asp.net mvc/webapi项目，这些项目也通过msdeploy部署到同一QA分段Web服务器上的两个独立网站。该版本配置为使用发布|任何CPU

构建运行时，使用ApplyVersionToAssemblys powershell脚本设置dll版本。

在build文件夹中，所有程序集都有正确的版本。但在其中一个已部署的网站中，其中一个dll文件“WebUI.dll”的版本号为1.0.0.0，即与构建目录中的相同dll不同，其版本号为4.0.buildnumber

部署的“WebUI。 dll“似乎也内置在调试模式下，因为只有在定义DEBUG时才会显示一些按钮和操作。

如果我从构建目录或甚至PublishedWebsites目录复制构建的WebUI.dll，一切都按预期工作。

所以我的问题是如何MSDeploy通过MSBuild创建其“自己的”版本的WebUI.dll？（并且没有 - Define DEBUG常量复选框未在发布模式中选中）。在服务器上的任何位置都找不到版本1.0.0的WebUI.dll，因此我猜想在msdeploy运行时必须“创建”它？

（我最近做出的唯一改变是增加它建立同样的解决方案，运行所有测试，但不部署任何新的构建定义。）

更新：我试着用从VS发布构建过程使用相同的发布配置文件，并按预期工作。部署的WebUI.dll是以发布模式构建的。该版本不适用，因为它是构建过程的一部分，但重要的是它的发布模式部署的dll，而不是调试，这是构建过程进行部署时的情况。我也尝试创建一个web部署包，并将其安装在本地服务器上，结果相同。

所以问题仍是建在构建过程中WebUI.dll是正确的（Release模式和正确的版本） - 但获得由调试模式，并没有versoning

“改为”在构建服务器上部署时

UPDATE 2; MSBUILD在cmd

C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo /noconsolelogger "C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.sln" /nr:False /fl /flp:"logfile=C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:PublishProfile=Chicago /p:AllowUntrustedCertificate=true /p:Password=bw /m /p:OutDir="C:\Builds\2\Products\SomeApp4.Main\bin\SomeApp4.Web\\" /p:Configuration="Release" /p:Platform="Any CPU" /p:VCBuildOverride="C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.sln.Any CPU.Release.vsprops" /dl:WorkflowCentralLogger,"C:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/740;IgnoreDuplicateProjects=False;InformationNodeId=14;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;LogProjectNodes=True;LogWarnings=True;TFSUrl=http://boston.SomeCompany.local:8080/tfs/SomeCompany;"*WorkflowForwardingLogger,"C:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;" /p:BuildId="abd7db3d-4ff8-43b4-ab36-f35c6f6e5697,vstfs:///Build/Build/740" /p:BuildLabel="SomeApp4.Main_4.0.6.740_20160121_103558" /p:BuildTimestamp="Thu, 21 Jan 2016 09:35:59 GMT" /p:BuildSourceVersion="[email protected]$/Products" /p:BuildDefinition="SomeApp4.Main"

来源

2016-01-20 Niclas

如果您从VS发布，您会得到相同的结果吗？你也可以尝试创建一个MSDeploy包并检查包内的文件版本。我假设你一直使用PowerShell脚本来设置DLL版本？ – chief7

查看我的帖子中的更新以回复您的评论。是的 - 我一直使用相同的PowerShell脚本。这仍然有效。在构建服务器上构建的文件是正确的（发布模式为versoning），但在部署过程中会取代其中一个dll文件WebUI.dll - 但只能在构建过程中使用 – Niclas

您可以共享您的msdeploy命令吗？ –

我发现了这个问题。

构建定义构建4种溶液，其中一个是在WebUI（ASPNET MVC）溶液和一种是一个API溶液（asp.net的WebAPI）

在API溶液一个项目被引用在WebUI项目，但在WebUI项目不在Api解决方案中。

MSbuild无论如何解决了WebUI项目，所以没有错误，并构建+部署的API解决方案。但是WebUI项目是以调试模式构建的，因为它在Api解决方案中没有解决方案配置我猜

msbuild运行带有部署标志的api解决方案时，它也设法部署内置调试的WebUI项目。

因此WebUI项目部署了两次。首先从WebUI解决方案中获得正确的解决方案，然后使用Api解决方案编译错误的调试WebUI。

Doh！我只能说这个。

感谢您的帮助球员。

来源

2016-01-21 12:22:57 Niclas

当您更改程序集的版本，源代码控制下的版本将不会改变。您只能更改在生成代理机器上复制的版本。如果msdeploy命令的来源指向TFS中的项目，则不会获得版本化的程序集。

来源

2016-01-21 09:32:11

是的，我知道。并且所有程序集在生成文件夹，放置文件夹和包含WebUI.dll的_PublishedWebsites文件夹中都有正确的版本号。问题是文件在构建过程中被部署的时间。部署的WebUI.dll不是在构建中创建的，而是由Debug模式的WebUI.dll文件替换的，我无法理解如何/为什么？我怀疑aspnet_compiler并试图在没有BuildMvcViews的情况下运行该构建，但WebUI.dll仍然被替换 – Niclas

部署的dll文件不是由TFS构建的文件

回答

相关问题