Porting a large project to .NET Core
Given: a system with a 10-year history, developed in C #, with a rather large code base. The server part of the system is a web service (hosted in IIS, SOAP protocol), actively working with the database, caching in Redis, with various security checks, searching in Elasticsearch.
Objective: to ensure the operation of the system on Linux without loss of performance with minimal gestures.
This suggests 3 possible solutions to the problem:
The third option is discarded immediately, it will take several person-years of development to rewrite. Remain Mono and .NET Core.
')
Although the technology has appeared for a long time and has been used successfully (for example, in Xamarin) there are several doubts about the further development of Mono:
As a result, the choice fell on the .NET Core. The task is complicated by the need to simultaneously support both .NET 4.6.1 implementation and .NET Core in the same 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 new .NET Core SDK (fresh builds are published on the project page ). Then for each csproj file you need to create its analogue - project.json. Go to the folder with each project, in the command line, enter the
Project.json will appear, you need to 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 as projects. In each project.json, you should register the dependencies on the projects (dependencies section), try 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.
Our application encountered the following problems:
This is all about the standard library API. Obviously, you should recycle the code using native calls (in our case, the code for checking access rights and working with security descriptors). Files with such legacy code were excluded from compilation (exclude section in project.json) or disabled by 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 support the SOAP protocol with a special desire. For ourselves, we decided to abandon SOAP and transfer the web service to REST. There are no problems, ASP.NET Core is no different from ASP.NET Web API. There are DI with whom you can live. Controllers, routs, 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 managing access rights, integration with LDAP.
The first problem can be solved by setting our Apache application with the necessary extension and enabling reverse proxy. The library for managing the ACL 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.
It is necessary to carry out load tests until complete certainty. But in general, technology has the right to life, although there are problems with tuling: 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 the operation of the system on Linux without loss of performance with minimal gestures.
This suggests 3 possible solutions to the problem:
- Use mono
- Use .NET Core
- Rewrite everything in Java \ Go \ Python
The third option is discarded immediately, it will take several person-years of development to rewrite. Remain Mono and .NET Core.
')
What's wrong with mono
Although the technology has appeared for a long time and has been used successfully (for example, in Xamarin) there are several doubts about the further development of Mono:
- Acquisition of Xamarin by Microsoft. Microsoft publicly bets on .NET Core and invests money in it. The .NET Core development process is open, release dates, roadmap, etc. are available. What will happen to Mono outside Xamarin question. Will Microsoft simultaneously develop 2 competing .NET implementations?
- Lack of feedback. What is Mono's performance? Can it be used in an enterprise? There is almost no talk about Mono at conferences, it feels like nobody uses technology
As a result, the choice fell on the .NET Core. The task is complicated by the need to simultaneously support both .NET 4.6.1 implementation and .NET Core in the same code base, since not all clients can be updated and backward compatibility is needed.
Migrating project files
First you need to install Update 3 for Visual Studio 2015 and the new .NET Core SDK (fresh builds are published on the project page ). Then for each csproj file you need to create its analogue - project.json. Go to the folder with each project, in the command line, enter the
dotnet new .Project.json will appear, you need to 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 as projects. In each project.json, you should register the dependencies on the projects (dependencies section), try 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 will not work
Our application encountered the following problems:
- app.config - The corefx developers have abandoned the outdated API for working with configuration files. Now the configuration is recommended to be stored in the json file.
- PerformanceCounter - Windows specificity, for use on a non-Windows platform, you should look for some alternative.
- DataSet, DataTable - is considered obsolete API.
- LCID for CultureInfo - the culture no longer has the LCID property; CultureInfo can now be created only by name.
- Assembly Property of a Type Instance — To get a description of an assembly for a type, you must use the GetTypeInfo () extension method. Breaks compatibility with the current code, especially in resource files.
- MachineKey - Windows specific, there is no way to get the unique identifier of the current machine.
- Thread.SetData, Thread.GetData - will be added in the second version of the standard.
This is all about the standard library API. Obviously, you should recycle the code using native calls (in our case, the code for checking access rights and working with security descriptors). Files with such legacy code were excluded from compilation (exclude section in project.json) or disabled by 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 support the SOAP protocol with a special desire. For ourselves, we decided to abandon SOAP and transfer the web service to REST. There are no problems, ASP.NET Core is no different from ASP.NET Web API. There are DI with whom you can live. Controllers, routs, 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 managing access rights, integration with LDAP.
The first problem can be solved by setting our Apache application with the necessary extension and enabling reverse proxy. The library for managing the ACL 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.
It is necessary to carry out load tests until complete certainty. But in general, technology has the right to life, although there are problems with tuling: 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.
Source: https://habr.com/ru/post/312264/
All Articles