简体   繁体   English

无法命令行构建混合解决方案(.NET Framework与.NET标准)

[英]Unable to Command-Line Build a Mixed Solution (.NET Framework with .NET Standard)

Short Version: I've got a VS2017 solution with 2 .NET Standard 2.0 projects, a .NET Framework 4.6.2 class library, and .NET Framework 4.6.2 MVC WebApp. 简短版本:我有一个VS2017解决方案,包含2个.NET Standard 2.0项目,一个.NET Framework 4.6.2类库和.NET Framework 4.6.2 MVC WebApp。 What are the proper command line build utilities to restore all nuget packages and then build all projects in the solution? 什么是正确的命令行构建实用程序来恢复所有nuget包,然后在解决方案中构建所有项目?

Long Version: I've migrated a solution targeting .NET Framework 4.5 and Visual Studio Pro 2015 to Visual Studio Pro 2017 with some projects targeting .NET Framework 4.6.2 and some targeting .NET Standard 2.0. 长版本:我已将针对.NET Framework 4.5和Visual Studio Pro 2015的解决方案迁移到Visual Studio Pro 2017,其中一些项目针对.NET Framework 4.6.2,一些针对.NET Standard 2.0。 According to https://github.com/dotnet/standard/blob/master/docs/versions.md , this specific version combination of Framework/Standard should be compatible. 根据https://github.com/dotnet/standard/blob/master/docs/versions.md ,这个特定版本的Framework / Standard组合应该是兼容的。

Here is my solution as it stands today: 这是我今天的解决方案:

WebApp - MVC 5.0 ASP.NET web app project targeting .NET Framework 4.6.2. WebApp - 面向.NET Framework 4.6.2的MVC 5.0 ASP.NET Web应用程序项目。 This is an MVC web app that was created originally in Visual Studio 2013 and has been upgraded numerous times to keep up with .NET Framework upgrades. 这是一个最初在Visual Studio 2013中创建的MVC Web应用程序,并且已经多次升级以跟上.NET Framework升级。

ModelsLibrary - .NET Standard 2.0, targeting both Standard and 4.6.2*. ModelsLibrary - .NET Standard 2.0,同时针对Standard和4.6.2 *。 Contains nothing but plain-old C objects that are used throughout the solution. 除了在整个解决方案中使用的普通C对象外,只包含其他内容。

LogicLibrary - .NET Standard 2.0, targeting both Standard and 4.6.2*. LogicLibrary - .NET Standard 2.0,同时针对Standard和4.6.2 *。 Contains business logic that makes changes to our POCOs and/or makes calls to third-party services using data from our POCOs. 包含对我们的POCO进行更改和/或使用来自POCO的数据调用第三方服务的业务逻辑。

ServiceLibrary - .NET Framework 4.6.2 class library project. ServiceLibrary - .NET Framework 4.6.2类库项目。 Performs CRUD operations for the WebApp. 执行WebApp的CRUD操作。 All objects fetched from, inserted into, or updated in the database are the POCOs from the ModelsLibrary project. 从数据库中提取,插入或更新的所有对象都是ModelsLibrary项目中的POCO。 Cannot be updated to .NET Standard as we have heavy reliance upon linq to SQL throughout this project and linq to SQL is not implemented in .NET Standard. 无法更新到.NET Standard,因为我们在整个项目中都非常依赖linq to SQL,并且在.NET Standard中没有实现linq to SQL。

TestsProject - .NET Framework 4.6.2 unit test project using Microsoft.VisualStudio.QualityTools.UnitTestFramework. TestsProject - 使用Microsoft.VisualStudio.QualityTools.UnitTestFramework的.NET Framework 4.6.2单元测试项目。 Performs basic unit testing on a small number of our key logic operations performed throughout the solution. 对整个解决方案中执行的少量关键逻辑操作执行基本单元测试。 This project, if it is the problem, can be removed and a new test project can replace it in time. 如果是问题,可以删除该项目,并且新的测试项目可以及时替换它。

*The CSProj files for the ModelsLibrary and LogicLibrary projects have the following lines: * ModelsLibrary和LogicLibrary项目的CSProj文件包含以下行:

<TargetFrameworks>netstandard2.0;net462</TargetFrameworks>
<TargetFrameworkIdentifier Condition="'$(_ShortFrameworkIdentifier)'=='net'">.NETFramework</TargetFrameworkIdentifier>
<TargetFrameworkIdentifier Condition="'$(_ShortFrameworkIdentifier)'=='netstandard'">.NETStandard</TargetFrameworkIdentifier>

The solution has the following references: 该解决方案具有以下参考:

WebApp references LogicLibrary, ModelsLibrary, ServiceLibrary WebApp引用了LogicLibrary,ModelsLibrary,ServiceLibrary

LogicLibrary has project dependency on ModelsLibrary LogicLibrary对ModelsLibrary具有项目依赖性

ModelsLibrary has no project dependency ModelsLibrary没有项目依赖性

ServiceLibrary references ModelsLibrary ServiceLibrary引用ModelsLibrary

TestsProject references WebApp, ServiceLibrary, ModelsLibrary TestsProject引用WebApp,ServiceLibrary,ModelsLibrary

The solution as a whole builds, runs, and can be published using the Visual Studio 2017 without any build errors or issues. 整个解决方案可以使用Visual Studio 2017进行构建,运行和发布,而不会出现任何构建错误或问题。 However, our continuous integration and continuous deployment system is completely inoperable. 但是,我们的持续集成和持续部署系统完全无法运行。 To simplify this question, I am only asking how to perform a command-line build of my solution. 为了简化这个问题,我只询问如何执行我的解决方案的命令行构建。 Once that is known, I can adapt our CI/CD solution to utilize the given commands. 一旦知道了,我就可以调整我们的CI / CD解决方案以利用给定的命令。 The server where builds are to take place has VS2017Pro installed, the .NET Framework 4.7.1 targeting pack installed, and all appropriate updates. 要进行构建的服务器安装了VS2017Pro,安装了.NET Framework 4.7.1目标包以及所有适当的更新。

Here is my generalized, pseudo-command idea of what I BELIEVE should take place in the build process: 1. pull latest code for the solution from source control 2. restore all nuget packages 3. build all projects in the solution. 这是我对构建过程中应该发生的概括的伪命令概念:1。从源代码控制中提取解决方案的最新代码2.恢复所有nuget包3.在解决方案中构建所有项目。 My assumption is in this order: ModelsLibrary, LogicLibrary, ServiceLibrary, WebApp. 我的假设是这样的:ModelsLibrary,LogicLibrary,ServiceLibrary,WebApp。

However, I'm getting tons of errors when I try and use command line tools to build. 但是,当我尝试使用命令行工具构建时,我遇到了大量错误。 Right off the hop: 就在跳:

dotnet restore ModelsLibrary
Errors in c:\MySolutionName\ModelsLibrary\ModelsLibrary.csproj
    Package Microsoft.AspNet.WebUtilities 1.0.0-rc1-final is not compatible with netstandard2.0 (.NETStandard,Version=v2.0). Package Microsoft.AspNet.WebUtilities 1.0.0-rc1-final supports:
      - dotnet5.4 (.NETPlatform,Version=v5.4)
      - net451 (.NETFramework,Version=v4.5.1)
    One or more packages are incompatible with .NETStandard,Version=v2.0.

NuGet Config files used:
    C:\Users\MyUserName\AppData\Roaming\NuGet\NuGet.Config
    C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

Feeds used:
    https://api.nuget.org/v3/index.json
    C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

Why would this error out on the command line but show no issue whatsoever within Visual Studio 2017? 为什么在命令行中出现此错误但在Visual Studio 2017中没有显示任何问题? What is being done differently? 有什么不同的做法? Ok, let's try a restore on the .NET Framework project that uses quite a few NuGet packages: 好吧,让我们尝试在.NET Framework项目上使用相当多的NuGet包进行恢复:

c:\MySolutionName>dotnet restore ServiceLibrary
  Nothing to do. None of the projects specified contain packages to restore.

But when I use NuGet 4.4.1, the currently recommended version, nuget packages are restored for this project without issue, but NuGet again shows the above error for the ModelsLibrary. 但是当我使用NuGet 4.4.1,当前推荐的版本时,nuget软件包会在没有问题的情况下为该项目恢复,但NuGet再次显示了ModelsLibrary的上述错误。

This is not the only issue, just one of many, many issues I encounter when I attempt to perform a command-line build for the solution. 这不是唯一的问题,只是我尝试为解决方案执行命令行构建时遇到的许多问题之一。 To get around these package issues, I've restored the packages for using VisualStudio itself and then attempted builds with both "dotnet build" and msbuild (from the VisualStudio 2017 directory), and neither command will successfully build the solution. 为了解决这些包问题,我已经恢复了使用VisualStudio本身的包,然后使用“dotnet build”和msbuild(来自VisualStudio 2017目录)尝试构建,并且这两个命令都不能成功构建解决方案。 Nor will using "dotnet build" on specific projects work. 也不会在特定项目上使用“dotnet build”。 Errors are simply too numerous to list here. 错误太多了,无法在此列出。

So the question boils down to this: Why does this solution build fine within Visual Studio 2017 but not through the command line using dotnet/msbuild? 所以问题归结为: 为什么这个解决方案在Visual Studio 2017中构建得很好,而不是通过使用dotnet / msbuild的命令行? What is being done differently in VS that allows a successful build? VS中允许成功构建的不同之处是什么? What commands, and more importantly, what versions of the utilities, does Visual Studio 2017 Pro use to build a solution like this? Visual Studio 2017 Pro使用哪些命令,更重要的是哪些版本的实用程序来构建这样的解决方案?

Short Version: Lex Li's suggestion was correct. 简短版本:Lex Li的建议是正确的。 Starting from scratch did the trick and this crow sure does taste great. 从头开始做诀窍,这种乌鸦确实味道很好。

Long version: I created a brand new solution in Visual Studio 2017 and created new versions of each of the projects using .NET Framework 4.7.1 and .NET Standard 2.0. 长版:我在Visual Studio 2017中创建了一个全新的解决方案,并使用.NET Framework 4.7.1和.NET Standard 2.0创建了每个项目的新版本。 I then copied in all of the files from the original project and spent a long while resolving all of the nuget and dependency issues. 然后我复制了原始项目中的所有文件,并花了很长时间解决所有的nuget和依赖问题。 Once I could get the project to build again in visual studio, building within the command line was fairly simple. 一旦我能够在Visual Studio中再次构建项目,在命令行中构建就相当简单了。 One other glitch I ran into was an issue Because my actual use case was within team city, here are the command line steps I am able to use to build my solution: 我遇到的另一个小故障是一个问题因为我的实际用例是在团队城市中,这里是我能够用来构建我的解决方案的命令行步骤:

delete all of the files in the packages directory: 删除packages目录中的所有文件:

del %system.teamcity.build.workingDir%\packages /F /S /Q
rd /s /q %system.teamcity.build.workingDir%\packages

run nuget restore: 运行nuget restore:

C:\TeamCity\buildAgent\tools\NuGet.CommandLine.4.6.1\tools\NuGet.exe restore %system.teamcity.build.workingDir%\MyWebProject\packages.config -PackagesDirectory %system.teamcity.build.workingDir%\packages -NonInteractive
dotnet restore %system.teamcity.build.workingDir%\MyModelsProject
dotnet restore %system.teamcity.build.workingDir%\MyLogicProject

build the solution: 构建解决方案:

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\MSBuild.exe" %system.teamcity.build.workingDir%\MyWebProject.sln /p:Configuration=MyConfiguration /p:DeployOnBuild=true /p:PublishProfile=MyPublishProfile

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM