Sdk: 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: a8686e58fc

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").

[ricardo-cantu]

@Tgeo This is exactly what happen to me. I wonder if this needs to be raised as an issue on some other forum as well.

[mkalkere]

When i am trying to build the dotnetcoreapp1.0 as SCD by removing "type":"platform" and by adding
"runtimes": {
"win10-x64": {},
"osx.10.10-x64": {}
}

in project.json i get the below error.

C:\Users\Mallikh\SCD>dotnet build -r win10-x64
Can not find runtime target for framework '.NETCoreApp,Version=v1.0' compatible with one of the target runtimes: 'win10-x64'. Possible causes:

1. The project has not been restored or restore failed - run dotnet restore
2. The project does not list one of 'win10-x64' in the 'runtimes' section.
3. You may be trying to publish a library, which is not supported. Use dotnet pack to distribute libraries.

can i know what i am doing wrong here please?

[blackdwarf]

@ricardo-cantu @Tgeo this is a known Nuget tooling issue, I believe it is being tracked on Nuget/home.

@mkalkere I just tried a repro on the default template for a console app and it worked. Some questions:

1. Did you restore the project after adding the runtimes node in the project.json?
2. If the above doesn't solve it, can you paste your entire project.json in here so we can review?

[mkalkere]

issue got solved when i changed the version from 1.0.1 to 1.0.0

"Microsoft.NETCore.App": {
"version": "1.0.0"
}

[mkalkere]

@blackdwarf yes i did restore the project after adding the runtimes.

when i changed the version to 1.0.0 it worked.

[blackdwarf]

@mkalkere did you install the 1.0.1 framework?

[mkalkere]

@blackdwarf yes i have installed 1.0.1 framework.

and now i am trying the same thing again. but i am facing the same problem.

this is the complete project.json :

{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"emitEntryPoint": true
},
"dependencies": {},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1"
}
},
"imports": "dnxcore50",
"runtimes":{
"win10-x64":{},
"osx.10.10-x64":{}
}
}
}
}

[mkalkere]

@blackdwarf : Issue was not with the version it was the location at which the runtimes was placed.

it works fine with the below project.json:

{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"emitEntryPoint": true
},
"dependencies": {},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1"
}
},
"imports": "dnxcore50"

}

},
"runtimes":{
"win10-x64":{},
"osx.10.10-x64":{}
}
}

[AlanBarber]

Updated my nuget packages on a asp.net core website and ran into the same problem with builds... I followed what @Tgeo said here and that fixed the builds.

I did upgrade from Microsoft.NETCore.App 1.0.0 to 1.0.1.

[hksingh]

@Tgeo workaround by adding platform fixed the issue.

[TheRealPiotrP]

Since this is a project.json issue and there is a workaround available I'm closing this issue.

[wilfredogr]

How do you close if the solution is not clear? I have the same issue with ASPNetCore 1.1.0. I didn't change anything because it is supposed Visual Studio 2015 creates everything from the template I'm using (MVC) right? So how do you determine is JSON problem? Users don't create this file.

This is my project.json:
{
"dependencies": {
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.0.0-preview2-final",
"type": "build"
},
"BundlerMinifier.Core": "2.2.306",
"Microsoft.ApplicationInsights.AspNetCore": "1.0.2",
"Microsoft.AspNetCore.Diagnostics": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.1.0",
"Microsoft.AspNetCore.Routing": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.StaticFiles": "1.1.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0",
"Microsoft.Extensions.Configuration.Json": "1.1.0",
"Microsoft.Extensions.Logging": "1.1.0",
"Microsoft.Extensions.Logging.Console": "1.1.0",
"Microsoft.Extensions.Logging.Debug": "1.1.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0",
"Microsoft.NETCore.App": "1.1.0",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.1.0",
"Microsoft.EntityFrameworkCore.SqlServer": "1.1.0",
"Microsoft.EntityFrameworkCore.Tools": "1.1.0-preview4-final",
"Microsoft.EntityFrameworkCore.Design": "1.1.0"
},

"tools": {
"Microsoft.EntityFrameworkCore.Tools.DotNet": "1.0.0-preview3-final",
"Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"
},

"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
]
}
},

"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},

"runtimeOptions": {
"configProperties": {
"System.GC.Server": true
}
},

"publishOptions": {
"include": [
"wwwroot",
"*/.cshtml",
"appsettings.json",
"web.config"
]
},

"scripts": {
"prepublish": [ "bower install", "dotnet bundle" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}
}

[blackdwarf]

@wilfredogr the solution is to add type: platform to the Microsoft.NETCore.App dependency, like so:

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

[Lukenbill]

Still an issue, Tego's fix works...not sure how this "closes the issue" though

[CodingSamurai]

I agree with @wilfredogr this issue should NOT be closed. First of all, the underlying issue (that a nuget update suddenly breaks a working .NET Core Website by removing "type": "platform") is not fixed and is a critical issue.

Secondly the error message is crap as it's not clear that a nuget upgrade may have simply broken the project.json. So a much better error message is needed, perhaps something that also describes what it means to be a "type": "platorm" (i.e. this is the default needed for a .NET Core Website) would help save people from wasting more than 10 minutes on something NuGet/Visual Studio breaks.

[gortok]

If you update Microsoft.NETCore.App to 1.1.0 (via Nuget) either in VS2015 or via the command line (Mac or Windows), it removes the following:

   dependencies: {
-         "Microsoft.NETCore.App": {
-         "version": "1.1.0",
-         "type" :  "platform" 
       }
   }

and replaces it with this:

 dependencies: {
    "Microsoft.NETCore.App" : "1.1.0",
 }

To resolve this issue, put the type and version properties back in and make the dependency an object instead of a string.