在Registering 2012中将Oracle.DataAccess注册为SQLCLR程序集存在的问题

Question

编辑3.5 (意思是在最后一次更新中将项目3放在下面，但忽略了)。唉.)

看看装配注册是如何为我的问题失败的，看看我能够从ProcExplorer跟踪中推断出哪些有限的信息，就会让我在一些事情上得出一些结论。没有解决办法，只有几个推论

1. Microsoft希望在某一时刻允许加载Framework2.0程序集。我作出这一推断的依据是，如果它们完全绑定到排除它们的概念中，验证可能会失败，立即检查程序集的框架元数据。如果在2008年R2中加载4.0个组件，这一失败将是无稽之谈--与之相反的是严厉和具体的错误，说“你的斯哈尔特不行”。

2.如果我对包含2.0程序集的2008R2数据库进行升级，将加载该程序集并在SQL 2012数据库中启动该程序集的函数。因此，执行基于2.0的程序集的能力是非常重要的。让它们通过加载程序是个窍门--因此，我更加相信，发现一个补丁或SP突然支持CLR中的2.0框架程序集不会让我感到惊讶。

3. PERMISSION_ SET =--我认为，无论是有意更改还是错误，SQL2012__中隐含的一些验证语义已经发生了变化。我的经验使我相信，以前版本的Server在指定PEVERIFY /MD (不检查非托管指针)时执行相当于PERMISSION_SET = UNSAFE，而在未指定时执行PEVERIFY /IL。但是，在我看来，在SQL 2012中，CLR验证程序执行PEVERIFY /IL ，而不考虑不安全权限标志的。我很想知道是否有人能证实这个理论*

EDIT2

在对这个问题进行了持续的研究之后，我还没有找到一个解决方案，只有对这个项目进行改造，才能使用微软几年前创建的现在不受欢迎的System.Data.OracleClient提供商。此外，进一步的研究和电子邮件让我相信至少有一两个“电池不包括”通知，关于在SQL2008R2和SQL2012之间对程序集验证的更改--这个程序集似乎正好指向了这一点。关于SQLCLR程序集注册问题的几篇博客文章已经导致断言验证过程中没有发生任何变化，但是在两个数据库之间注册相同的程序集会产生一个无法解释的问题。我找不到SQLServer是如何验证程序集的，所以现在，我继续在黑暗中(完全)寻找一个解决方案.*

在我们的数据库中存在一个长期存在的SQLCLR项目，该项目对Oracle数据库进行各种关键查询。这个项目已经运行了六年，已经从SQL 2005中的32位程序集迁移到2008 R2的64位程序集。

尽管MS 2012升级顾问只指出了SQLCLR迁移涉及某些地理类型的一般问题，但我还是有一种鬼鬼祟祟、丑陋的怀疑--这种迁移可能真的是有问题的。可以肯定的是，我发现将这个项目迁移到Server 2012现在出现了我担心的棘手问题。

在尝试注册此64位Oracle.DataAccess.dll (2.112.1.0)时，数据库建议程序集“失败验证”，因为它在Server 2008R2 (及其祖先)中生活得很愉快。编辑:我的理解一直是，授予不安全权限的程序集不会通过验证检查。这不对吗？

以下是错误响应的摘录：

[ : Oracle.DataAccess.Client.OracleDatabase::Startup][mdToken=0x6000021][offset 0x00000048][found unmanaged pointer][expected readonly address of value 'Oracle.DataAccess.Client.OpoConValCtx'] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Startup][mdToken=0x6000021][offset 0x00000080][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Startup][mdToken=0x6000021][offset 0x000000E3][found unmanaged pointer][expected readonly address of value 'Oracle.DataAccess.Client.OpoConValCtx'] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Startup][mdToken=0x6000021][offset 0x0000011B][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Shutdown][mdToken=0x6000023][offset 0x0000003C][found unmanaged pointer][expected readonly address of value 'Oracle.DataAccess.Client.OpoConValCtx'] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Shutdown][mdToken=0x6000023][offset 0x00000073][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleTransaction::Commit][mdToken=0x600002f][offset 0x0000008F][found unmanaged pointer][expected readonly address of value 'Oracle.DataAccess.Client.OpoTxnValCtx'] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleTransaction::Commit][mdToken=0x600002f][offset 0x000000A6][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleTransaction::Dispose][mdToken=0x6000034][offset 0x0000001E][found unmanaged pointer][expected Native Int] ...

认识到SQLCLR在2012年使用的是.NET 4.0，我想可能同一个DLL的4.0版本可能会解决这个问题。所以我下载了ODAC 12.1.0.1的64位版本，它提供了这个库的4.0特定版本。然而，也可以看到类似(但不完全相同)的程序集创建/验证失败--特别是在“无法验证非托管指针类型”方面。

然后，我尝试使用Oracle.DataAccess (Oracle.ManagedDataAccess)的托管代码版本，该程序集依赖于另一个程序集，该程序集也由于它不是“纯”PE格式程序集而导致注册失败(随后的研究使我相信它有一个不允许的MSIL和程序集的混合物)。因此，对我来说，这意味着托管代码版本永远无法加载到SQLCLR中。

因此，到目前为止，我只剩下几个问题和几个答案。确切地说，在2005/2008/2008R2和2012年间，程序集验证发生了哪些变化，从而阻止了给定程序集的验证？是否有任何选项或解决方案可以让Oracle.DataAccess注册？如果失败，将使项目重新配置/重定向到.NET 4.0。从我们的系统中删除这个组件将是一个巨大的头痛，因此，任何解决方案或建议将是非常感谢的。

Answer 1

实际上，Server 2012使用的是.NET Framework4.0，而且只有这一点。您不可能在Server中加载多个版本的CLR。这是故意的。Server 2012也不允许加载混合程序集。您可以做的是创建一个包含当前.NET 2.0功能的单独(Web)服务。然后从您创建的纯.NET 4.0CLR程序集中调用该服务上的方法。我认为这是最有可能解决你的问题的方法。