Core 2.0 dll real-time update, https, dependency package change problems and solutions, real-time update https

Core 2.0 dll real-time update, https, dependency package change problems and solutions, real-time update https

 

Today, all development environments have been migrated to Visual Studio Code + command line compilation and release under mac OS, and the running server is CentOS7, which is not associated with windows. As long as the Relese is compiled and runs successfully in the same local running environment as the server, it is not difficult to migrate to the Real Server.

 

The following are the three problems encountered after the migration to version 2.0 and their solutions.

 

1:Sometimes the dll is not updated in real time.(Not every time, and this happens only on Centos) sometimes you need to upload all edge files related to the dll together (for example, supporting xxx. config. json, xxx. runtime. json), it will be updated immediately after the application is restarted (note that this is to restart the application), otherwise the restart program is invalid, once this situation occurs, even after the system is restarted (note that the system is restarted), it still loads the old dll. After several hours, it will load the latest dll only after manual restart of the system.

Although it cannot be said in the truth, this is an actual case. I don't know why, and I don't have to worry about it. This kind of mechanism can be proved from the aspect: when you are running the service normally, you can update or even delete the dll in the running directory. If you do not restart, the running program will not be affected, the loading mechanism of linux is different from that of mac and windows. It may be that after all the existing dll files are copied to a certain place, in addition, you must compare the time and content of the supporting json file before it runs.

It is unclear whether other linux systems will do the same.

 

 

2:Https configuration is different from previous

Kestrel has evolved into an independent and complete server, so there is no problem in coping with real requests. However, the method for loading https in versions 1.1 and below is no longer applicable. You need to change it to the following method:

Var WebServer = new WebHostBuilder (). useKestrel (options => options. listen (IPAddress. any, servicePort, listenOptions => {listenOptions. useHttps (new X509Certificate2 ("your. pfx "," pfx File Password "); options. limits. maxConcurrentConnections = 100; options. limits. maxConcurrentUpgradedConnections = 100; options. limits. maxRequestBodySize = 10*1024 ;})). useContentRoot (AppContext. baseDirectory ). useStartup <Startup> (). build (); WebServer. run ();

 

I believe many people use letsensecret to obtain https. The original key is not in the pfx format. You can simply find an online conversion method.

 

3,Dependent package change

I have never used preview 3, but migrated from preview2 to the official version 2.0. Maybe you will encounter loading View after migration like me, "Cannot find compilation library location for package 'Microsoft. win32.Registry ", a glance at the package name, scared to death, actually it is not necessarily associated with win32. Solution:

Add the following in csproj:

<MvcRazorExcludeRefAssembliesFromPublish>false</MvcRazorExcludeRefAssembliesFromPublish>

And:

<PackageReference Include = "Microsoft. Win32.Registry" Version = "4.4.0"/>

Make sure that the refs folder exists in your running directory after compilation and release, which contains basic dll System. xxxx and Microsoft. xxx.

This is only one of them. When I searched for this problem on Google, I also found that someone else encountered a similar package named Cannot find. The truth is the same.

 

Which of the following is not solved?

 

1. Currently, I have compiled the project into a universal dll for the entire platform. The dll compiled by mac is run in centos (to windows). The Actual dependency package is saved in the CLR installed by the system. Another way is to specify the runtime during the compilation process and compile it for centos to obtain a complete running package with full binary and green security deployment (with a large capacity ), it can be directly run in the production environment. In this case, I only compiled it on windows in 1.0 beta. Now mac cannot be compiled, and the command line does not respond after 20 minutes.

 

2. If you want to try Visual Studio for Mac, but cannot Release, you cannot configure it in the GUI. After setting it to Release, it is useless to change the configuration of csproj to Release manually, give up (of course, this is my personal ability, believe that others can ).

 

3. I chose CentOS 7 because it has a Minimal version and has low requirements on memory and other resources. It is not because it is the Redhat twins. If any one of them finds that there is a better cost-effective Linux, I also hope to recommend a copy. Thank you first.

 

4. Although core is officially cross-platform, Microsoft still has another nuclear weapon: Does. net native have any of the following? Since windows phone is supported only, it is no sound.

 

Just published for one day, there may be more migration issues to be found