我所说的值是包含项目文件的值
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<OtherStuff>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<TargetFrameworkProfile>Client</TargetFrameworkProfile>
<OtherStuff>
</PropertyGroup>
<OtherStuff>
</OtherStuff>
</Project>
基本上我想知道当编译程序集时框架的目标版本,以及目标框架配置文件的可能性.
而且我不是在说现在加载的CLR版本,Environment.Version不是我以后的版本.
理想情况下,解决方案将使用System.Reflection,但如果我必须诉诸其他方法,我会的.
如果您对编译程序集的CLR版本感到满意,可以使用Assembly.ImageRuntimeVersion属性.根据MSDN,该属性：
representing the version of the common language runtime (CLR) saved in the file containing the manifest.
和
By default, ImageRuntimeVersion is set to the version of the CLR used to build the assembly. However, it might have been set to another value at compile time.
当然,这并不给你.NET Framework的特定版本(例如：.NET Frameworks 2,3.0和3.5都在2.0 CLR上).
如果CLR版本不够,您可以尝试“估计”(智能猜测)它所引用的程序集所需的版本.对于.NET 1和4,CLR版本应该是足够的.但是,如果CLR版本为2.0,则不知道是否意味着2.0,3.0或3.5,以便您可以尝试更多的逻辑.例如,如果您看到该程序集引用System.Core(使用Assembly.GetReferencedAssemblies()),那么您将知道该版本为3.5,因为System.Core是3.5中的新增功能.这并不是完全固定的,因为有关的议会可能不会使用大会的任何类型,所以你将无法捕捉到.为了尝试捕获更多的情况,您可以循环遍历所有引用的程序集并检查其版本号 – 也许过滤到只有从System开始的程序集,以避免与其他程序库的误报.如果您看到所引用的任何System.*程序集的版本为3.5.x.x,那么您也可以确定它是为3.5构建的.
正如你所注意到的那样,我不相信TargetFrameworkProfile在Visual Studio之外转义.但是,如果应用程序碰巧有一个app.config文件,Visual Studio可能会将目标框架放在那里.例如,如果您将项目设置为使用4.0客户端配置文件,Visual Studio将创建一个这样的app.config：
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client"/>
</startup>
</configuration>