Core 2.0 的dll实时更新、https、依赖包变更问题及解决_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > Core 2.0 的dll实时更新、https、依赖包变更问题及解决

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

 2017/8/16 15:31:23  梁逸晨  程序员俱乐部  我要评论(0)
  • 摘要:今天所有开发环境已经迁移到macOS下的VisualStudioCode+命令行编译发布,而运行服务器是CentOS7,和windows没什么关联了。只要你Relese编译并在本地有一个与服务器相同的运行环境中运行成功了,迁移到真实服务器不会有什么难度。下面是迁移到2.0版本之后遇到的3个问题及解决办法1:有时候dll不会实时更新(不是每次都会遇到,并且这事情仅发生在Centos上)有时候你需要把与dll相关的所有边缘文件一同传上去(例如配套的xxx.config.json、xxx
  • 标签:解决 问题 HTTP

 

今天所有开发环境已经迁移到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的方法已经不适用,需要改为如下的办法:

class="brush:csharp;gutter:true;">            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 之后,就无声无息了。

 

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

 

发表评论
用户名: 匿名