How to use VSTS to build a .NET solution that contains a .NET Standard project and a .NET 4.7 project?

Question

I have a .NET solution which has 2x projects:

• .NET Standard 1.6
• .NET 4.7 xUnit project

Unfortunately, I'm using a package in the xUnit project that doesn't work in a .NET Core xUnit project, which is why I'm using a .NET 4.7 project for unit testing.

So, i'm not sure how to do this with Visual Studio Team Services.

Previously, I've just had a .NET Standard Project and a .NET Core xUnit project and have the following:

• Get Sources (GIT)
• Restore (.NET Core)
• Build (.NET Core)
• Pack (.NET Core)
• NuGet Push

So - how do I :

• restore + build a .NET Core project
• and then the .NET 4.7 project
• and then run the xunit tests for the .NET 4.7 project
• and finally pack/nuget push the .NET Standard 1.6 project.

please?

---

EDIT:

here's what it looks like on my LOCALHOST machine when i try and do a normal dotnet restore

Notice: - Hornet.Services.csproj is restored. - Hornet.Services.Tests.csproj is not located or restored. - Both projects are in my sln, as shown above with the screen shot above.

c:\Projects\Personal\Hornet\Hornet.Services>dotnet restore
  Restoring packages for c:\Projects\Personal\Hornet\Hornet.Services\src\Hornet.Services\Hornet.Services.csproj...
  Generating MSBuild file c:\Projects\Personal\Hornet\Hornet.Services\src\Hornet.Services\obj\Hornet.Services.csproj.nuget.g.props.
  Writing lock file to disk. Path: c:\Projects\Personal\Hornet\Hornet.Services\src\Hornet.Services\obj\project.assets.json
  Restore completed in 1.42 sec for c:\Projects\Personal\Hornet\Hornet.Services\src\Hornet.Services\Hornet.Services.csproj.

  NuGet Config files used:
      c:\Projects\Personal\Hornet\Hornet.Services\NuGet.Config
      C:\Users\Pure Krome\AppData\Roaming\NuGet\NuGet.Config
      C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

  Feeds used:
      https://api.nuget.org/v3/index.json
      https://purekrome.pkgs.visualstudio.com/_packaging/Hornet-Dev/nuget/v3/index.json

c:\Projects\Personal\Hornet\Hornet.Services>

Answer 1

There's many things going on here:

1. There are now many ways to create a .NET Framework xUnit test project - classic .NET projects or "SDK-based" projects. Currently, only .NET Core and .NET Standard project templates (as well as the "ASP.NET Core (.NET Framework" one) create SDK-based projects, but the TargetFramework property in the csproj file can easily be changed to net47 from e.g. netcoreapp1.1.

2. By default, classic projects use a packages.config file for NuGet references. Only the nuget.exe command line can restore these types of projects. The msbuild-integrated way of referencing NuGet packages using the PackageReference items can be used directly via MSBuild using msbuild /t:Restore which is what dotnet restore does. This means that dotnet restore is unable to restore packages.config based projects. Note that even classic .NET Framework projects (non-SDK-based) can use the PackageReference style in VS 2017 versions >= 15.2.

3. The support for dotnet test is provided by the Microsoft.NET.Test.SdkNuGet package and is meant to be used for SDK-based projects. This package contains the necessary configuration and msbuild targets to allow running tests via msbuild /t:VSTest - which is what dotnet test calls. Classic unit test projects do not contain or reference this logic and rely on a test runner to detect and run tests (e.g. the classic Unit Test VSTS task that uses a visual studio installation).

4. Even though dotnet build should be able to build many classic .NET Framework projects, many features may not work since the underlying build tasks are meant to be run on .NET Framework and may behave differently or are completely unsupported on the .NET Core version of MSBuild - e.g. resx files cannot use file references, assembly signing is limited , COM references don't work etc. As a precaution or fix for these situations, use msbuild instead of the dotnet based tools. (msbuild /t:Restore, msbuild /t:Publish /p:Configuration=Release, msbuild /t:VSTest etc.)

My suggestion: Create the test project as .NET Core xUnit project and change the TargetFramework in the csproj to net47 so that you can use all of the dotnet tooling features.