Today, we are releasing .NET Core Tools 1.0. It’s an exciting day and an important milestone in the .NET Core journey. The tools are supported on Windows, macOS and Linux. You can use them at the command-line, with VS Code or as part of Visual Studio 2017.
You can download the new .NET Core tools at .NET Core Downloads, for using .NET Core on the command-line.
The tools are also integrated into Visual Studio 2017, also releasing today. You need to select the .NET Core cross-platform development workload when you install Visual Studio.
You can read more about the Visual Studio 2017 release in Announcing Visual Studio 2017 General Availability… and more. Also check out Visual Studio 2017: Productivity, Performance, and Partners.
Visual Studio for Mac also includes support for .NET Core. Visual Studio for Mac Preview 4 is also releasing today.
Visual Studio Code works great with .NET Core, too. The C# extension is a must-have for .NET Core development, and is typically suggested to you as soon as you open a C# or csproj file.
New versions of the .NET Languages are included in Visual Studio. You can now use C# 7, Visual Basic 15 and F# 4.1. C# 7 is already supported with .NET Core (just by using the latest Roslyn!). We expect F# support in the first half of 2017 and then VB support after that.
.NET Core 1.0.4 and .NET Core 1.1.1 were also released today. Both releases include a set of reliability updates to improve the quality of .NET Core. You can download the .NET Core Runtime releases via our .NET Core Runtimes download page. If you are looking for the .NET Core SDK to get the latest tools, try the .NET Core SDK download page.
A Quick Tour of .NET Core
There are some great experiences and features that we’ve built over the last several months, a big step forward over the tools that were previously available for .NET Core.
You can take the tour of .NET Core by watching What’s new in .NET Core and Visual Studio 2017. It’s a great video, showing you a lot of the new .NET Core experience in just 8 minutes.
We are encouraging everyone doing .NET Core development to move to Visual Studio 2017, including migrating from project.json to csproj. We will not be supporting csproj and MSBuild for .NET Core in Visual Studio 2015.
Let’s take a look at some of the key improvements, starting with the command-line experience, moving to Docker and then into Visual Studio.
Command-line experience
You can very quickly create and run a .NET Core app on your favorite OS. Let’s see what the experience looks like on Windows, creating and launching a .NET Core 1.0 console app. You need the .NET Core SDK installed for this experience.
C:\>dotnet new console -o myapp
The template "Console Application" created successfully.
C:\>cd myapp
C:\myapp>dotnet restore
Restoring packages for C:\myapp\myapp.csproj...
C:\myapp>dotnet run
Hello World!
Docker experience
You can see a similar command-line experience using Docker. In this example, I’m creating and launching an ASP.NET Core 1.1 MVC site using a .NET Core SDK Linux Docker image with Docker for Windows (I prefer “Stable channel”). You just need Docker for Windows installed, configured to Linux containers for this experience. You do not need .NET Core installed. You can do the same thing with .NET Core and Windows containers.
C:\Users\rich>docker run -p 8000:80 -e "ASPNETCORE_URLS=http://+:80" -it --rm microsoft/dotnet
root@9ea6f0be8ef7:/# dotnet new mvc -o mvc --framework netcoreapp1.1
The template "ASP.NET Core Web App" created successfully.
root@9ea6f0be8ef7:/# cd mvc
root@9ea6f0be8ef7:/mvc# dotnet restore
Restoring packages for /mvc/mvc.csproj...
root@9ea6f0be8ef7:/mvc# dotnet run
Hosting environment: Production
Content root path: /mvc
Now listening on: http://+:80
Application started. Press Ctrl+C to shut down.
I then navigated the web browser to http://localhost:8000 and saw the following page load, instantly. I still find this configuration amazing, loading ASP.NET sites from a Linux container, on Windows. Try it; it works!
Visual Studio Templates
There are new templates that you can use in Visual Studio 2017, for .NET Core, ASP.NET Core and .NET Standard. You can see them located in the new project dialog, displayed in the following screenshot.
You should use the ASP.NET Core template if you want to build web sites or services, use the .NET Core template for tools or .NET Core experimentation and use the .NET Standard (Class Library) templates for libraries that you want to use with multiple apps of different application types (for example, .NET Core, .NET Framework and Xamarin). There are also platform-specific class library templates (for example, .NET Core (Class Library) and .NET Framework (Class Library)) that enable you want to take advantage of APIs available in those respective platforms and not in .NET Standard.
The ASP.NET Core “new project” experience includes a version picker, making it easy to select the version of ASP.NET Core that you want. The selection controls both the .NET Core target framework and ASP.NET Core package versions. See the experience in the following screenshot.
Editing csproj files in Visual Studio
With .NET Core projects, you can edit project files “live” while the project is loaded. This option is available by right-clicking on the project file and selecting Edit [project-name].csproj. You can add or remove package references and other aspects of the project file. It seems magic compared to the existing Visual Studio “Unload Project” experience. You can also try an experimental extension that offers csproj intellisense. See the new experience in the following screenshot.
.NET Standard Project-to-Project References
.NET Standard libraries are a new project type that you can use in nearly all .NET project types. They are the replacement for and a big step forward over Portable Class Libraries. You can now reference .NET Standard projects and NuGet packages from .NET Framework, Xamarin and Universal Windows Apps. The image below shows a .NET Framework console app with a project dependency on a .NET Standard project, which has dependencies on two popular NuGet packages.
Migrating project.json Projects to csproj
We’re now encouraging everyone to migrate to MSBuild and csproj from project.json. As I stated above, we will not be supporting any of the new .NET Core tools in Visual Studio 2015. We also won’t be updating the Visual Studio 2015 project.json-based tools.
There are two experiences for migrating project.json projects. You can migrate project.json files on the command-line, with the dotnet migrate command. The command will produce a .csproj project file that you can use with the latest .NET Core tools or open in Visual Studio 2017.
You can also open .xproj files in Visual Studio 2017. Visual Studio will migrate your .xproj files for you, producing a .csproj file that you can use going forward for use with both Visual Studio 2017 and with the latest .NET Core tools at the command-line.
Visual Studio for Mac
Visual Studio for Mac is an IDE for mobile-first, cloud-first workloads with support for building iOS, Android, and Mac apps in C# and F# with Xamarin, as well as web and server apps with .NET Core and ASP.NET Core. You’ll find the same Roslyn-powered compiler, IntelliSense code completion, and refactoring experience you would expect from a Visual Studio IDE. And, since Visual Studio for Mac uses the same MSBuild solution and project format as Visual Studio, developers working on Mac and Windows can share projects across Mac and Windows transparently.
Documentation
.NET Core documentation and ASP.NET Core documentation have been updated to document the .NET Core Tools 1.0 and Visual Studio 2017 experience.
We still have a lot of work to do to improve and expand the docs and will endeavor to do just that. Like the .NET Core product, the .NET Core docs are open source. Please don’t hesitate to file issues and improve the docs with a pull request.
What’s in the release
We released the following today:
- .NET Core Tools 1.0.0 – only ships in Visual Studio 2017
- .NET Core Tools 1.0.1 – available in the SDK and via Docker SDK images
- .NET Core Runtime 1.0.4 – available as a Runtime install or Docker image and in the .NET Core SDK
- .NET Core Runtime 1.1.1 – available as a Runtime install or Docker image and in the .NET Core SDK
We didn’t intend to release two versions of the SDK on the same day. That would be silly! Instead, there is a good story! The short version of the story is that we missed an internally-set date to update the .NET Core Tools 1.0.0 release (the one going into Visual Studio 2017) to add support for some Linux distros, so were forced to create the 1.0.1 in order to make Fedora 24 and OpenSUSE 42.1 developers happy.
We also updated both .NET Core 1.0 and 1.1, with patch releases. Both releases contain reliability fixes and no new features. You can always read the .NET Core release notes to learn about our releases.
Docker
The latest .NET Core runtime and tools are available in the following .NET Core SDK Docker images:
1.0.4-sdk1.0.4-sdk-nanoserver1.1.1-sdk1.1.1-sdk-nanoserver
You can also use the latest .NET Core Runtime Docker images, which are recommended for production deployments since they are much smaller than the SDK images:
1.0.4-runtime1.0.4-runtime-nanoserver1.1.1-runtime1.1.1-runtime-nanoserver
We adopted changes to the Docker tag scheme we use at microsoft/dotnet. The “-projectjson” and “-msbuild” differentiation is now gone. The tags are significantly simpler, as you can see from the tags above.
We have changed the tags multiple times over the last few months. These changes were required to properly represent the changing nature of the product. We believe that we will no longer need to make significant tag scheme changes going forward and that we are now at “steady state”. Thanks to all .NET Core Docker users for your patience!
As previously stated, we will no longer be producing any project.json-based Docker images.
.NET for UWP
The final release of .NET for UWP also shipped today within the Visual Studio 2017.
.NET Native is now included within the Microsoft.NETCore.UniversalWindowsPlatform NuGet package, starting with version 5.3.0. This means that you can select the version of .NET Native you want to use by selecting a specific version of the Microsoft.NETCore.UniversalWindowsPlatform package (starting with version 5.3.0). This capability is new with Visual Studio 2017. By using NuGet, we can ship .NET Native updates more easily and it’s easier for you to select the version you want to use, per project.
Here are the steps:
- Right click on the project and select Manage NuGet Packages…
- Select the Microsoft.NETCore.UniversalWindowsPlatform NuGet package.
- Change the version to 5.3.0.
- Click the Update button.
If you do not see version 5.3.0 listed, make sure that the Package Source is set to nuget.org.
You can revert back to .NET Native 1.4 at any time by rolling back the Microsoft.NETCore.UniversalWindowsPlatform NuGet package from 5.3.0 to any earlier version such as 5.2.2 or 5.1.0. This can be done by following the same steps outlined above with the desired version.
Visual Studio 2017 RC comes with .NET Native 1.4 by default. This is the same version that is included in Visual Studio 2015 Update 3, with the addition of a few fixes. .NET Native 1.6 is not supported in Visual Studio 2015.
Closing
Thanks to everyone that helped to get .NET Core Tools to 1.0. There are so many people to thank that helped the product get to today and we thank you for your patience as we iterated on our tools. We hope that you are happy with the product, specifically the 1.0 tools. Sincerely, thank you!
I looked back in our blog history and found the first mention of .NET Core and related tools on this blog. Enjoy that. Certainly, much of what I wrote there remains true. There are some DNX-isms that we’d still like to bring back, too.
.NET Core 1.x is just the start of this new platform. We’re very excited to see what you do with it. We’ll listen closely to your feedback and look forward to working closely with many of you on GitHub. Also, .NET Standard 2.0 and .NET Core 2.0 will be released later this year. We’ll start talking about those releases on the blog before long.
Again, thanks so much for using the product and for helping us build it.
Note: You can always find our released builds documented in release notes.
The Project File Tools mentioned in relation to VS Code are actually a Visual Studio extension.
Thanks! Fixed. That was an oversight.
Do we have VB support yet?
Thanks,
Jeff Bowman
Fairbanks, Alaska
I seriously miss VB support.
And as a long time VB user, I feel feel very offended as we are treated badly.
Microsoft stills says we support VB and C# => no your not.
And I feel really bad when I have to do code in C#, some code that would be a lot nicer to me in VB.
Could you at least give a date ?
So what happened to the .Net Core Windows Server Hosting package with the ASP.Net Core Module? Didn’t see it on the .Net Core downloads page anymore, unless I missed it somewhere.
Steve – there were no updates to the ASP.Net Core Module for this release and the Windows Server Hosting package is still in the oven. I’ll get that added to the download page as soon as it’s ready to roll.
Thanks for the update!
For F# info, see wiki page https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-1.0.1
There are good workaround/info, and always updated
Good call. Added that link early in the post. Thanks!
“We’re now encouraging Visual Studio 2015 users to migrate to MSBuild and csproj from project.json. As I stated above, we will not be supporting any of the new .NET Core tools in Visual Studio 2015. We also won’t be updating the Visual Studio 2015 project.json-based tools.”
that is completely different statement compared to the initial release of .NET Core Support in VS 2015.
what a stupid recommendation:
we should migrate to MSBuild and .csproj and in the next sentence you’re writing to the tools will not be supported in VS 2015.
a real flash back: as always the bug will be fixed in next release of VS – but the reality is different as the bug will never be fixed.
I understand why you are frustrated. We made a lot of changes in Visual Studio 2017 to enable the .NET Core tools experiences that were needed. It was impractical to port those to Visual Studio 2015, both for compatibility and cost reasons. Again, I sympathize.
Why VSCode can got this update, and VS201 not?
*2015
The level of .NET Core integration in Visual Studio is so much greater than in Code. Also, the integration in Visual Studio touches code that is relied on by multiple project types and scenarios beyond even just .NET. This is not the case with Code. Also, the extension for Code is opt-in w/o any impact on core Code features. So, the proposition is very different from an engineering standpoint and potential for negative user impact.
Does it mean if we want to go with .Net Core, we must pay for Visual Studio 2017? And it’s not cheap!
I understand why you are frustrated. you made a lot of changes in Visual Studio 2017 to enable the .NET Core tools experiences that were needed. Know it is impractical for us to upgrade to Visual Studio 2015, both for compatibility and cost reasons. Again, I sympathize.
You want to use latest results of .NET Core engineering efforts without using latest version of Visual Studio, … The irony is upon you!
You can get VS2017 Community edition for free, you know. And stop complaining…
Mike,
read the license terms for VS 2017 Community edition and you know that it is only an option for tiny projects but not for real commercial projects.
How did the organization that you work for managed to get VS2015? Get VS2017 thru same means then… Or use VS Code, for .NET Core development should be just right…
Downloading another 25+ GB of stuff on a 1 mbps connection is not something I look forward to. Also, I believe that IDE and the language/platform should be decoupled. I think that’s the way it is for 2017 onward.
VS2017 is not 25+ GB… In face with VS 2017 if you been paying any attention, comes new installation experience, it only downloads components you select, and you have vast array of work flows to choose from…
… And if that doesn’t fancy you, you can fall back on dotnet cli or VS Code… Each in MB download
“We are encouraging everyone doing .NET Core development to move to Visual Studio 2017”
I’d suggest that sentence goes under a Visual Studio heading unless you really are encouraging OS X and linux users to use windows and VS2017 🙂
Thanks. Fixed. That wording is definitely too broad and was a mistake. It now says:
“We are encouraging Visual Studio 2015 users doing .NET Core development to move to Visual Studio 2017.”
Are projects created in VS for Mac and VS 2017 compatible
Yes.
Congratulations on shipping 1.0! I’ve been experimenting with .NET Core for a few months now. Core Runtime/Standard/ASP.NET Core are great products, but the tooling has undergone so many changes in the past couple years that finding up-to-date answers was a constant frustration. I hope that a stable, well-documented, well-integrated 1.0 tools release will help alleviate some of that pain for future Core users.
Agreed and I share your hope. We now have a solid foundation to work from, so everything should just get better from this point.
Will it be possible to have both VS2015 and VS2017 installed on the same machine and be able to use both dotnet tooling options? When I test the upgrade I want to still be able to open a project.json based solution in VS2015 and have that continue to work on my machine.
Yes you can do that. I have both VS2015 and VS2017 together. The only thing you need to note is to have respective global.json file for VS2015 projects.
Dawa,
as Robert wrote: installing VS2017 with .NET Core support breaks VS2015 .NET Core support and there’s no save and always working way to have both version configured
Just a word of warning. Installing VS2017 on the same box as VS2015 breaks the latter somewhat. It’s documented at http://stackoverflow.com/questions/40674393/ and it looks like a good number of folks are experiencing it.
Hi Yousif,
Yes, you can use both VS2015 and VS2017 on the same machine, however you do need to do additional configuration in the form of a global.json file. That file specifies which SDK/CLI to use. For your VS2015 projects/solutions you should add it and specify the Preview 2 version of the CLI. More information can be obtained on https://github.com/dotnet/cli/blob/master/Documentation/ProjectJsonToCSProj.md.
Thanks!
We’re not doing ASP.NET Core yet, still on ASP.NET MVC 5 in VS2015. If we upgrade to VS2017 will we be able to use the new msbuild goodies in our *.csproj files (like wildcard inclusions, nuget package refs, etc.), or is the new msbuild/csproj tech for Core projects only? If we’re good to use them, then we’ll also need to upgrade our buildservers with the new msbuild tools – is there a separate package with the new msbuild or do we need to install fully licensed VS2017 on our servers?
Grats on the new release!
Hi Marcin,
Majority of the new csproj features are available only for .NET Core projects. Package reference, however, is available for non-Core csproj projects if you configure it using Tools->Options->Nuget and select “Package Reference” under “Package Management” heading.
Hope this helps!
Thanks!
Is it practical to move a plain .NET project to the new friendlier csproj?
One goal of mine is to use git submodules to bring in certain libraries but nuget references having a full DLL path have always made this impossible without tons of issues.
Congrats on finishing 1.0!
I tried to migrate my 60-something projects solution from VS15 .NET Core over to VS17. Overall this worked quite ok, but it seems for quite a number of projects VS17 decided to have project references point to the projects moved into the backups folder as I get a number of errors like “referenced project XYZ cannot be found in folder ../../../Backup/”.
Where would I report this? Would that be an CLI error and thus be going to github or is that an VS17 issue?
Thanks,
Christian
Hi Christian,
Please file any and all migration issues on the CLI repo.
Thanks!
Hi Christian,
Please file any and all migration issues to the CLI repo. We will then triage them and send them where needed. 🙂
Thanks!
Does it support Taghelpers ?
if not than it will be added in next version breaking current version of VS ROFL
Do we have VB support yet?
Thanks,
Jeff Bowman
Fairbanks, Alaska
Is it posible to be clear about the terminology you’re using : sdk, cli, runtime, framework, tool, visual studio tool, each of them has a different version number and release cycle. When you’re talking about .net core tools, is that the sdk (wich is the runtime + cli if i’m right) or the netcoreapp framework ? or the VS tools ? or something else ?
All this confusing versioning and version numbers … reminds me of dll hell really 🙁
Just wanted to write the same… 1.0 and 1.1 versions of .Net Core are multiplied by 4 version of tools and runtime.
FEEDBACK: The new Edit and Continue experience is highly broken.
With Edit and Continue enabled, the code editor disables editing of code while the code is running altogether (presumably for all code that it cannot live re-compile into the running app). This is MUCH WORSE than not having E&C enabled in the first place and requiring a restart of the server app every time you make changes – because it prevents you from coding and being productive while behind the scenes you compile / re-run etc.
It would be much better to display a modal banner or something of the sorts if you make changes that cannot be live recompiled into the app while still allowing the developer to develop, while still being able to “instant run” the changes that E&C CAN handle.
I know that lack of runtime recompilation is literally THE reason compiled languages have been losing out, and we all eagerly want to see this area improved the same as Android is doing with Instant Run – but we need to this right guys if we’re gonna do it at all. The E&C feature is great in concept, but as it stands you guys literally took a step BACKWARDS in user experience. In 2017 I would not expect decisions like these to make it past your product managers and into shippable products.
Please rectify at first chance guys – until then the whole Edit & Continue feature is literally useless.
#toughlove
Hey guys, so what parts of C# 7 outlined in the preview post (https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/) made it?
There’s a bunch of features in there that were ‘not yet implemented in Preview 4’. Did these all make it into final?
– throw expressions
– deconstruction wildcards
– generalized async types
– ValueTask
– expression-bodied getters/setters
Haven’t seen these explained in an announcement anywhere.
Cheers!
Great question. Mads published a post on exactly this topic after I published this one. I have updated the link in this post to the updated post. It is here: https://blogs.msdn.microsoft.com/dotnet/2017/03/09/new-features-in-c-7-0/
Is VB going to be implemented/support on linux for .net core?
Yes. It is just a question of when. We intend to provide this support in 2017.
@Andrew
I recommend to be careful: We heard exactly the same thing some months ago regarding Core Tools 1.0 for VS2015. The just promised VS2015 support to avoid to shy users away because of an expected forced VS upgrade. Now its “We understand your frustration, but never mind”
Now they even added Python (!) support to VS2017 before VB# to Core. I would not rely on getting VB# support for Core. Since about a year VB# support “is coming soon”. There never was and still is no ETA, and its not mentioned in the .Net Core roadmap.
VB# has fallen out of favor and is left for dead. I wouldn’t be surprised if the next VS release will skip VB# support completely, As it happened with Silverlight/WP8 support for VS2017. Don’t let them fool you.
I think the first question is whether VB is going to be implemented/supported on anything for .net core? I loved the sentence in the announcement above:
“You can now use C# 7, Visual Basic 15 and F# 4.1.”
Sounds great! Until you realise in the next sentence that the writer has entirely different conception of the word ‘now’ from everybody else.
“C# 7 is already supported with .NET Core (just by using the latest Roslyn!). We expect F# support in the first half of 2017 and then VB support after that.”
So ‘now’ is actually at least 4 months away and could be any time! Please tell me I’ve got this all wrong.
I am so sick of hearing “We also won’t be updating the Visual Studio 2015 project.json-based tools.”. Why didn’t you realize there is a major of chunk of users who are developing production ready apps using Visual Studio 2015 and .NET Core tools. What options did you leave for us to upgrade?
I cannot again go back to business and claim we need a Visual Studio 2017 license(as some of my team members do not have MSDN), as Microsoft no longer supports VS2015 with .NET Core Tools. You better inform customers before you deciding on all these…
I am frustrated by the dictatorship of Microsoft without vision of how may people will be affected by this simple clause “We also won’t be updating the Visual Studio 2015 project.json-based tools.”.
The .NET Core install is failing for me. Attempting to download the SDK from this location: https://www.microsoft.com/net/download/core
Looking at the log file here is the relevant section showing the error:
[28C8:2154][2017-03-13T11:59:05]i370: Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{adfa1ec9-2075-4eec-9bb5-3f647f8e8e48}, options: 0x7, disable resume: No
[28C8:2154][2017-03-13T11:59:05]i000: Caching bundle from: ‘C:\Users\kdacey\AppData\Local\Temp\{1FB8C9CB-EB7E-4E61-ACB0-02BDF13874B9}\.be\dotnet-dev-win-x64.1.0.1.exe’ to: ‘C:\ProgramData\Package Cache\{adfa1ec9-2075-4eec-9bb5-3f647f8e8e48}\dotnet-dev-win-x64.1.0.1.exe’
[28C8:2154][2017-03-13T11:59:05]i320: Registering bundle dependency provider: {adfa1ec9-2075-4eec-9bb5-3f647f8e8e48}, version: 1.0.1.0
[28C8:2154][2017-03-13T11:59:05]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{adfa1ec9-2075-4eec-9bb5-3f647f8e8e48}, resume: Active, restart initiated: No, disable resume: No
[4EC0:25FC][2017-03-13T11:59:05]i338: Acquiring package: VC_redist.x64.exe, payload: VC_redist.x64.exe, copy from: C:\Users\kdacey\Downloads\VC_redist.x64.exe
[4EC0:25FC][2017-03-13T11:59:05]i000: Setting string variable ‘WixBundleLastUsedSource’ to value ‘C:\Users\kdacey\Downloads\’
[28C8:2E08][2017-03-13T11:59:06]e000: Error 0x80070490: Failed to find expected public key in certificate chain.
[28C8:2E08][2017-03-13T11:59:06]e000: Error 0x80070490: Failed to verify expected payload against actual certificate chain.
[28C8:2E08][2017-03-13T11:59:06]e000: Error 0x80070490: Failed to verify signature of payload: VC_redist.x64.exe
[28C8:2E08][2017-03-13T11:59:06]e310: Failed to verify payload: VC_redist.x64.exe at path: C:\ProgramData\Package Cache\.unverified\VC_redist.x64.exe, error: 0x80070490. Deleting file.
[28C8:2E08][2017-03-13T11:59:06]e000: Error 0x80070490: Failed to cache payload: VC_redist.x64.exe
Unsure what’s needed to get this working.
This was some weird chess move by MS to get users onto the Core platform and then force users to change the tools completely. During one of the speeches, during the original release schedule, it was brought up that MS was open to supporting “project.json” for certain projects but nothing was ever done there. It would be nice if the conversion just happens at build time behind the scenes so the change wouldn’t effect any of our existing systems.
Mate, take it easy… Sound like the only programming you do is inside project.json file… .NET Code is growing beyond initial goals, look at “big picture/direction” of .NET Core… It will become the new .NET foundation; and as such must work with all existing project types.
I don’t think I’ve said anything outrageous here. I was evangelizing the core & project.json format and how its very comparable to python & virtualenvs to the startup communities in the bay. They already have a sour taste about the existing msbuild & .csproj format configurations which makes it hard for them to consider. Mainly because a lot of the tools & workflows aren’t really documented for command line users but for Visual Studio workflows. No one lives in “project.json” but its a configuration file which made since for development teams in my realm.
I’m kinda confused. After upgrading one of my libraries to the new project system (from project.json) I was expecting that the tooling, which was broken for the livetime of project.json, will be working now again. Otherwise, what’s the whole point of doing that exercise of migration etc. in the first place?
a) Code coverage is not supported, why is that?
b) Live unit tests are not supported – cool new feature in VS 2017 Enterprise which I have, but I cannot use it. Well shit…
c) Calculate code metrics not working
d) Performance Profiler doesn’t really work as it cannot link the source to the results and doesn’t display anything. It gives some numbers, but really, its kinda useless right now.
e) Edit and Continue not working at all. While debugging, you cannot edit your code. If you don’t attach a debugger it starts rebooting the app (attaches a watch automagically) => bad experience
f) Unit tests – lots of issues here, David Fowler wrote a pretty good issue on github about all the things.
g) There is still no UI support at all for multi targeting (especially in the test runner)
Overall I must say that I’m happy that the whole thing works at all and migrating was kinda ok (still had to do a lot of manual tweaks though). But I’m really disappointed about the tooling support in VS 2017 for .NET Core projects.
Literally nothing has changed from project.json to csproj in that regards -.-