May 24, 2016 at 14:38Project.json changes
- Transfer
Last week, we announced the RC2 / RTM release schedule for .NET Core and ASP.NET . Now that we have released RC2, I would like to reveal a little more details about the transition of .NET Core from projects like .xproj / project.json to .csproj / MSBuild.
When the ASP.NET team began work on ASP.NET 5 (ASP.NET Core already), one of the main goals was the ability to easily create and develop applications on Windows, Mac and Linux. This entailed the creation of .xproj / project.json project systems. Key features were:
Continuing the development, we expanded the role of the .NET Core itself:
How does this affect project.json? One of the key principles of .NET as a platform is the ability to share code between our developers in all models of .NET applications (WinForms, WPF, UWP, ASP.NET, IOS, Android, etc.). This creates a number of problems: although project.json is great for creating web applications and class libraries, at the same time it does not allow unification with other application models.
We had two ways. The first was to port all .NET projects to use project.json. This would require us to create / modify tools that affect all types of projects in Visual Studio, Xamarin and our partners, such as Unity. We would have to extend project.json to support all types of builds required by each of these types of projects, as well as provide a migration history. Another way could be to create a bridge between .xproj and .csproj projects so that the latter can refer to the .xproj project in Visual Studio and Xamarin Studio. This approach has its drawbacks, for example, when a client creates a project, he should now choose between .xproj and .csproj, which only adds more options and complexity.
Having considered the options above, it became obvious that it would be easier to migrate .NET Core projects to .csproj / MSBuild, which would allow all .NET projects to use the same toolkit and build system.
At the same time, we do not plan to give up the benefits of project.json. So, we plan to expand .csproj to support the missing functionality:
Because Since all .NET will use the same toolkit, you can then do the improvement of MSBuild. We will seek feedback from customers and the community regarding JSON support instead of XML, reducing the number of overly detailed files generated by our tools, etc. Provided that one stack is used, these enhancements will work for all .NET projects.
The first wave will be changes in Visual Studio “15” RTM: when you open any .NET Core project, Visual Studio will automatically convert .xproj to .csproj, transferring data from project.json to the configuration files and the .csproj file itself. We will also provide a tool for converting applications using console .NET utilities.
The next wave will be after the launch of Visual Studio “15”, aimed at further improving the experience of building projects and working with them.
.NET Core and ASP.NET Core are the first .NET projects that we developed completely open. Most likely, you will not see all the changes, as the team is experimenting to make the best product. We are trying to find the right balance of transparency between GitHub, the community and even this blog. Moving forward, we will try and announce the main changes through this blog first as we are ready to provide more context on what is changing and why.
Next week we will write about .NET Standard: how we plan to make code sharing easier for all types of .NET projects.
Msbuild
When the ASP.NET team began work on ASP.NET 5 (ASP.NET Core already), one of the main goals was the ability to easily create and develop applications on Windows, Mac and Linux. This entailed the creation of .xproj / project.json project systems. Key features were:
- No file enumeration in the project
- Ease of editing a project file without an IDE
- Creating a Nuget Package Using Only a Project
- Cross compilation for different versions of the framework
- Ease of link / dependency switching
Continuing the development, we expanded the role of the .NET Core itself:
- .NET Core has become the platform for Universal Windows Applications (UWP)
- .NET Core has become a cross-platform toolkit for creating both console applications and libraries
- Microsoft acquired Xamarin so that .NET developers can create iOS and Android applications (translator's note: we are talking about free Xamarin tools)
How does this affect project.json? One of the key principles of .NET as a platform is the ability to share code between our developers in all models of .NET applications (WinForms, WPF, UWP, ASP.NET, IOS, Android, etc.). This creates a number of problems: although project.json is great for creating web applications and class libraries, at the same time it does not allow unification with other application models.
We had two ways. The first was to port all .NET projects to use project.json. This would require us to create / modify tools that affect all types of projects in Visual Studio, Xamarin and our partners, such as Unity. We would have to extend project.json to support all types of builds required by each of these types of projects, as well as provide a migration history. Another way could be to create a bridge between .xproj and .csproj projects so that the latter can refer to the .xproj project in Visual Studio and Xamarin Studio. This approach has its drawbacks, for example, when a client creates a project, he should now choose between .xproj and .csproj, which only adds more options and complexity.
Having considered the options above, it became obvious that it would be easier to migrate .NET Core projects to .csproj / MSBuild, which would allow all .NET projects to use the same toolkit and build system.
At the same time, we do not plan to give up the benefits of project.json. So, we plan to expand .csproj to support the missing functionality:
- No file enumeration in the project
- Using the CLI tool to perform any operations on the project file, although in most cases you do not have to edit the file itself
- Create a package using only the project
- Multi-targeting
Because Since all .NET will use the same toolkit, you can then do the improvement of MSBuild. We will seek feedback from customers and the community regarding JSON support instead of XML, reducing the number of overly detailed files generated by our tools, etc. Provided that one stack is used, these enhancements will work for all .NET projects.
The first wave will be changes in Visual Studio “15” RTM: when you open any .NET Core project, Visual Studio will automatically convert .xproj to .csproj, transferring data from project.json to the configuration files and the .csproj file itself. We will also provide a tool for converting applications using console .NET utilities.
The next wave will be after the launch of Visual Studio “15”, aimed at further improving the experience of building projects and working with them.
Developing in the open
.NET Core and ASP.NET Core are the first .NET projects that we developed completely open. Most likely, you will not see all the changes, as the team is experimenting to make the best product. We are trying to find the right balance of transparency between GitHub, the community and even this blog. Moving forward, we will try and announce the main changes through this blog first as we are ready to provide more context on what is changing and why.
What's next
Next week we will write about .NET Standard: how we plan to make code sharing easier for all types of .NET projects.