.net 通过查询获取SQL Server上SQLCLR程序集的目标框架版本

我们有许多程序集是用.NET 2.0或.NET 3.5编译的

是否有一种方法可以通过未记录的表、函数等查询数据库中的程序集列表并获取程序集的.NET版本

我们查询了

sys.assemblies

，它确实包含各种程序集信息，但不包括目标框架版本

---

我们正在将08R2实例升级到Windows Server 2012，需要了解哪些程序集当前针对的是.NET 2.0框架，而不是3.5框架，因此我们可以针对它们进行重新编译（或替换，因为我们有许多来自NuGet软件包的程序集，不清楚它们是否针对.NET 3.5）.

您可以查看以下内容的输出：

select * from sys.dm_clr_properties

你应该得到类似于：

name        value
-----------------------------------
directory   C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
version     v4.0.30319
state       CLR is initialized

---

不，没有获取此信息的机制（至少我从未见过或听说过）。如果此信息通过反射可用，则可以创建SQLCLR存储过程或函数来读取

sys.assembly_文件的
content
列，并尝试从中提取它

但是，您可能不需要此信息。如果唯一的原因是确定从SQL Server 2008 R2过渡到SQL Server 2012时可能需要重新编译的内容，则：

为2.0和3.5目标程序集编译的内容之间没有真正的区别。2008 R2链接到CLR 2.0，其中包括.NET Framework版本2.0、3.0和3.5，而2012和更新版本链接到CLR 4.0，后者使用.NET Framework版本4.0和更新版本。因此，当您移动到SQL Server 2012时，为2.0编译的程序集和使用3.5的程序集都链接到您将不使用的CLR版本。因此，如果需要重新编译2.0程序集，可能还需要重新编译3.5程序集。但是
幸运的是，您很可能根本不需要重新编译任何东西。NET对大多数类都具有向后兼容性，所以为2.0编译的东西应该在将来的所有框架版本中都可以使用。事实上，我为项目中的所有程序集（可能只有一个程序集除外）使用了目标框架版本2.0，以便从2005年开始，它们可以跨所有SQL Server版本工作。我在运行任何东西时都没有遇到问题，我的大部分初始测试都是在SQL Server 2012上完成的，而我在2014年和2016年进行了额外的测试，目前还没有遇到任何问题。最大的“问题”是框架版本之间的默认值或行为发生了微小变化（例如，“登记”连接字符串关键字将其默认值从
false
更改为跨一个升级的
true
以及类似的情况）
我的问题不清楚（已重新措辞）。我试图获取程序集的目标框架版本，而不是服务器上的.NET CLR版本。我们正在将08R2实例升级到Windows Server 2012，需要了解哪些程序集当前针对的是.NET 2.0框架，而不是3.5框架，因此我们可以针对它们进行重新编译（或替换，因为我们有许多来自NuGet软件包的程序集，不清楚它们是否针对.NET 3.5）
SELECT*FROM sys.assemblies
如果此查询可以包含多个定义目标框架版本的列，基本上与VS project文件包含的元数据相同，这就是我们要查找的。检查
sys.assemblies
视图将生成
ASSEMBLYPROPERTY
，该属性已关闭，但没有目标框架版本。我们遇到了一个特定程序集的问题，该程序集在将其操作系统升级到Windows Server 2012的测试机器上失败。直到我们将目标框架从.NET 2.0更改为3.5，它才起作用。@ElliotRodriguez在这种情况下，我想真正的问题可能是机器上从未安装完整的2.0框架。如果您再次遇到这种情况，我会确保安装了2.0本身，而不是从3.5开始。我想有可能有些东西不能按预期工作，即使有向后兼容性，或者向后兼容性要求以前的框架版本完全安装。你们的组件到底在做什么？我可以测试它使用的任何特定类吗？我看不出改成3.5会有什么效果。