I have downloaded and installed the latest .Net Core from https://www.microsoft.com/net/download/core, but after the installation I opened up a cmd prompt and > dotnet --version still shows 1.0.0-preview2-003131
Could someone explain what I'm missing here please?
Update for new comers - 2018-08-01
The original answer was highly targeted at the understanding that the OP had with context at the time (2016). Core has come a long way in the last few years so if you are coming at this now, you might not even know what a global.json and SDK pinning is because it is no longer part of the default template when creating a new project.
Essentially, the CLI will use the highest installed version of .Net Core by default. However, should you choose to, you can dictate a specific version of .Net Core to be used by all apps in nested folders by creating a global.json and setting a specific SDK version. If you do this, you'll get errors when the incorrect version is installed.
The Core team is pretty good about not causing any breaking changes and as described above have opted to remove pinning by default. This actually recently caused some issues for some people because they had not pinned to the version they had built their app against. I personally prefer to pin to the version I'm building against and update it explicitly.
To add extra confusion, the SDK versions don't line up with the version numbers of the .Net Core releases so you really have to "just know" which version to use for what.
For anyone coming to this answer now, the problem that the OP had here was that he didn't realize the global.json was pinning his version nor why the version was so different than the .Net Core version.
Original answer:
The command line is context specific. My guess is you are running from a project that has a global.json in a parent folder that references an older version.
Old Global.json
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-preview2-003131"
}
}
Change your global.json to:
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-preview2-1-003177"
}
}
This change will make the dotnet cli respect the new version in your projects so you can choose when to upgrade your projects. This is how you can have multiple versions of dotnet on your machine and not have to update every one of your projects at once.
[Edit - SDK version confusion]
Just to note, the SDK version you have installed is indeed the 1.1 version of the SDK. The installer indicates the new version of the SDK for 1.1. I've captured a screenshot below.
Related
When I install Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation in a Web project and in Startup add :
services.AddMvc().AddRazorRuntimeCompilation();
,the project does not run and the error is:
the project must provide a value for configuration
my .NET-Core version is 3.1
How can this be fixed?
There are some GitHub issues with this problem and some solutions that have worked for people. That said I would check to see that all NuGet packages are on versions supported by .NET Core 3.1. At this particular moment that means not too new so as to only work with .NET 5 and not too old so as to only work with Core 2.2.
Otherwise, someone suggested restarting VS.
https://github.com/dotnet/sdk/issues/9932
You may also try deleting Microsoft.AspNetCore.Razor.Design from the CsProj file per this duplicate question
I'm trying to understand how the roll-forward mechanism with Microsoft.AspNetCore.App is supposed to work along with other nuget packages.
My understanding so far is that any time I publish my app, .netcore will automatically publish the app on the latest patched version that I have installed. This doesn't sound like a good practice to me. I think the application should be deployed on the .net version that it was developed on.
I recently ran into a problem where my build server has a newer SDK installed than I have on my development machine, so it tried to publish the app with a newer .netcore version.
This caused the build to break with the following error:
error NU1605: Detected package downgrade: Microsoft.EntityFrameworkCore.Design from 2.1.8 to 2.1.4. Reference the package directly from the project to select a different version.
I have explicitly specified that I want version 2.1.4 of Microsoft.EntityFrameworkCore.Design because that was the latest version that was available when I originally developed the application.
I feel like I'm missing something here. Am I supposed to make sure that I always
have the same SDK installed locally as the build server and that all of my apps are updated to the latest SDK every time I need to make a change? What if a co-worker wants to write a .netcore app targeting a newer version of the framework so they request that a new SDK be installed on the build server? Surely I shouldn't have to also update my app to the latest patch version.
You experienced the problem because when you reference the versionless Microsoft.AspNetCore.App you shouldn't reference packages which already are pulled in by the metapackage.
Because the metapackage already contains Microsoft.EntityFrameworkCore.Design and you specified a hard version you got a version conflict.
This usually happens when you have one project with the metapackage in another (for example test project) have a specified version. What happens then is that when building it will determine the highest version and use that but when it gets to the test project it will need to downgrade (because of the specified version) and will throw a build error. The recommended way until 3.0 is to add <Project Sdk="Microsoft.NET.Sdk.Web"> to the test project and also use the metapackage.
As far as I know it works like this: When you reference Microsoft.AspNetCore.App it will take the lowest possible version it can. So if for example your targetframework is netcoreapp2.1 then it will take 2.1.1. When it builds it will look what the highest possible version is of the shared framework you have installed for and use that. If you have the following runtimes installed: 2.2.0, 2.1.5, 2.1.12 it will roll forward to 2.1.12. There are some additional roll forward policies having to do with the minor (if its a preview version or not ect.) but those only happen when it can't find a runtime corresponding to the major and minor version.
See also: https://github.com/aspnet/AspNetCore/issues/3292 and https://github.com/aspnet/AspNetCore.Docs/issues/6430
I've been working on a software for a while and always executed it using dotnet run. Today, I decided to install VS 2017 and after that (still not entirely sure if it's the root cause, though), I can't run my software anymore.
The pre-existing project is nowhere near the project I opened with VS 2017 so the only collision I suspect might be due to the Core version being changed. To be sure, I re-ran the installation from the page, the latest version.
dotnet --version
1.0.0-preview4-004233
I notice that when I execute dotnet new, the directory get a xxx.csproj file and not project.json and I've read somewhere that MS is going to drop support for it.
What can I do to get the pre-existing project running again? I'm kind of stuck in the middle of the whole thing and googling gave me precisely nothing. Apparently, I'm the first dude to do this stupid upgrade (if it's because of that to begin with).
What can I do to get the pre-existing project running again?
Add a global.json to your project or solution's root directory, with an SDK property that points at the previous SDK. For example:
{
"sdk": {
"version": "1.0.0-preview2-003131"
}
}
View the SDK versions that you have installed like this:
PS> dir 'C:\Program Files\dotnet\sdk\' -name
1.0.0-preview2-003131
1.0.0-preview2-003133
1.0.0-preview2-003156
1.0.0-preview2-1-003177
1.0.0-preview3-004056
Anything with preview2 will use project.json, anything with preview3 (or above) will use xxx.csproj.
See also: Announcing .NET Core Tools MSBuild “alpha” > Side by side install.
I am new to this area. I already upgraded my VS2015 with update 3. So now I have: .Net Core 1.0.0 with preview tool 2 installed.
Then I use VS2015 to create a new .Net Source project (class library). I have copied some existing .net 4.6.1 code to the new place and compiled error as expected. Then I use "porting analyzer tool"(https://learn.microsoft.com/en-us/dotnet/articles/core/porting/index) to compare and it did give some suggestion how to use the new way in .Net Core.
But there are still few class missing and cannot compile, like 'TypeDescriptor' or 'NullableConverter' etc. Then I googled and someone from Github say they already added these feature but I still not sure why I still get compilation error.
I also noticed that my class libary project has a project.json file as:
"frameworks": {
"netstandard1.6": {
"imports": "dnxcore50"
}
}
I foundn if I remove the 'netstandard1.6' one but change to:
"frameworks": {
"net461": {}
}
All the compilation error gone, but I could guess it's NOT .Net core project anymore, and more likely as a standard .Net 4.6.1 project.
So basically I'd like to ask:
Why developer from Github saying that is fixed already but I still couldn't find/compile those classes in my project (e.g. TypeDescriptor : https://github.com/dotnet/corefx/issues/8262)?
Some sample also puts both 'net461' & 'netstard1.6' or 'netcoreapp1.0' under 'frameworks' in project.json file. What's the purpose for that?
If I just use 'net461' for the only framework, there seems no difference to traditional .Net Framework 4.6.1 project. Am I correct?
Thanks a lot!
Install package System.ComponentModel.TypeConverter and you are good to go with .NET Core project.
For building different output (binaries) each of which targeting different platform. net461 for applications which should run on (full) .NET Framework (under Windows or Mono). netcoreapp1.0 used for app which should be run under .NET Core. netstandard1.6 (avoid using netstandard1.5 and netstandard1.6 by the way - use previous versions) used for portable class libraries, which are supposed to run under different platforms: (full) .NET Framework, .NET Core, Xamarin, Universal Windows App, etc. You may read more about here and here.
Absolutely.
I've been playing around a bit with MVC 6 and a few other of the newer web development tools (Angular 2.0, etc.) and I've run into a bit of a problem setting up a webpage that utilizes MSMQ. For reference, I'm using VS2015 Update 2, which I believe is still RC1.
When I first tried to mess with System.Messaging in general, it kept having issues with Nuget Packages (which was a bug with Update 2, it required an update to the Nuget service) and wouldn't reference the package properly. After playing with it some more, I eventually got the package referenced (had to do it manually in my solution explorer) and any errors Visual Studio originally would have detected seemed to be resolved. Now, I get errors on build stating that it can't find a reference (to System.Messaging). I'm not sure if this is an issue with my solution or if it is something that VS2015 is having issues with.
From what I've read (I'm coming from WCF), MVC 6 is a much better way to handle these sort of situations so I'm trying to make the switch but this has me completely dead in my tracks.
If there is any specific way I need to do messaging queues in MVC 6/ASP.NET Core 1.0 I have not found it, so any sources or advice on this is greatly appreciated.
Unless you specifically need to target multiplatform with the .net core DNX, you could still write your app with all of the new hotness features of MVC6 and the DNX, but still target the classic full .Net 4.5.1 (or whatever version you need).
Open your project.json file and find the "frameworks" portion of it, and remove the reference to "dnxcore50" so that the final section becomes the following.
"frameworks": {
"dnx451": { },
},
At that point you should be able to reference System.Messaging without issue.