-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad error message if Microsoft.NETCore.App isn't a "platform" in the project.json #5801
Comments
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? |
I don't think "A better error saying that the type needs to be a platform." is accurate. It's entirely reasonable to use
... 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:
... 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. |
So hooking into this, how would one have both options on at the same time? 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? |
@NinoFloris no, there's no good story for that. Here's a question though, why not just develop standalone? |
@davidfowl I'm not sure what you mean by standalone, by rid's? as in 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? Why will it not just build the stated runtimes but does it complain about your current runtime not being stated? Another option that pops into my head would be a As little config ceremony as possible is the goal right? |
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 I was playing around with this option around a month ago when |
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. |
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. |
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. |
thanks it works for me, :) |
As per this documentation
I am getting this error when trying to deploy for first time a web app with
and
in Am I to assume that this version 1.0.1 is not installed in Team Services host? |
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: Then after upgrade, that line was removed and this was added: 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"). |
@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. |
When i am trying to build the dotnetcoreapp1.0 as SCD by removing "type":"platform" and by adding in project.json i get the below error. C:\Users\Mallikh\SCD>dotnet build -r win10-x64
can i know what i am doing wrong here please? |
@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:
|
issue got solved when i changed the version from 1.0.1 to 1.0.0 "Microsoft.NETCore.App": { |
@blackdwarf yes i did restore the project after adding the runtimes. when i changed the version to 1.0.0 it worked. |
@mkalkere did you install the 1.0.1 framework? |
@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 :{ |
@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:{
}, |
@Tgeo workaround by adding platform fixed the issue. |
Since this is a project.json issue and there is a workaround available I'm closing this issue. |
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: "tools": { "frameworks": { "buildOptions": { "runtimeOptions": { "publishOptions": { "scripts": { |
@wilfredogr the solution is to add "Microsoft.NETCore.App": {
"type": "platform",
"version": "1.1.0"
} |
Still an issue, Tego's fix works...not sure how this "closes the issue" though |
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. |
If you update
and replaces it with this:
To resolve this issue, put the |
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
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
The text was updated successfully, but these errors were encountered: