"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: #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.