sdk: Multi framework targetting not working with VS2017 RC
Steps to reproduce
- Install Visual Studio 2017 RC with .NET Core support.
- Create a new .NET Core project. Type seemingly does not matter, tested with Web MVC and Console application.
- Right click on project in Solution Explorer and select “Edit name.csproj”
- Find the line with the
TargetFrameworkelement. - Replace
netcoreapp1.0withnetcoreapp1.0;net452, as demonstrated in this .NET Blog post under the section Cross-targeting.
Expected behavior
- Project compiles for both
netcoreapp1.0andnet452as previously with the project.json format.
Actual behavior
Error occurs:
MSB4115 The "HasTrailingSlash" function only accepts a scalar value, but its argument "$(OutputPath)" evaluates to "bin\Debug\netcoreapp1.0;net452\" which is not a scalar value.
Environment data
dotnet --info output:
.NET Command Line Tools (1.0.0-preview3-004056)
Product Information:
Version: 1.0.0-preview3-004056
Commit SHA-1 hash: ccc4968bc3
Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 1
- Comments: 18 (7 by maintainers)
My suggestion is to remove the distinction. Why have two element names for a single purpose? It just adds unnecessary complexity. The new format is supposed to be simplified.
@MartinJohns
The original issue was definitely using
TargetFrameworkto specify multiple frameworks instead ofTargetFrameworks(plural). The blog post has that right.There are two other issues:
Currently, you do need to specify a RuntimeIdentifier if one of your targets is the full .NET Framework and you are building an exe. We are looking to improve this, see https://github.com/dotnet/sdk/issues/396
You must condition the .NETCoreApp package reference to only the netcoreapp1.0 build as the package is not compatible with net452. This is also being improved with https://github.com/dotnet/sdk/pull/450 which will make the package ref implicit and remove you from having to condition it yourself.
(1) above explains the RuntimeIdentifier error you’re seeing. (2) might be the “invalid restore input” you’re seeing, but I’m seeing much clearer nuget errors on newer than RC bits:
For (1), here is how the main property group should look with both RuntimeIdentifer and TargetFrameworks set:
For (2), here is how the NETCore.App package ref should be conditioned
Let me know if you’re still seeing errors after applying the above and please share the full .csproj that isn’t working for you.
Ignoring the name confusion, let’s imagine we remove the concept of “TargetFramework”, what condition would you write to have an item (say a package or project reference) only apply to a single framework?
@SzymonSasin After that I was able to compile, and start server (
dotnet run) but it collapsed after http request.Hey @nguerrera,
I’ve indeed overlooked that there’s a plural version in the blog post. Performing the changes that you mentioned allowed me to compile the project. But the way to this has been very rocky - I think the mistakes I made are very easily done and the tooling should at least inform me about solutions to the most common mistakes. That there’s no schema (after the latest VS update) doesn’t help much, and the XML editing experience is not great either (e.g. when I rename an opening tag it doesn’t rename the closing tag).
Here’s my updated csproj file:
It compiles fine, but when I press F5 I get the following error: “Unable to run your project. The “RunCommand” property is not defined.”
Executing the net452 version works. Trying to execute the netcoreapp1.0 version fails:
Any advice on this?
Additionally, can you please expand on these questions?
RuntimeIdentifier? Yes, I’ve triedRuntimeIdentifiers. 😃I guess the suggestion here is to add a better error message? If so, this should be tracked in dotnet/sdk, since that is where the errors for this would come from.
The migration to MSBuild XML schema only give to us bad user experience, i not like vs2017… i prefer vs2015 with json project format, easy and friendly. Nobody try to learn MSBuild schema before… the people are trying to do the things like with json project format and MSBuild is ugly.
I agree this is rocky and I apologize for that. FWIW, cross-targeting exe projects is significantly more complicated by these RID issues than cross-targeting libraries. We still need to do better on the docs and diagnostics, but let me try to answer your questions here.
The failure to load hostpolicy.dll is because we set an x86 RID for all outputs and we’re trying to run on x64 dotnet.
For defining multiple RIDs, nuget restore understands
RuntimeIdentifiers(plural), but everything else requires that you specify one at a time. There is https://github.com/dotnet/sdk/issues/414 to reconcile this but in the meantime, you can get to a state that works for this project by specifying the full set of RIDs statically for restore and only setting a single RID when you’re actually building for desktop.From there: