CODEWITHSUNDEEP
msbuildmono.net-core
kataik
kataik

Reputation: 520

.NET Standard on Linux

I am doing some experiments in an uncommon stack. I have a .NET solution which is a mixture of .NET Standard, Core and regular .NET Framework projects. Both VS, framework and tooling are updated to latest available.

I'd like to use gitlab CI with a docker runner over ubuntu.

Before I introduced Core/Net Standard libraries (xprojs), I was able to build my solution by executing

MONO_IOMAP=case xbuild /t:Build /p:Configuration="Release" /p:Platform="Any CPU" ./src/CoreLibrary/CoreLibrary.sln

, but since that, I keep getting the

could not import "$(VSToolsPath)\DotNet\Microsoft.DotNet.Props"

error for all of my xprojs. Although I am able to build the xprojs with dotnet restore and dotnet build, the rest only can be built with xbuild. Right now I have two solutions to be able to build the non-xbuilds on linux separately to avoid the error. Is this the best I can do? Can somebody give me a hint on how to do this properly?

Update

To simplify things, let's say I have two projects within a solution: a .NET Core Library project targeting netstandard1.4 (xproj) and the same old .NET Console Application targeting .NET Framework 4.6.1 (csproj). The console application has a dependency to the netstandard library.

From Visual Studio, I am able to build the solution without any problem, both the projects get built properly. From my windows machine, I can use the dotnet utility tool as well to build/run xprojs. All works fine.

In my ubuntu based container though, mono is not capable to build the solution, it shows the error above (sounds reasonable, no VS installed there). I am only able to first build the xproj by using the properly working dotnet utility tool and have a separate solution file which does not contain the xprojs, only the console application and build it with xbuild.

My main concern (over the fact that this isn't a convenient solution) is that if a bug in VS gets fixed which makes it impossible at the moment to add references to xprojs from csprojs as project reference, I will not be able to use it since my csproj projects will need to be separated.

Upvotes: 0

Views: 5374

Answers (1)

Martin Ullrich
Martin Ullrich

Reputation: 100761

Your situation is a mixture of known issues and work in progress for .NET and .NET Core tooling. The xproj is a msbuild-wrapper for project.json based projects that makes it work with Visual Studio and other project types. The targets are installed into the global MSBuild location and only included in the .NET Core Tooling installer for Visual Studio.

Your options are:

  1. The preview2/preview2.1 versions of the dotnet cli know how to build libraries and console applications for the .NET "Full" Framework. It also knows about mono on linux and unix and also has an environment variable (DOTNET_REFERENCE_ASSEMBLIES_PATH) which allows you to tell it where your xbuild's reference assemblies are if it can't find it.

    This means you could make all your projects project.json-based, even the projects just targeting the full framework. The resolution of the dependencies section in project.json will find other project.json-based projects in the same folder or in the specified project locations in global.json.

    As long as all your projects are only libraries and console application, this allows you to build everything on linux and mac. However, you will need multiple dotnet build calls, one for each project, as the dotnet tool does not know about solution files. In Contrast, dotnet restore will find all projects in a folder (or interpret global.json > projects afaik) and restore them all.

  2. The latest released msbuild versions know about .NET Core and can build a csproj that targets .NET Core. But it is a mixture of csproj and project.json that is little known / used and will probably soon go away in its current form. There is only a short guide on how to make it work with visual studio. You could try to make it franken-build with that targets but it will probably not work out well.

  3. The .NET Core tooling is moving to msbuild anyway. That means full support for .sln, .csproj and even custom msbuild projects as long as you have all the target/properties files. The MSBuild targets are distributed via a NuGet package (Microsoft.NET.Sdk) that will replace the globally installed msbuild targets for all c# project types. The dotnet sdk ships with a self-contained xplat build of msbuild and the project brings its target definitions via NuGet. As of now, these targets don't really work with mono but they want to make it work with mono or at least build for full framework on linux.

    So if you wait a little for .NET Core tooling to mature, you will probably be able to dotnet build your.sln. Maybe also mono's xbuild will pick up the new msbuild changes.

  4. 2-step build:

    Build all your libraries and .NET Core Apps with using project.json. Then package all libraries up as NuGet package using dotnet pack to a temporary location. The "classic" .NET projects can reference these packages via NuGet and restore using the temporary path as an additional source - either via a NuGet.Config file or a -s ../tmp-packages argument to nuget.

    This removes the possibility to code on both projects in VS and have newly added methods become available directly, but you can build all types of projects that xbuild supports (xamarin, web apps, ...).

Upvotes: 1

Related Questions