.NET Core can't build AnyCPU exes
See original GitHub issue(I may be misunderstanding how things are supposed to work here; apologies if this is more of a question than a bug.)
Consider the following project file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net47</TargetFramework>
<PlatformTarget>AnyCPU</PlatformTarget>
<RuntimeIdentifier>win</RuntimeIdentifier>
</PropertyGroup>
</Project>
This project builds/runs correctly and generates an AnyCPU exe. Now change the target framework to .NET Core:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<PlatformTarget>AnyCPU</PlatformTarget>
<RuntimeIdentifier>win</RuntimeIdentifier>
</PropertyGroup>
</Project>
This project generates a build error: Project is targeting runtime ‘win’ but did not resolve any runtime-specific packages for the ‘Microsoft.NETCore.App’ package. This runtime may not be supported by .NET Core.
If RuntimeIdentifier is win-x86 or win-x64, it builds, but at publish time I suspect (though couldn’t confirm) that the assemblies it generates are not AnyCPU, even though the Platform in the project file was explicitly AnyCPU.
I believe .NET Core still supports AnyCPU for DLLs. But does it really support AnyCPU for EXEs? It looks like today there isn’t a clear answer - you can say you’re building an AnyCPU exe, but you don’t actually get an exe unless you do publish on a Self-Contained Deployment by using a RuntimeIdentifier, and no AnyCPU RuntimeIdentifier (aka just “win”?) is currently supported.
How should this work? Should .NET Core allow creating AnyCPU EXEs? If not, should the build generate an error when OutputType=Exe and Platform=AnyCPU?
Issue Analytics
- State:
- Created 6 years ago
- Comments:7 (4 by maintainers)
Top GitHub Comments
FWIW, I think the separation between build & deployment is one of the bigger disconnects between .NET Core and it’s use of MSBuild - things like PlatformTarget were largely the equivalent ways to set things in the past during build time that .NET Core now wants to handle at deployment time. The fact that .NET Core MSBuild projects keep most/all the same build-time mechanisms and then add (potentially duplicate or conflicting) deployment-time mechanisms leads to some surprising/inconsistent behavior. I think this overall design issue is largely capture by #1553, and this is one of many manifestations, but let me know if there’s a better way to provide input on the broader difficulties here.
Understood. However, is there a need for PlatformTarget to control that knob? If we only had RuntimeIdentifier(s), would that achieve the same result? (Perhaps that’s equivalent to saying AnyCPU is the only PlatformTarget, but you can have architecture-specific RuntimeIdentifiers.)