SQLCLR 使用错误版本的 .NET Framework
在我们的开发服务器最近重新启动期间，SQL Server 开始使用 .NET 4.0 作为 SQLCLR。这意味着在 SQL 中使用 CLR 不起作用，或者至少这是我通过阅读以下来源的理解：
http://software.intel.com/en-us/blogs/2009/10/16/sql-server-2008-sqlclr- net-framework-version/
www.sqlskills.com/BLOGS/BOBB/post/On-SQL-Server-and-NET-40.aspx
我们得到的只是这种类型的错误消息：
消息 6517，级别 16，状态 1，第 1 行无法创建 AppDomain “xxx.dbo[ddl].3”。方法的类型签名与互操作不兼容。
运行该语句（按照 @john-christensen 的建议）
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
有谁知道如何解决这个问题或者我们如何强制 SQL Server CLR 使用早期版本的框架？
During a recent restart of our development server the SQL Server started using .NET 4.0 for the SQLCLR. This means that nothing using the CLR in SQL works, or at least that's my understanding by reading these sources:
http://software.intel.com/en-us/blogs/2009/10/16/sql-server-2008-sqlclr-net-framework-version/
www.sqlskills.com/BLOGS/BOBB/post/On-SQL-Server-and-NET-40.aspx
All we get are error messages of this type:
Msg 6517, Level 16, State 1, Line 1 Failed to create AppDomain
"xxx.dbo[ddl].3". Method's type signature is not Interop compatible.
Running the statement (as suggested by @john-christensen)
select * from sys.dm_clr_properties
results in the following information:
*Name* *Value*
directory C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
version v4.0.30319
state CLR is initialized
Does anyone know how to solve this or how we can force SQL Server CLR to use an earlier version of the Framework?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我遇到了同样烦人的问题。我的数据库中的地理/几何内容都不起作用。我重新安装了一些不成功的 SQL Server，最终（几周后！）发现注册表中的以下键已设置为“1”，
当我将其重置为“0”时，并重新启动计算机，一切又恢复正常了！
I experienced the same annoying problem. None of the Geography/Geometry stuff in my database worked. Took me some unsuccessful reinstalls of SQL server to finally (some weeks later!) find the following key in my registry had been set to '1'
when I reset it to '0', and rebooted the machine, things worked again!
通常，您可以通过在应用程序的配置文件中指定
supportedRuntime标记来强制 .NET 应用程序使用特定的 .NET Framework 版本。因此，您可以尝试在 SQL 实例根路径下的
\Binn文件夹中创建sqlservr.exe.config并在其中指定您只想使用 .NET版本最高 3.5。检查此 MSDN 链接了解配置文件的结构。Typically you can force a .NET application to use a specific .NET Framework version by specifying the
supportedRuntimetag in the application's config file.So you could try creating a
sqlservr.exe.configin the\Binnfolder under the root path of the SQL instance and specify there that you would like to use only .NET versions up to 3.5. Check this MSDN link for the structure of the config file.从这篇文章和我在网上的研究来看，看起来可能会发生相反的情况 - 您可能会注册 4.0 DLL 吗？看来 SQL Server 2008 将始终加载 2.0 CLR，而不是 4.0 CLR。尝试运行这个语句，它会告诉你你的 SQL 服务器正在运行什么版本：
From the article and my research on the web, it looks like the opposite might be happening - could you potentially be registering a 4.0 DLL? It appears that SQL Server 2008 will always load the 2.0 CLR and not the 4.0 CLR. Try running this statement, it will tell you what version your SQL server is running:
在您引用的英特尔帖子中，如果您仔细阅读，它会说：
后来：
我不知道你是如何设法将 .NET 4 之类的东西加载到 SQL Server 2008 R2 中的......
In your post at Intel that you reference, if you read it closely, it says:
And later on:
I don't know how you manage to get something like .NET 4 loaded inside SQL Server 2008 R2....
他们做出了明确的选择，以确保 .NET 4.0 的安装不会产生影响。它不应使用 .NET 4.0 或除新的填充文件 mscoree.dll 和 mscoreei.dll 之外的任何新文件。这些应该与 2.0 运行时向后兼容。您可以运行 Process Explorer 查看加载的 dll 的版本号，以验证它是否运行在正确的运行时。
They made explicit choices to ensure that installation of .NET 4.0 would be non-impactful. It shouldn't be using .NET 4.0 or any of the new files except for the new shim files, mscoree.dll and mscoreei.dll. Those should be backward compatible with the 2.0 runtime. You could run Process Explorer to see the version numbers of the dll's loaded to verify that it is running the right runtime.
我遇到这个问题一天了，更新我的 Windows 和 .NET 框架后，问题消失了。该问题与 .Net 框架有关，请尝试修复它。
I had this problem for a day and after updating my windows and .NET frameworks problem disappeared.the problem relates to .Net framework try to repair it.