本子之上,Net程序脱离

本文转载   https://walterlv.github.io/dotnet/2017/09/22/dotnet-version.html ,感谢  吕毅 (包含链接: https://walterlv.github.io )

Net 框架目前逐步在普及了,仍然有很多人在寻找如何让.Net程序脱离.NET框架的方法。现成的工具有 Xenocode 的postbuidle或者vas,还有 Salamander .NET Linker .

当我们编译程序目标框架选为 .Net Framework 4.5/4.6/4.7 时,CLR 运行时是如何判断我们究竟应该用哪一个 .Net Framework 呢?.Net Framework 的版本到底由哪些部分组成?我们编译 .Net Framework 时选择的版本决定了什么?

另外还有 MaxToCode 作者以前做的 framework linker. 以及一些支持注册表模拟和文件模拟的打包工具molebox,thinstall等.


最后还有某网友(应其要求隐去网名) 兜售的一个实现方法.

让我对这个问题产生兴趣的原因是:

Xenocode的是使用了一个虚拟机环境,模拟框架需要的 注册表信息和文件信息.Xenocode号称的生成nativa代码功能实际上就是指的这个功能.我测试了几个程序打包,兼容性似乎不怎么好. 不知道是不是因为机器上已经安装了框架的原因。

  • 我将程序编译的目标框架选为 .Net Framework 4.7;在一台安装了 .Net Framework 4.6 的电脑上提示缺少 .Net Framework 4.7;删除了随编译一起生成的 app.config 文件后程序能够正常运行。
  • 另一个程序,我明明将程序编译的目标框架选为 .Net Framework 4.5,但在一台没有安装任何额外 .Net Framework 的 Windows 7 的电脑上提示缺少的是 .Net Framework 4.0。

Jason做的 framework linker,以前我也使用过, 他的实际上是利用了 Remotesoft的内核文件,然后自己实现了一个loader。好像是使用的早期的内核文件,兼容性也不太好。

这里的疑点在于为什么以上两种看似类似的情况,提示的框架版本却不同。其中的 app.config 文件成为了调查此问题的突破口。

Salamander .Net Linker ,Remotesoft的一个产品,没有可以下载的,但是其兼容性似乎很不错。移动的飞信软件就利用了它的核心。

配置支持的运行时

观察程序附带的 app.config 文件,我们发现支持的运行时版本是 v4.0,sku 版本是 4.7。

<configuration>  
   <startup>  
      <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7" />  
   </startup>  
</configuration>  

疑点:

  1. 为什么我们基于 .Net Framework 4.7 开发的程序运行时版本是 4.0?
  2. sku 是什么?

微软的官方文档给了我们解答:supportedRuntime Element。

  • version:用于指定此应用程序支持的公共语言运行时(CLR)的版本。
  • sku:stock-keeping unit(官方中文为“库存单位”,然而依然不懂这个词的意思),用于指定此应用程序支持的 .Net Framework 发行版本。

version 的值可取:

.NET Framework 版本 version 值
忽略早期版本 忽略早期版本
2.0 “v2.0.50727”
3.0 “v2.0.50727”
3.5 “v2.0.50727”
3.5 “v2.0.50727”
4.0-4.7 “v4.0”

sku 的值可取:

.NET Framework version sku 值
4.0 “.NETFramework,Version=v4.0”
忽略中间版本 忽略中间版本
4.5 “.NETFramework,Version=v4.5”
4.5.1 “.NETFramework,Version=v4.5.1”
4.5.2 “.NETFramework,Version=v4.5.2”
4.6 “.NETFramework,Version=v4.6”
4.6.1 “.NETFramework,Version=v4.6.1”
4.6.2 “.NETFramework,Version=v4.6.2”
4.7 “.NETFramework,Version=v4.7”

于是我们发现,其实无论我们将程序的目标框架选为 .Net Framework 的哪一个 4.x 版本,CLR 运行时都是用 v4.0 表示的。微软的描述是:

对于支持 .NET Framework 4.0 或更高版本的应用程序,version 属性指示 CLR 版本,这是 .NET Framework 4 及更高版本的通用版本,而 sku 属性指示应用程序所针对的单个 .NET Framework 版本。

其实看到这里我们就能有一个看似不错的解释:

  1. 无论我们选择的目标框架是 .Net Framework 4.x 的哪一个版本,用于指定 CLR 运行时版本的 version 值都是 v4.0;
  2. CLR 运行时会根据配置文件的 sku 值决定应该采用那一组运行库来为程序运行提供支持。

某网友的方法似乎是利用remotesoft的核心和飞信的框架,因为他并没有免费公开方法,从他给出的样例可以看到有remotesoft的核心文件以及飞信的框架程序。

.Net Framework 的组成以及各部分的版本

我们需要寻找到 .Net Framework 的本质,不然如此错综复杂的版本号系统真把我搞懵了。

微软在 .NET Framework Versions and Dependencies 中说到:

每个版本的 .NET framework 都包含公共语言运行时 (CLR)、基础库和其他托管库。

于是我们谈论 .Net Framework 的版本其实应该分三个不同的部分来谈:

每个新版本的 .NET Framework 都会保留早期版本中的功能并会添加新功能。 CLR 有其自己的版本号标识。 虽然 CLR 版本并不总是递增的,但 .NET Framework 版本号在每次发布时都会递增。 例如,.NET Framework 4、4.5 和更高版本包含 CLR 4,而 .NET Framework 2.0、3.0 和 3.5 包含 CLR 2.0。 (没有版本 3 的 CLR。)

从官方文档给出的表格当中我们可以确信:.Net Framework 4.0/4.5/4.6/4.7 包含的 CLR 版本都是 4.0。

这里要介绍的方法是直接利用飞信的框架来实现脱离 .Net framework运行。

CLR 的更新

然而,不相信微软的 CLR 可以完全没有 BUG,既然 CLR 版本都是 4.0,那么微软对 CLR 运行时的更新怎么处理?安装了 .Net Framework 4.5/4.6/4.7 会如何提升 CLR 的稳定性和安全性?

在 Targeting and Running .NET Framework apps for version 4.5 and later 中,解释了 CLR 的更新机制——就地更新(in-place update)。这篇文章 .NET 4.5 is an in-place replacement for .NET 4.0 对这种就地更新方式有比官方文档更详细的解释,并且还附带自己的一些试验(含代码)。不过文章是 2012 年写的,部分结论现在看来已经过时(因为在我的 Windows 10 配 .Net Framework 4.7 上结论已经不一样),不过对我理解就地更新本身非常有帮助,也为后续调查提供了更清晰的思路。

微软对 .Net Framework 4.x 框架就地更新的说明是:

.NET Framework 4.5 是替代计算机上的 .NET Framework 4 的就地更新,同样,.NET Framework 4.5.1 4.5.2、4.6、4.6.1、4.6.2 和 4.7 是对 .NET Framework 4.5 的就地更新,这意味着它们将使用相同的运行时版本,但是程序集版本会更新并包括新类型和成员。 在安装其中某个更新后,你的 .NET Framework 4.NET Framework 4.5 或 .NET Framework 4.6 应用应继续运行,而无需重新编译。 但是,反过来则不行。

也就是说,无论我们在开发时指定目标框架的版本是 4.x 的哪一个,在运行时,CLR 环境都是 4.0。但是新的 .Net Framework 会带来更新版本的 CLR,这个 CLR 会直接替换掉旧的 CLR。.NET 4.5 is an in-place replacement for .NET 4.0 文章中 .Net Framework 基础库也是就地更新的;但我实际实验的情况是每一个不同的 .Net Framework 基础库有自己单独的文件夹,目前尚不清楚这个改变是从 .Net Framework 的哪一个版本开始的,但一定是 4.5.1、4.5.2、4.6 这三个版本中的一个。

图片 1

首先下载一个飞信的程序安装。在安装目录中会有 VMDotNet 目录。这个就是.Net框架虚拟环境需要的文件。

解决一开始的疑问

于是,本文一开始的疑问就全部明晰了:

  1. 不管是 .Net Framework 4.5 的还是 4.7 的那两个程序,都是靠 4.0 版本的公共语言运行时(CLR)运行起来的;
  2. 如果没有安装 4.0 版本的 CLR,则会弹出提示需要安装 .Net Framework 4.0 版本才能运行,而不管我们的程序目标框架是 .Net Framework 4.x 的哪一个版本;
    • 虽然说文案说的是 .Net Framework,但其实需要的是 CLR
  3. 如果已经安装有 4.0 版本的 CLR(可能随 .Net Framework 4.5/4.6 安装),我们程序的目标框架是 .Net Framework 4.7,但 .Net Framework 基础库并没有安装 4.7 版本,则运行时会提示需要安装 .Net Framework 4.7;
    • 这个提示是 4.0 版的 CLR 弹出的,是根据 supportedRuntime 中指定的 sku 值来决定的

直接把整个目录提取出来。

参考资料

  • supportedRuntime Element - Microsoft Docs
  • .NET Framework Versions and Dependencies - Microsoft Docs
  • .NET 4.5 is an in-place replacement for .NET 4.0 - Rick Strahl’s Web Log
  • app config - What does “SKU” (attribute) mean in C#? - Stack Overflow
  • .net - What happens if I remove the auto added supportedRuntime element? - Stack Overflow

本文会经常更新,请阅读原文: https://walterlv.github.io/dotnet/2017/09/22/dotnet-version.html ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

如何利用这个虚拟环境运行 自己的 .Net 程序呢?很简单,一个命令行搞定。在 VMDotNet 目录里面会找到一个 FetionVM.exe 。这个是虚拟环境的loader。

使用方法: FetionVM.exe pathtoyoureexe。就是直接把你的 .Net 程序 作为命令行参数传递给 FetionVM.exe 就可以在这个虚拟环境中执行你的。net程序了。

最好再自己写一个启动程序,首先检查系统是否安装了。Net框架,如果有直接运行。没有调用虚拟环境运行。

这个启动程序飞信也有,如果不想自己写就直接拿飞信安装目录中的 Feition.exe,但是这样的话 你自己的.Net程序的名字必须叫 FeitionFX.exe 。把它和Feition.exe 放在同一目录下,直接执行 Feition.exe 即可。

另外,如果你对。Net程序使用了加密保护,需要注意一下,目前市面上的大部分。Net加密工具加密后的程序集不能在这个虚拟环境中运行的。

这个东西除了能实现脱离 。net框架运行外,还有另外一个副作用--让。net程序运行在指定版本的 。net 框架中.

以上内容未经最后证实。

转自:

本文由明仕msyz手机版发布于旅游-环球旅讯,转载请注明出处:本子之上,Net程序脱离

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。