Bad error message if Microsoft.NETCore.App isn't a "platform" in the project.json

[clairernovotny]

Steps to reproduce

Create a new project/exe that uses the netcoreapp1.0 framework.

Add a dependency "Microsoft.NETCore.App":"1.0.0-rc2-24015"

Expected behavior

A better error saying that the type needs to be a platform. The entry should be
"Microsoft.NETCore.App": {
"version": "1.0.0-rc2-24015",
"type": "platform"
}
And that fixes the error correctly.

Actual behavior

Errors that suggest putting in RID's

Severity    Code    Description Project File    Line    Suppression State
Error       Can not find runtime target for framework '.NETCoreApp,Version=v1.0' compatible with one of the target runtimes: 'win10-x64, win81-x64, win8-x64, win7-x64'. Possible causes:   Dapper.Tests    C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets  241 
Error       1. The project has not been restored or restore failed - run `dotnet restore`   Dapper.Tests    C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets  241 
Error       2. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 'runtimes' section.   Dapper.Tests    C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets  241 

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc2-002418)

Product Information:
Version: 1.0.0-rc2-002418
Commit Sha: a8686e5

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14316
OS Platform: Windows
RID: win10-x64

[Petermarcu]

The other option here is that you could build a standalone application by providing runtimes. This would create a self-contained application. Perhaps a 3rd option in the error (maybe it should be first) that says the package may be a platform?

[guardrex]

I don't think "A better error saying that the type needs to be a platform." is accurate. It's entirely reasonable to use Microsoft.NETCore.App without "type": "platform" in a standalone project. In which case, the exception line ...

Error 2. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 
'runtimes' section.

... is fairly clear. I agree though with the sentiment of @onovotny that this is bound to come up and confuse devs new to the application types.

Perhaps, the exception could be a bit more explicit:

Error 2. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 
'runtimes' section. If the project does not include '"type": "platform"' with the 
'Microsoft.NETCore.App' dependency and this is a self-contained standalone application, 
list one or more of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 'runtimes' section of 
'project.json', restore the project, and use 'dotnet publish --runtime {RID}' to obtain 
executable output.

... wordy, yes, but utterly clear what needs to be done. Outside of that, another option would be for exceptions to hotlink to stable documents ... e.g., this would link directly to @blackdwarf's upcoming application types document, which also makes it clear what the dev should do.

[NinoFloris]

So hooking into this, how would one have both options on at the same time?
E.g. I would like to locally, for devs, have "platform", but at build time I want to have self contained publishes.

Currently I either have to switch it to build when I need to produce a production build or have all the different development machine runtimes in the project.json.

Is there a good story for this?

[davidfowl]

@NinoFloris no, there's no good story for that. Here's a question though, why not just develop standalone?

[NinoFloris]

@davidfowl I'm not sure what you mean by standalone, by rid's? as in "type": "build"?

Look at it like this, I will only deploy to debian flavors, and preferably a fat dist with everything included. I will not deploy to osx, windows, linuxmint, etc. so why add all of them in my config?
However I may want to bytecode compile on those, let me take care of the existence of a runtime.

Why will it not just build the stated runtimes but does it complain about your current runtime not being stated?
Because who cares that my current runtime is not in the project.json, let me handle that, and yes I know about -r and I understand that for dotnet run this error message would be desirable.

Another option that pops into my head would be a dotnet build switch for a plain bytecode / platform compile, just ignore all runtimes. Having to step down to the compiler to do just this is brutal.

As little config ceremony as possible is the goal right?

[hal-ler]

What about separating shared platform and standalone apps into different TFMs? This makes the decision clear both for the CLI and the developer and the error message could be specialized for the TFM. It also allows a developer to include both options into their project.json at the same time with no confusion (as long as the TFMs are clearly named).

I was playing around with this option around a month ago when netstandard was also runnable and it seemed to work well. I could build standalone versions for a set of runtimes and still have a back-up shared platform app for everything else supported by the CLI.

[hal-ler]

Developer tools are another scenario where both shared platform and standalone builds are desirable in my view. For example your build system might rely on NuGet, ScriptCs and some other tools. Instead of downloading a 20MB standalone version for all of these (with replicated copies of all platform libraries), one would first install the SDK (as it is needed for the build) and just download the shared platform versions of these tools. However the standalone versions of these tools are also preferred to exist in the wild for other applications.

[NinoFloris]

Yeah, I also thought about that. It's not really good as runtimes are something in the background and are not part of the real dependencies. So it does not make any sense to have different TFM's for portable and standalones.

[NinoFloris]

Hah our answers just crossed.

I really do think that there should be some way to just create a portable but I don't know enough about all the constraints and underlying thought behind the current model to know what the options are.

I hope @davidfowl can spare some of his time to explain why it is as it is.

[macakmujo]

thanks it works for me, :)
I got this bug when transfering my .net core solution to other laptop, I changed my
global.json from "version": "1.0.0-preview2-003121" to "version": "1.0.0-preview2-003131"
and got error, what does this setting "type": "platform" do exactly ?

[iberodev]

As per this documentation

The type: platform property on that dependency means that at publish time, the tooling will skip publishing the assemblies for that dependency to the published output. You don't need these since they will be installed with .NET Core on the targeted machine.

I am getting this error when trying to deploy for first time a web app with "version": "1.0.0-preview2-003131" in global.json and

"Microsoft.NETCore.App": {
      "version": "1.0.1",
      "type": "platform"
    }

and

"frameworks": {
    "netcoreapp1.0": {
    }
  },

in project.json

Am I to assume that this version 1.0.1 is not installed in Team Services host?

[Tgeo]

Hopefully this helps someone, I ran into this error message after upgrading some nuget packages in an ASP.NET Core project.

My project.json file had this line before nuget upgrade:
"Microsoft.NETCore.App": { "version": "1.0.1", "type": "platform" }

Then after upgrade, that line was removed and this was added:
"Microsoft.NETCore.App": "1.0.1"

Since this now doesn't list the platform (the focus of this GitHub issue), you just need to revert the newly added line to the previous block (with the "type": "platform").