This post was written by Scott Hunter.
You all want .NET Core 1.0 RC2, you want a schedule, and you want to go live. Today we’ve got a schedule to share plus some changes that will improve things for everyone in the .NET Community going forward.
The Core Schedule
- .NET Core and ASP.NET Core 1.0 RC2 runtime and libraries will be available in mid-May.
- Tooling will be Preview 1 and bundled with this release.
- .NET Core and ASP.NET Core 1.0 RTM (release) runtime and libraries will be available by the end of June.
- Tooling will be Preview 2 and bundled with this release.
- We will continue to make changes and stabilize the tooling until it RTMs with Visual Studio “15”.
How We Got Here
The ASP.NET team started two and a half years ago, building a new version of ASP.NET that was modular, cross platform, and high-performance. This new version of ASP.NET was built on a new .NET Execution Environment (DNX) that was optimized for modern cloud-focused workloads (websites, microservices, etc.). We shipped an RC1 of those bits in November.
After shipping ASP.NET Core 1.0 RC1, it was very important to broaden .NET Core to also support building native console applications. So we started the process of reworking the tool chain so it could be used to build .NET console, class libraries and server applications. This process has proved to be harder than we anticipated and led to us removing dates for RC2/RTM from our schedule in February.
Unifying the frameworks and the tooling
Now that Xamarin is a part of Microsoft, more than ever we want to make it easy to share code between desktop, server and mobile applications.
We announced the .NET Standard at Build as part of our plan for making it easy to share code across .NET application models.
We also need to make it easy to work with projects across these application models. In order to do this we are working to merge the capabilities of .xproj/project.json and .csproj project systems into a single project system based on MSBuild. This transition will be automatic and will not require you to change your existing projects. This work will happen during the VS 15 release schedule and we will release another blog post with more details.
What does Preview mean?
Remember that .NET Core has two main parts:
- The Runtime/Libraries – This is the CLR, libraries, compilers, etc.
- The Tooling – This is all the support in the .NET Core command line tools, Visual Studio and Visual Studio Code that enable you to work with .NET Core projects.
We’re splitting the .NET Core “release train” so that those of you who are waiting can go live on .NET Core 1.0 RC2 with confidence, while we continue to deliver on our plans for the tooling:
- The .NET Core 1.0 RC2 runtime is a true Release Candidate. It’s solid, stable, and it won’t change for RTM (except if something critical happens) and we feel good about it. It will have a “go-live” license, meaning you can get official support from Microsoft.
- The tooling that supports .NET Core and ASP.NET Core, including the new command line tools and bits that plug into Visual Studio & Visual Studio Code, aren’t there yet. It’s going to change before it stabilizes. We’re going to call this tooling release Preview 1.
Summary
If you have questions, please share them below and the team will answer them here. We will also discuss this delivery schedule change on our next ASP.NET Community Standup with a full question and answer segment.
Scott Hunter – .NET Team
This is great news! The dates are sooner than I expected. Great work team!!! The best part is this: “In order to do this we are working to merge the capabilities of .xproj/project.json and .csproj project systems into a single project system based on MSBuild”
Horray!!! Please stick to MSFT-tech/roots and make this a Xaml-based format!!!
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system
Congratulations again and great work on your accomplishments. These are investments we will benefit from for the next decade, easy.
For them love of ALL THAT IS HOLY, please ANYTHING BUT XAML. I’d rather the XML-based csproj style than XAML.
The only reason you want XAML to be the choice is because you assume that there would be great tooling to go with it, similar to the designer you use with WPF projects but this isn’t necessarily the case. As someone who dealt with (old) TFS’s build system – that used XAML – believe me, the unnecessarily verbose nature of it can cause far too many problems.
The project.json format is absolutely fantastic, it’s simple and concise and works really well. This is coming from someone who hates the csproj (And similar vbproj/vcxproj) formats. Simple and clean is the way to go – if JSON is too simple, keep it something like XML but not using the same MSBUILD project system now.
I’m a little surprised by the XAML wish too. I think everyone would be better off with JSON, but out of curiosity what advantage do you see in XAML over JSON?
JSON doesn’t support comments, which makes it a poor choice for anything with human-editable needs. And personally I find all the pointless quotes around keys make it hard to parse, but I understand that might be personal taste.
Agreed please no xaml
Haha well we’re going to get the web crowd saying “no Xaml,” and we’ll get the native crowd saying “no Json” … so why not both?
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/10020525-enable-roslyn-powered-data-asts-and-data-views
There definitely stands for some further innovation in this area!
Yes, the TFS Xaml System was/is T-E-R-R-I-B-L-E! I agree… that was a poor showing of what Xaml is capable of, and I absolutely am in agreement. What Xaml provides out of the box that project.json is a class-based schema, where a POCO class definition is the document schema. That means there is no having to create yet another artifact to describe the document that you are creating, and tooling just kicks right in. There is a 1:1 correlation between the objects you are working with and the objects that ultimately are deserialized in memory to create the project. This leads to consistent naming conventions as well.
Plus the designer support. You are familiar with the Project Properties tabs in Visual Studio .csproj files, correct? That should be a styled control based off of Xaml! Right now each of those tabs are custom rolled and completely untouchable. A Xaml-based system would be very conducive to editing and extending projects in a very robust/comprehensive manner.
Agreed, no xaml please.
A simple XML format will do.
Another option would be a DSL. The Gradle build system uses Groovy for example.
On second thought, I think a DSL might be the best option.
Easy to extend, short format, very flexible, supports comments, etc.
Could even be VB…
Name = “TestProject”
Version = “1.0”
‘ Add some references
AddReference(“System.Data”, “System.Data.SqlClient”)
‘ OS specific
If PlatForm = PlatForm.Linux Then AddReference(“Kestrel”)
Etc.
Why not F#?
It’s a stellar language for DSLs! https://fsharp.github.io/FAKE/
I’m pretty sure what they’re saying is that they’re going to make MSBuild work with project.json as well as traditional XML project files. Which is absolutely the right way to go. There are millions of developers out there using JSON/JS based project systems (NPM, TypeScript, Gulp/Grunt/Webpack, etc.), not using full-fat Visual Studio, and ASP.NET Core projects need to sit nicely in that world.
Oh, and now that .NET Core is seeing a light at the end of the tunnel, it would be great to start putting some sights/efforts on bringing .NET to the Web, and rounding out support for .NET so that it can effectively target all the four major platforms (iOS, Droid, Windows, and Web).
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
With iOS and Droid support provided by Xamarin, we’re 3/4ths of the way there.
Thank you for any consideration and support!
This is awesome! Thanks so much. (Any chance of “Angular 2 templates” getting some love on File > New?)
That will be happening along with the work the Angular community are doing on angular-cli, which can be integrated with IDEs to provide, for example, ‘Add > New Route’.
I was always wondering, why there is now Xamarin to Angular or React. I hope with ASP.NET core 1.0 this opens a way to introduce web-platform as part of the Xamarin-platform.
Great news
thank you asp.net 5 team keep up the good work 
Thanks for the timeline and the details on future plan.
If there is a possibility, It would be highly appreciated if you guys reconsider supporting mono TFM in CLI by RTM: https://github.com/dotnet/cli/issues/1613; otherwise some library maintainers will be reluctant to switch completely to CLI even after the RTM (until mono support is available).
Will the new project file format require people to specify which files are in a project? Or will all files in the project tree be included by default?
In other words, will adding new files to a project by multiple people at the same time still require a project file merge?
> Will the new project file format require people to specify which files are in a project? Or will all files in the project tree be included by default?
Almost definitely no. We definitely want to keep as much of the project.json goodness as possible, including not requiring you to specify the files :).
To be sure, this is not a feature that is inherit to JSON, but to how the JSON-described projects behave. This same functionality/behavior can be applied to any format. It should also be adjustable/customizable as well. It’s basically opt-in vs opt-out model. .csproj-based projects are opt-in, whereas JSON-based projects are opt-out. Those of us who are conditioned/old skoolers are opt-in whereas all the new kids are opt-out. We can blame Git.
In any case, it would be great to have a system where both styles are accounted for!
Well, it’s basically a locking vs merging pattern when it comes to source control.
As soon as you work with a merging pattern, the optin model becomes very cumbersome.
And I’ve put sone serious effort into learning Java and its tools, which makes me look at .NET in a different perspective.
Maven and Gradle are so much more flexible than MsBuild. I really hope the .NET guys look at the Java stuff for inspiration.
But yes, I really want to use Git at work!
Any roadmap for when SignalR will be added to the new stack?
SignalR will be avaiable after 1.0 release.
Is there any news on System.Drawing?
If it’s not included yet, are there changes in RC2 which will make porting easier in the future?
Great work, .NET team.
So we are going back to XML instead of the project json?
It was not very clear what merging into something based on msbuild meant? Or is this only for visual studio.
The XML “format” that MSBuild uses is actually quite terrible. XaML is a much better format, mature, already has tooling support, and is a MSFT tech.
http://blog.developers.win/2016/02/has-the-tide-turned-on-project-json/
This is great news!
I have an ASP.NET 5, dnx rc1 solution which is working except for publishing to IIS. Is there guidance on how to make the migration to dotnet core rc2 ASP.NET Core?
Thanks
So there will be console projects, class library projects, and web projects that target .NET Core, but how about the VS unit test projects targeting .NET Core, any plans for that?
The unification of the .NET Standard Library across all 3 domains (.NET Framework, .NET Core, and Xamarin) is outstanding news! Now, there are also opportunities for unification at the App Model layer: WPF, UWP, and Xamarin.Forms all use different dialects of XAML. Ideally, these XAML dialects should also be consolidated, such that the unification would be complete: common infrastructure at the bottom of the stack, .NET Standard Library at the middle of the stack, and XAML App Model at the top of the stack. One can also imagine that even ASP.NET and ASP.NET Core could replace HTML with XAML (sort of a Silverlight revival) via compilation to WebAssembly. Are there any thoughts being given to unifying/consolidating the different XAML dialects?
Please feel free to join the conversation here, Leo!
https://github.com/dotnet/corefx/issues/5766
Ideally we want a Xaml system that is System.Xaml based, a little faster and more streamlined. Anything but UWP’s Xaml system.
This is an extraordinary time to be a .NET developer! The last time I was this excited about .NET was when the early betas were released pre-v1.0. Microsoft has made a wise decision to open source .NET and go cross platform. Acquiring Xamarin was another smart move. Nice to be part of a thriving ecosystem with strong leadership and a clear vision. Keep up the great work.
Question marks are indeed turning into exclamation points.
Mr. Nadella’s vision/stamp is finally taking hold, I’d say. All that is needed is .NET support for WASM (WebAssembly) and we are totally in business again!!
Will tooling Preview 1 and 2 (.NET Core SDK Installer) be available for Ubuntu 16.04 LTS?
Any more details for EF 7 roadmap ?