Project.json changes
Last week we announced the release schedule for RC2 / RTM versions of .NET Core and ASP.NET . Now that we have already 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 started working 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 project systems .xproj / project.json. Key features were:
Continuing 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 possibility of sharing the code by our developers in all models of .NET applications (WinForms, WPF, UWP, ASP.NET, IOS, Android, etc.). This creates a number of problems: at least project.json is great for creating web applications and class libraries, but at the same time it does not allow unification with other application models.
We had two ways. The first was the transfer of all .NET projects to project.json. This would require us to create / modify a toolkit that affects all types of projects in Visual Studio, Xamarin, and our partners, such as Unity. We would need to extend project.json to support all the types of build required by each of these types of projects, as well as providing migration history. Another way would be to create a bridge between .xproj and .csproj projects so that the latter could 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 now has to choose between .xproj and .csproj, which only adds more options and complexity.
Considering the options above, it became obvious that it would be easier to move .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 abandon the benefits of project.json. So, we plan to extend .csproj to support missing functionality:
Since the whole .NET will use the same set of tools, then you can do it later and improve MSBuild. We will request feedback from customers and the community about supporting JSON instead of XML, reducing the number of excessively detailed files generated by our tools, etc. With the use of a single stack, these enhancements will work for all .NET projects.
The first wave will be changes in Visual Studio "15" RTM: when opening 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 have 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. Going forward, we will try and announce the main changes through this blog first as we are ready to provide more context about what is changing and why.
Next week we will write about .NET Standard: how we plan to make it easier to share code for all types of .NET projects.
Msbuild
When the ASP.NET team started working 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 project systems .xproj / project.json. Key features were:
- No listing of files in the project
- Easy to edit project file without IDE
- Creating a Nuget package using only the project
- Cross compilation for different versions of the framework
- Easy link / dependency switching
Continuing development, we expanded the role of the .NET Core itself:
- .NET Core became a 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 (note of the translator: it’s about Xamarin tools for free)
How does this affect project.json? One of the key principles of .NET as a platform is the possibility of sharing the code by our developers in all models of .NET applications (WinForms, WPF, UWP, ASP.NET, IOS, Android, etc.). This creates a number of problems: at least project.json is great for creating web applications and class libraries, but at the same time it does not allow unification with other application models.
We had two ways. The first was the transfer of all .NET projects to project.json. This would require us to create / modify a toolkit that affects all types of projects in Visual Studio, Xamarin, and our partners, such as Unity. We would need to extend project.json to support all the types of build required by each of these types of projects, as well as providing migration history. Another way would be to create a bridge between .xproj and .csproj projects so that the latter could 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 now has to choose between .xproj and .csproj, which only adds more options and complexity.
Considering the options above, it became obvious that it would be easier to move .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 abandon the benefits of project.json. So, we plan to extend .csproj to support missing functionality:
- No listing of files in the project
- Using the CLI tool to perform any operations on a project file, although in most cases you will not have to edit the file itself.
- Creating a package using only the project
- Multi-targeting
Since the whole .NET will use the same set of tools, then you can do it later and improve MSBuild. We will request feedback from customers and the community about supporting JSON instead of XML, reducing the number of excessively detailed files generated by our tools, etc. With the use of a single stack, these enhancements will work for all .NET projects.
The first wave will be changes in Visual Studio "15" RTM: when opening 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 have 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. Going forward, we will try and announce the main changes through this blog first as we are ready to provide more context about what is changing and why.
What's Next
Next week we will write about .NET Standard: how we plan to make it easier to share code for all types of .NET projects.
Source: https://habr.com/ru/post/301622/
All Articles