Porting a large project to .NET Core
Given: a 10-year-old system developed in C # with a fairly large code base. The server part of the system is a web service (hosted in IIS, SOAP protocol), actively working with the database, with caching in Redis, with various security checks, search in Elasticsearch.
Objective: to ensure that the system runs on Linux without loss of performance with minimal body movements.
There are 3 options for solving the problem:
The third option is discarded immediately, the rewriting will take several man-years of development. Remain Mono and .NET Core.
Although the technology appeared a long time ago and has been successfully used (for example, in Xamarin), there are several doubts about the further development of Mono:
As a result, the choice fell on .NET Core. The task is complicated because you need to simultaneously support both .NET 4.6.1 implementation and .NET Core in one code base, since not all clients can be updated and backward compatibility is needed.
First you need to install Update 3 for Visual Studio 2015 and the fresh .NET Core SDK (fresh builds are published on the project page ). Then for each csproj file you need to create an analogue of it - project.json. We go into the folder with each project, enter it on the command line
Project.json appears, remove the line about emitEntryPoint from it if the assembly does not contain the Main method. Next, create an empty sln file, add project.json files to it, like projects. In each project.json, you should register dependencies on projects (the dependencies section), we are trying to compile. If there are no compilation errors, congratulations. The only problem is that the old solution with csproj projects will stop working so that both projects work side by side there is a solution. It looks pretty weird, but it works.
In our application, we encountered the following problems:
That's all for the standard library API. Obviously, you should recycle code using native calls (in our case, access control code and work with security descriptors). Files with such legacy code were excluded from compilation (the exclude section in project.json) or disabled with the conditional compilation directive (NETCOREAPP1_0).
In the current implementation of .NET Core, there is no way out of the box to create a SOAP-based Web service. There is an example with MSDN, where they show how you can, with a special desire, support the SOAP protocol. For ourselves, we decided to abandon SOAP and switch the web service to REST. There are no problems, ASP.NET Core is no different from ASP.NET Web API. There is a DI to live with. Controllers, routes, even swagger works - everything is in place.
There are still big problems: user authentication (IIS used to do this) and which library to use for access control, integration with LDAP.
The first problem can be solved by putting Apache with the necessary extension in front of our application and enabling reverse proxy. A library for managing ACLs has not yet been found.
Visual Studio 2015 Update 3 and Resharper on .NET Core projects work perfectly, there are no problems with debugging and compilation speed. Finally, you can use Docker to deliver the application. Unit tests work.
To complete confidence, you need to conduct stress tests. But in general, technology has the right to life, although there are problems with tuning: for example, msbuild is not supported. I recommend .NET developers to take a closer look and start using .NET Core in their projects. For us, the experience is only positive.
Objective: to ensure that the system runs on Linux without loss of performance with minimal body movements.
There are 3 options for solving the problem:
- Use mono
- Use .NET Core
- Rewrite everything in Java \ Go \ Python
The third option is discarded immediately, the rewriting will take several man-years of development. Remain Mono and .NET Core.
What is wrong with Mono
Although the technology appeared a long time ago and has been successfully used (for example, in Xamarin), there are several doubts about the further development of Mono:
- Acquisition of Xamarin by Microsoft. Microsoft is publicly betting on .NET Core and investing in it. The .NET Core development process is open, release dates, roadmap, etc. are available. What will happen to Mono outside the Xamarin question. Will Microsoft simultaneously develop 2 competing implementations of .NET?
- Lack of feedback. What performance does Mono work with? Can I use it in enterprise? Mono is hardly talked about at conferences, it feels like nobody uses technology
As a result, the choice fell on .NET Core. The task is complicated because you need to simultaneously support both .NET 4.6.1 implementation and .NET Core in one code base, since not all clients can be updated and backward compatibility is needed.
Project file migration
First you need to install Update 3 for Visual Studio 2015 and the fresh .NET Core SDK (fresh builds are published on the project page ). Then for each csproj file you need to create an analogue of it - project.json. We go into the folder with each project, enter it on the command line
dotnet new. Project.json appears, remove the line about emitEntryPoint from it if the assembly does not contain the Main method. Next, create an empty sln file, add project.json files to it, like projects. In each project.json, you should register dependencies on projects (the dependencies section), we are trying to compile. If there are no compilation errors, congratulations. The only problem is that the old solution with csproj projects will stop working so that both projects work side by side there is a solution. It looks pretty weird, but it works.
What won't work
In our application, we encountered the following problems:
- app.config - Corefx developers abandoned the outdated configuration file API. Now it is recommended to store the configurations in a json file.
- PerformanceCounter - Windows specifics, for use on a non-Windows platform, you should look for some alternative.
- DataSet, DataTable - considered obsolete APIs.
- CultureInfo LCID - culture no longer has an LCID property, CultureInfo can now be created only by name.
- The Assembly property of the Type instance - to get the description of the assembly of the type, you must use the GetTypeInfo () extension method. It breaks compatibility with the current code, especially in resource files.
- MachineKey - Windows specifics, there is no way to get a unique identifier for the current machine.
- Thread.SetData, Thread.GetData - will be added in the second version of the standard.
That's all for the standard library API. Obviously, you should recycle code using native calls (in our case, access control code and work with security descriptors). Files with such legacy code were excluded from compilation (the exclude section in project.json) or disabled with the conditional compilation directive (NETCOREAPP1_0).
SOAP
In the current implementation of .NET Core, there is no way out of the box to create a SOAP-based Web service. There is an example with MSDN, where they show how you can, with a special desire, support the SOAP protocol. For ourselves, we decided to abandon SOAP and switch the web service to REST. There are no problems, ASP.NET Core is no different from ASP.NET Web API. There is a DI to live with. Controllers, routes, even swagger works - everything is in place.
There are still big problems: user authentication (IIS used to do this) and which library to use for access control, integration with LDAP.
The first problem can be solved by putting Apache with the necessary extension in front of our application and enabling reverse proxy. A library for managing ACLs has not yet been found.
findings
Visual Studio 2015 Update 3 and Resharper on .NET Core projects work perfectly, there are no problems with debugging and compilation speed. Finally, you can use Docker to deliver the application. Unit tests work.
To complete confidence, you need to conduct stress tests. But in general, technology has the right to life, although there are problems with tuning: for example, msbuild is not supported. I recommend .NET developers to take a closer look and start using .NET Core in their projects. For us, the experience is only positive.