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. What are the proper command line build utilities to restore all nuget packages and then build all projects in the solution?
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. According to https://github.com/dotnet/standard/blob/master/docs/versions.md, this specific version combination of Framework/Standard should be compatible.
Here is my solution as it stands today:
WebApp - MVC 5.0 ASP.NET web app project targeting .NET Framework 4.6.2. 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.
ModelsLibrary - .NET Standard 2.0, targeting both Standard and 4.6.2*. Contains nothing but plain-old C objects that are used throughout the solution.
LogicLibrary - .NET Standard 2.0, targeting both Standard and 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.
ServiceLibrary - .NET Framework 4.6.2 class library project. Performs CRUD operations for the WebApp. All objects fetched from, inserted into, or updated in the database are the POCOs from the ModelsLibrary project. 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.
TestsProject - .NET Framework 4.6.2 unit test project using Microsoft.VisualStudio.QualityTools.UnitTestFramework. 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:
<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
LogicLibrary has project dependency on ModelsLibrary
ModelsLibrary has no project dependency
ServiceLibrary references ModelsLibrary
TestsProject references 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. 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. The server where builds are to take place has VS2017Pro installed, the .NET Framework 4.7.1 targeting pack installed, and all appropriate updates.
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. My assumption is in this order: 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? What is being done differently? Ok, let's try a restore on the .NET Framework project that uses quite a few NuGet packages:
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.
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. Nor will using "dotnet build" on specific projects work. 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? What is being done differently in VS that allows a successful build? What commands, and more importantly, what versions of the utilities, does Visual Studio 2017 Pro use to build a solution like this?
Short Version: Lex Li's suggestion was correct. 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. 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. Once I could get the project to build again in visual studio, building within the command line was fairly simple. 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:
del %system.teamcity.build.workingDir%\packages /F /S /Q
rd /s /q %system.teamcity.build.workingDir%\packages
run 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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With