This is pretty cool and I was excited to hear about it.
But this release also changes the way unit testing integrates with the tooling, so now my suite of 1000+ nunit tests won't run via the 'dotnet test' command, nor in visual studio 2017.
If not for that, we would have upgraded today. Eventually the nUnit team will release a test runner that works with the new tooling, but in the meantime, we will stay on preview2 of the tooling & vs2015 where our tests work.
I think you are right, the change likely happened in one of the preview versions leading up to this release. I didn't notice any documentation on it for any of the releases, though I could have easily missed it.
You make it sound like this change was a snap decision. It's been known for at least 10 months now that project.json was going away. All the documentation I stumbled upon on github also made this clear.
While I would love a simpler, more readable project file, I understand that the tooling already out there relying csproj format, probably makes it not worthwhile changing.
>You make it sound like this change was a snap decision. It's been known for at least 10 months now that project.json was going away. All the documentation I stumbled upon on github also made this clear.
Great and in those 10 months there was no alternative but to use the soon to be deprecated projects. And they released a 1.0 product like that.
Someone from Microsoft commented unofficially that there was pressure from partners who were using .NET Core in production to release a stable - which was very obvious and they put them self in a spot where they had to support a deprecated project.json system since people are using it in production while also developing the new system. Whoever decided on the release timelines dropped the ball.
Well for the last 4 months, MSBuild alpha has been out with the option to use "dotnet migrate" to migrate a project.json to a project.csproj file.
The other 6 months I agree has left people in a limbo. Only people following the discussions closely would have an idea of which direction they were going.
There's still a bunch of fundamental changes to how the XML-based MSBuild files work, such as the addition of wildcards and recursive includes, so expect a wait for the rest of the ecosystem to catch-up.
Note that the move back to MSBuild from Project.json was prompted by pragmatism rather than ideology - I suspect the JSON-camp are biding their time before putting forward another proposal.
Is there any reason that I should care about .Net Core yet over .Net 4.6 if I'm a Windows only developer or should I just wait for things to settle down?
If you're Windows-only then there's no need to worry about Core. There may be some web optimizations there, but I'm pretty sure most of those are targeting Linux distributions.
most of the nuget operations (restore, pack, push) can be performed using dotnet.exe that ships as part of .NET Core Tools 1.0 on any platform.
If you are facing any specific issue or need any nuget related help, please file an issue on https://github.com/nuget/home/issues and will do our best to respond asap!
There are basically three major entities being versioned somewhat independently:
- The .NET Core 1.0 runtime, which is now at 1.0.4.
- The .NET Core 1.1 runtime, which is now at 1.1.1
- The .NET Core SDK/tools, which is now at 1.0.1. The version released with VS2017 is 1.0.0 because the most recent update barely missed the VS2017 train leaving the station.
Everything uses semantic versioning, i.e. major-minor-patch, with the associated rules around breaking changes and new functionality.
The 1.0 and 1.1 runtimes are both maintained for compatibility/supportability reasons - if you have an app that runs on 1.0, you can confidently take advantage of 1.0.4 immediately.
What you see when you run dotnet --version is the version of tooling you are using. The tools can output both 1.0.x and 1.1.x binaries. The tools hitting 1.0.0 yesterday was the biggest announcement, because it's been a circus - multiple "preview" releases, each with multiple point releases, as the CLI and functionality rapidly changed and (most importantly) support for the .csproj format was brought in. They dropped support for project.json/.xproj somewhere around preview4, but they kept maintaining older versions of the tools too to give people time to migrate away. Now that they're at 1.0.x, it's official and can be shouted from the rooftops: project.json/.xproj are gone, fully dead, no longer supported, don't use them, migrate away from them if you still have them, get rid of any old versions of the tools you have, move to the 1.0.x tools and don't look back.
There are basically two "families" of installers/packages/Docker images - those with the SDK and a version of the runtime, and those with only a version of the runtime. All installers/packages/Docker images are labeled with the runtime version number, because all of the SDK packages include the newest version of the tools, and the tools can target both the 1.0.x and 1.1.x runtimes.
You are clearly missing other dotnet dependencies. Apt output is mentioning dotnet-sharedframework-microsoft.netcore.app-1.1.1. Anyway I personally would go with docker image, so you won't mess up your system. I've tried microsoft/docker image om example from that arcticle and was successful.
Through P/Invoke, sure. But WinForms, WPF, and UWP (and Silverlight, and XNA) are not part of .NET Core by-design. Though I assume someone will port Xamarin over, if they haven't done already.
I'd love to see SDL support so OpenRA can have another build target.
It would be nice to see Winforms and WPF pulled out into their own projects on top of .Net core. Both could do with some cross platform open source love.
WinForms is, unfortunately (in my opinion), a hack on top of Win32/hWnds, the fact that every Control wraps a top-level hWnd window is a source of performance issues. It needs a fundamental re-thinking... but Xamarin Forms is a better concept, it just needs a Win32 target.
But this release also changes the way unit testing integrates with the tooling, so now my suite of 1000+ nunit tests won't run via the 'dotnet test' command, nor in visual studio 2017.
If not for that, we would have upgraded today. Eventually the nUnit team will release a test runner that works with the new tooling, but in the meantime, we will stay on preview2 of the tooling & vs2015 where our tests work.