Shulou(Shulou.com)06/01 Report--

one。 The choice of scheme

In fact, this has been introduced in the previous article, the current. Net core,. Net Framework,mono for Xarmain and so on all have their own runtime, although they all use C # syntax, but class libraries cannot directly call each other without using portable or standard libraries. With the upcoming release of. Net standard 2.0, the application scenario of. Net core (asp.net core) will become more and more common, and the need for compatibility of legacy projects will become stronger and stronger. Oss.common will also encounter this problem, so I will extend its. Net standard support.

As the current project is still in use in several .net framework projects, so that the support for the version of net45 in the old project can not be lost, so I will keep two sets of solutions, one for the support of. Net Standard, one for the. net framework, two class library projects, sharing the same set of code files, for Framework-specific features through conditional compilation to control. The directory structure on github has been updated. Welcome to check it.

two。 Transplant detection

Before porting, we need to make a general assessment of the migration, understand the coverage area of code changes, and determine the portability of the code. It is recommended to use Microsoft's official Migration Detection tool (ApiPort) or its VS extension. Here I use the vs plug-in. After installing the plug-in, open the solution and view the right-click menu with the following two options:

First, click the second option to configure the migration comparison version to be detected, as shown below:

Click OK after completing the corresponding test version, and click the first option to perform the analysis process. Two reports, html and xsl, will be generated. The html report interface is as follows:

The report will give the corresponding version of the interface coverage, as well as related recommendations, can be said to be more detailed.

three。 Transplant process

After the above testing, we can see that more than 20% of the code of the oss.common project under. Net standard1.4 can not provide direct support. I took a look at it, and it mainly focused on the code related to specific attributes such as configuration, cache, reflection and so on. This is still expected, but it is still a headache to see a pile of red forks. I can't help it. I have to finish the code even if I cry. The steps for migration are described below.

1. Add project files

For the sake of project intuition and convenient management, I renamed the original OSS.Common class library to OSS.Common.NET45, built a new OSS.Common standard library project, and two project files were placed in the same directory, explaining that if vs2015 wants to build a standard library project, you need to build a portable class library first, modify it in the class library property page, if you are not clear, please read the introduction of the previous article.

At this time, if you directly generate the OSS.Common.NET45 project, there will be an error, even if you do not do any actual code operation, mainly because adding portable class libraries requires project.json files for dependency management, when they are in the same directory, nuget will restore the dependencies in project.json by default, although you are currently generating OSS.Common.NET45 projects, there is no way, it is so stupid If you encounter this error, just create a project.json file corresponding to the current project file in the current directory. Here I add the OSS.Common.Net45.project.json file with the following code:

{

"frameworks": {

"net45": {}

}

"runtimes": {

"win": {}

}

}

two。 Code integration

After building the corresponding solution, attach the code file to the new standard library, there will be a lot of errors directly generated at this time, at this time we need to sacrifice the conditional compilation of this big trick, because the future is mainly to maintain the standard library, so I in the old NET45 project on the new NETFW conditional compilation symbols, the rest is a perfect error.

In the process of dealing with compatibility, we will mainly face these problems, 1. The standard library does not support 2. The method of calling standard library is different from that of Framework, 3. Can indirectly complete the implementation of the standard library

Here, I would like to give an example of what I have encountered for your reference:

1. The standard library is not supported at all. The most typical example is the cache module. Under. Net standard, the System.Runtime.Caching class library has been completely removed. There is no way but to use # if NETFW to completely mask the default Cache implementation under the Module module. The default implementation can only be used under Framework (originally intended to implement a cache class by yourself, but found that it may bring unpredictable bug and invalidation).

two。 The calling method of the standard library is different from that of Framework. For example, the IsEnum attribute under Type type needs .gettypeinfo () .IsEnum under net standard. For example, the code:

# if NETFW

If (! enType.IsEnum)

# else

If (! enType.GetTypeInfo (). IsEnum)

# endif

3. You can implement the standard library indirectly. This common ConvertAll method, such as list, is implemented by default in Framework, but not in the standard library. Here, I define one in the ConvertExtention class:

# if! NET40

Public static List ConvertAll (this List list, Func func)

{

If (list = = null)

Return null

Var resultList = new List (list.Count)

List.ForEach (e = > resultList.Add (func (e)

Return resultList

}

# endif

Of course, there will be some other problems, but fortunately, basically all have been solved, if there is not clear, you can download the oss.common code to check it yourself.

four。 Nuget packaged deployment

This is relatively simple, generate the corresponding dll in the two solutions, and add the net45 and netstandard1.4 folders in the lib folder to add the corresponding dll.

It is important to note that it is best to add a separate dependency. For example, under the "System.Security.Cryptography.Algorithms" dll assembly, the Hmacsha1 encryption algorithm of the standard library will not report an error if the dll is not referenced in the calling project, but when the code executes the call, it will pop up an error that the assembly cannot find. Of course, if you find this problem, you can also install it through the nuget online installation command (install-package).

Let me show you my nuget file configuration:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.