
Announcing .NET Core Tools 1.0 - WadeJohnson
https://blogs.msdn.microsoft.com/dotnet/2017/03/07/announcing-net-core-tools-1-0/
======
danek
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.

~~~
Sacho
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/91)

[https://github.com/nunit/dotnet-test-
nunit/issues/101](https://github.com/nunit/dotnet-test-nunit/issues/101)

[https://github.com/nunit/nunit3-vs-
adapter/issues/305](https://github.com/nunit/nunit3-vs-adapter/issues/305)

~~~
danek
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.

------
replete
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.

~~~
AwesomeBean
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.

~~~
rubber_duck
>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.

~~~
AwesomeBean
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.

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

~~~
DaiPlusPlus
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.

------
scarface74
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?

~~~
artimaeis
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.

------
debacle
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.

~~~
josteink
> 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?

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

------
hubert123
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

~~~
nlawalker
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.

------
insertnickname
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

~~~
finchisko
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.

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

------
snehesht
[https://i.imgur.com/2uLUNH1.png](https://i.imgur.com/2uLUNH1.png) Why is
Microsoft serving Panasonic.jp SSL certificate ?

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

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

~~~
DaiPlusPlus
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.

~~~
tonyedgecombe
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.

~~~
DaiPlusPlus
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.

~~~
tonyedgecombe
I thought Xamarin Forms was for phones?

------
NoGravitas
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.

