Sdk: "dotnet build" fails on non-Windows for projects that multi-target where Desktop is one of the targets frameworks.

[tannergooding]

Issue

If you have a project that multi-targets where one of Desktop is one of the target frameworks (such as <TargetFrameworks>net46;netcoreapp1.0</TargetFrameworks>), then the project will fail to build on non-windows with an error similar to:

Microsoft.Common.CurrentVersion.targets(1110,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.6" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Expected Result

The Desktop framework should be ignored and a warning should be printed indicated the framework in question could not be built.

This is a reasonable solution since the Desktop framework is not to be available on non-Windows.

Additional Details

This also impacts solutions where some projects target Desktop and some target .NETStandard or .NETCore and projects that only target Desktop.

[TheRealPiotrP]

@tannergooding dotnet build -f netcoreapp1.0?

696 , in part, tracks your broader suggestion of skipping invalid frameworks, but the above should atleast ensure you're unblocked.

[tannergooding]

@piotrpMSFT, that works for singular projects. That does not work when targeting an entire solution (which is perhaps a separate issue) where not every project targets the desired framework.

The command will fail with project.assets.json' doesn't have a target for '.NETStandard,Version=v1.6'. Ensure you have restored this project for TargetFramework='netstandard1.6' and RuntimeIdentifier=''. (or equivalent for whatever framework you built for).

The workaround would be to build all netstandard projects first, then to build all netcore or net projects, but that quickly becomes untenable.

[dasMulli]

This is a reasonable solution since the Desktop framework is not to be available on non-Windows.

I suppose that this will become an even bigger issue with .net standard / .net core 2.0 given that you may want to reference net* projects. Related: https://github.com/dotnet/sdk/issues/335

[TheRealPiotrP]

@tannergooding yea, the sln issue is MUCH more gnarly. I have a PR that aims to address it, both for RID and for TFM, but it's really invasive and I'm not sure if we'll be able to take it for 1.0.0 at this point.

[tannergooding]

@piotrpMSFT, Do you have a link?

Is it something akin to --skip-framework so that you can tell a build to explicitly skip a particular framework?

[Lexcess]

@livarcocc Is your update saying that this won't even make 2.0 now?

Is there any sort of workaround for sln till then? If this was regular MSBuild I assume we could just override the TargetFrameworks parameter from the command line but I don't think that is possible via dotnet.exe. I get that this is only a problem for more complex applications (i.e. not most Asp.Net core apps) but it is a migration blocker for us.

[MikhailArkhipov]

We need this to build https://github.com/microsoft/rtvs on Mac

[bruno-garcia]

Another reason to have the suggested --skip-framework is targeting net35 which won't be supported ever it seems:
https://github.com/Microsoft/msbuild/issues/1333

[ferdaarikan]

Any updates on this? Currently we have a solution that tests multi target netcoreapp2.0 and net47 and the main library targets netstandard2.0. This compiles and runs tests fine on windows. When on linux, compiling solution always fails regardless of the framework used.

[RusKnyaz]

I solved the issue by installing the Mono and configuring cli with command:
export FrameworkPathOverride=/usr/lib/mono/4.7.2-api

[bruno-garcia]

ReferenceAssemblies are available on nuget.org now. You can add it like this:

<PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.0-preview.2" PrivateAssets="All" />

With that you don't need to hack paths for the Mono ReferenceAssemblies:

[ferdaarikan]

I tried @bruno-garcia's suggestion and works for me. I can compile the projects targeting .net 4.7 on linux.

[wojteksbt]

Any update on that? Can I run multitargeted solution on macOS without performing changes in project files?

[CaCTuCaTu4ECKuu]

3 years has passed - no solution here. Even VS Code can process builds out of box, how can I purchase a product where simple problems persist for years...
I'm on windows btw and suggestion is to install vs or .net/mono. That's not a solution, I don't want to configure and install things I don't use and need and it's still causing problems on *nix

[tannergooding]

This is at least partially resolved via the existence of https://www.nuget.org/packages/Microsoft.NETFramework.ReferenceAssemblies.

Provided you are referencing it, you can successfully build the desktop targets even on Linux and MacOS.

There isn't a built-in mechanism to easily build everything but a specific list of target frameworks, but given the NuGet package and other workarounds available, it might not be necessary.

[CaCTuCaTu4ECKuu]

It's only one of problems. If I just need to build once I can run command in terminal and specify my target.
I have a application with single target that referencing multitarget library and when I run it's trying to assemble library for all target before building app project forbidding me to run/debug.
I was unable to find ANY solution for this case.
Initially I get here while was looking for solution of problem in Rider. Sorry for misinformation. You're fine guys no problem in VS or VS Code