Core 2.0 的dll实时更新、https、依赖包变更问题及解决

标签：limits   ext   runtime   最新   content   window   .net   native   更新   

今天所有开发环境已经迁移到mac OS下的Visual Studio Code + 命令行编译发布，而运行服务器是CentOS7，和windows没什么关联了。 只要你Relese编译并在本地有一个与服务器相同的运行环境中运行成功了，迁移到真实服务器不会有什么难度。

下面是迁移到 2.0 版本之后遇到的3个问题及解决办法

 1：有时候dll不会实时更新（不是每次都会遇到，并且这事情仅发生在Centos上）有时候你需要把与dll相关的所有边缘文件一同传上去（例如配套的xxx.config.json、xxx.runtime.json），它才会真正在重启应用程序后立即更新（注意这里是重启应用程序），否则重启程序无效，这个情况一旦出现，哪怕是重启系统后（注意这里是重启系统），它依然加载过去的老dll，过几个小时后再次手动重启系统才会加载最新dll。

虽然道理上是说不通的，但这是我真实遇到的事例，原因嘛，不知道，也没空折腾，这类机制可以从侧面得到证明： 你正常运行着服务的时候，可以去运行目录里面更新、甚至删除dll，如果不重启，正在运行的程序不会受到影响，说明linux版本的加载机制不同于mac和windows，它可能是把现有dll全都复制到某个地方后，并且要同时比较配套json文件的时间戮和内容后才会运行。

别的linux会不会也这样，不清楚。

2：https配置不同以往

Kestrel已经演化成独立完整的服务器，应对真实请求没什么问题了， 但是1.1及以下版本加载https的方法已经不适用，需要改为如下的办法：

            var WebServer = new WebHostBuilder()
            
            .UseKestrel(options => options.Listen(IPAddress.Any, servicePort, listenOptions =>
            {
                listenOptions.UseHttps(new X509Certificate2("你的.pfx", "pfx文件的密码"));
                options.Limits.MaxConcurrentConnections = 100;
                options.Limits.MaxConcurrentUpgradedConnections = 100;
                options.Limits.MaxRequestBodySize = 10 * 1024;
            }))
            .UseContentRoot(AppContext.BaseDirectory)
            .UseStartup<Startup>()
            .Build();

            WebServer.Run();

相信很多人通过LetsEncript来获取https，原始得到的密钥不是pfx格式，随便找个在线转换就可以了。

3, 依赖包变更

我没有用过 preview 3， 而是从preview2迁移到正式版2.0的， 可能你会和我一样迁移后遇到加载View的时候，出现“Cannot find compilation library location for package ‘Microsoft.Win32.Registry” ， 晃眼一看这包的命名，吓死人，实际它和win32没什么必然关联。解决办法：

在csproj中添加：

<MvcRazorExcludeRefAssembliesFromPublish>false</MvcRazorExcludeRefAssembliesFromPublish>

以及：

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

确保编译发布后你的运行目录下存在refs文件夹，里面都是System.xxxx、Microsoft.xxx 这些基本dll，就行了。

这仅是其中一例，我在Google搜索这个问题的时候，还发现别人遇到了类似的其它包Cannot find，道理都一样。

下面是尚未解决的，等待各位探讨

1，目前我是把项目编译为全平台通用的dll，mac编译出来的dll放到centos运行（放到windows也行），实际依赖包保存在系统安装的CLR中。另有一种办法是编译过程中指定runtime，针对centos编译，得到完全二进制、绿色安全部署的完整运行包（容量会很大），可以扔到生产环境中直接就运行了，这种情况我只在1.0 beta的时候在windows上成功编译出来，现在mac没法编译， 命令行假死20分钟没反应。

2，想尝试Visual Studio for Mac，但是搞不定Release发布，GUI中没法配置，设置为Release后，晃眼换个窗口再回去又变回Debug（我明白windows visual studio中统一在解决方案中配置的道理，没用），手动修改csproj的相关配置为Release也没用，就放弃了（当然这是我个人能力不行，相信别人是可以的）。

3, 我之所以选择CentOS 7 是因为它有一个Minimal版本，内存等资源要求较低，并不是因为它是Redhat的双胞胎，如果哪位同好发现还有更好性价比的Linux，还望推荐一份，先行谢过。

4，core虽然正式跨平台了，但是微软还有另一件核武器吧： .net native 还有没有下文？ 自从看到仅支持 windows phone 之后，就无声无息了。

刚正式发布一天，可能还会有更多迁移问题待发现

Core 2.0 的dll实时更新、https、依赖包变更问题及解决

标签：limits   ext   runtime   最新   content   window   .net   native   更新   

原文地址：http://www.cnblogs.com/kvspas/p/7086396.html