Announcing .NET Core Tools 1.0 | Hacker News Reader

Announcing .NET Core Tools 1.0

blogs.msdn.microsoft.com

148 pointsWadeJohnson42 comments

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.

Is the change documented anywhere? I looked through all the release notes and couldn't find it.

It looks like it wasn't this release that changed the testing. The comments about nUnit not working are from November / January / February:

https://github.com/nunit/dotnet-test-nunit/issues/91

https://github.com/nunit/dotnet-test-nunit/issues/101

https://github.com/nunit/nunit3-vs-adapter/issues/305

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.

Yep, they are working on it, but won't say when it'll be released.

I'm done with endless refactoring of .NET Core updates.

The reality is they shipped RCs with 1.x version numbers.

I will be back to reassess after Core 2.0 gets a minor update.

Microsoft suck at versioning. Progress is great, but we feel tricked.

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.

They were pretty clear from the early days that this was WIP, did you never watch a MS presentation?!

I agree that the talk has been from MS that this was a moving target and not ready for anything close to production till after 1.0.

Hopefully this will be the much-awaited end of all of the tooling confusion around the project.json to csproj change.

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.

The Microsoft dev making the blog post is certainly explicitly saying so in the comments. :)

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.

The only thing that has really bothered me about .NET Core is I haven't been able to figure out how to get NuGet to run properly on Linux.

> I haven't been able to figure out how to get NuGet to run properly on Linux.

Use the "dotnet" binary and just run "dotnet restore"? This will restore whatever packages your project references-

Or are you thinking about pakage-management, as in searching for and installing new packages?

The latter. Installing works fine. Is there a way to not have to manually add packages?

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!

Adding to rohit -> on linux you can try out dotnet binary available from https://github.com/dotnet/cli.

Still dont get it at all. I installed VS2017 today, dotnet --version = 1.0.0

I go to the dotnet core website, download a new sdk and install. dotnet --version = 1.0.1

Oh and the file is called "dotnet-1.1.1-sdk-win-x64.exe" Notice yet another version number.

Same thing on Linux. tar.gz has 1.1.1 in the name, installed version is 1.0.1

I didn't really get it until yesterday.

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.

Tried installing the Ubuntu 16.10 deb, but getting this error:

  $ sudo dpkg -i dotnet-sdk-ubuntu.16.10-x64.1.0.1.deb 
  (Reading database ... 408184 files and directories currently installed.)
  Preparing to unpack dotnet-sdk-ubuntu.16.10-x64.1.0.1.deb ...
  Unpacking dotnet-dev-1.0.1 (1.0.1-1) over (1.0.1-1) ...
  dpkg: dependency problems prevent configuration of dotnet-dev-1.0.1:
   dotnet-dev-1.0.1 depends on dotnet-sharedframework-microsoft.netcore.app-1.1.1; however:
    Package dotnet-sharedframework-microsoft.netcore.app-1.1.1 is not installed.

  dpkg: error processing package dotnet-dev-1.0.1 (--install):
   dependency problems - leaving unconfigured
  Processing triggers for man-db (2.7.5-1) ...
  Errors were encountered while processing:
   dotnet-dev-1.0.1

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.

Yes, I understand that I am missing a dependency. What I don't understand is how I am supposed to get that dependency.

There's instructions for installing from their repos elsewhere on the site: https://www.microsoft.com/net/core#linuxubuntu

    sudo apt-get install dotnet-dev-1.0.1

works if you have the partners repository enabled.

https://i.imgur.com/2uLUNH1.png Why is Microsoft serving Panasonic.jp SSL certificate ?

They're both on Akamai's CDN. I'd suspect the trouble lies in akamai's setup somewhere.

Vault7 at work :-)

It's just for you. Problem with your ISP? I am seeing proper SSL connection

Cert looks good on my end. Maybe someone MITM you?

I saw CONSOLE and ASP profiles .NET Core profiles. Can .NET Core also be used to develop GUI apps?

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.

I thought Xamarin Forms was for phones?

Not at this stage, if you don't want some sort of pre-beta 1-man project.

Microsoft is not investing so it will have to be community managed.

There is already a community driven WPF type library. I can't find it on my phone. It was posted on NH like 6 months ago.

Probably https://github.com/AvaloniaUI/Avalonia

That's the one!

I'm somewhat confused as to why the Centos and Fedora pages tell you to install from binary tarballs, but there's a yum repository for RHEL.

Reply on news.ycombinator.com