РЕДАКТИРОВАТЬ 3.5 (Представьте пункт 3 ниже в последнем обновлении, но пропущено. Увы...)
Глядя на то, как регистрация сборки выходит из строя для моей проблемы, и глядя на то, что ограниченная информация, которую я могу сделать из следов ProcExplorer, приводит меня к некоторым выводам по нескольким вещам. Нет решений, всего несколько выводов
1. Microsoft в какой-то момент хочет, чтобы сборки Framework 2.0 были загружены. Я делаю этот вывод на том основании, что если бы они были связаны исключительно с понятием их исключения, проверка может завершиться неудачей с немедленной проверкой метаданных рамки сборки. Ошибка будет аналогичной загрузке 4.0 сборок в 2008R2 - с суровыми и конкретными ошибками обратного, говоря, что вы не должны делать.
2. Если я выполняю обновление до базы данных 2008R2, содержащей сборку 2.0, сборка загружается и функции из нее будут запускаться в базе данных SQL 2012. Таким образом, возможность выполнять сборки на основе 2.0 очень много. Получение их мимо загрузчика - это трюк - и, следовательно, усиливает мое убеждение, что меня не удивит, что я обнаружил патч или SP, которые внезапно включили 2.0 сборки сборки в среде CLR.
3. Я считаю, что с помощью преднамеренного изменения или ошибки некоторые семантики проверки, подразумеваемые PERMISSION_ SET = UNSAFE, были изменены в SQL2012. Мой опыт заставляет меня поверить, что предыдущие версии SQL Server CLR Verifier выполняли эквивалент PEVERIFY /MD, когда указан PERMISSION_SET = UNSAFE (не проверяя такие вещи, как неуправляемые указатели), и PEVERIFY /IL, когда это не так. Однако мне кажется, что в SQL 2012 верификатор CLR выполняет PEVERIFY /IL независимо флаг разрешения UNSAFE. Я хотел бы найти, мог ли кто-нибудь проверить эту теорию *
EDIT2
После продолжения исследований по этой проблеме я еще не нашел решения, не достраивающего проект, чтобы использовать устаревший поставщик System.Data.OracleClient Microsoft, созданный несколько лет назад. Кроме того, дальнейшие исследования и электронные письма заставляют меня поверить, что хотя бы одна или две "батареи не включены" уведомляют об изменениях в проверке сборки между SQL 2008R2 и SQL 2012 - и эта сборка, похоже, указывает именно на это. Более чем несколько сообщений в блоге по вопросам регистрации сборки SQLCLR привели к утверждениям, что ничего в процессе проверки не изменилось, но регистрация одной и той же сборки между двумя базами данных породила необъяснимую проблему. Я не могу найти, как SQLServer проверяет сборку, поэтому на данный момент я продолжаю искать решение (ну, полностью) в темноте... *
В нашей базе данных MS SQL Server существует давний проект SQLCLR, который делает различные критические запросы для базы данных Oracle. Этот проект работает уже около шести лет, он был перенесен из 32-разрядной сборки в SQL 2005 и в 64-разрядную сборку для MS SQL Server 2008 R2.
Несмотря на то, что советник по обновлению MS SQL 2012 указал только на общие проблемы с миграцией SQLCLR в отношении определенных географических типов, у меня было скрытое, уродливое подозрение, что эта миграция может быть действительно проблематичной. Разумеется, я обнаружил, что перенос этого проекта в SQL Server 2012 теперь представляет собой то, что я боюсь, является неразрешимой проблемой.
При попытке зарегистрировать тот же 64-разрядный файл Oracle.DataAccess.dll(2.112.1.0), который сейчас живет в SQL Server 2008R2 (и его предках) в течение некоторого времени, база данных теперь сообщает, что сборка "не работает" проверка". Изменить. Мое понимание всегда заключалось в том, что сборка, предоставляющая разрешения UNSAFE, не проходит проверку проверки. Это неверно?
Ниже приведен фрагмент ответа об ошибке:
[ : 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, я подумал, что, возможно, версия 4.0 той же DLL может решить проблему. Поэтому я загрузил 64-разрядную версию ODAC 12.1.0.1, которая предоставила 4.0 конкретную версию библиотеки. Однако были обнаружены сходные (но не идентичные) сбои сборки/проверки сборки, особенно в отношении "неуправляемых типов указателей не могут быть проверены".
Затем я попытался использовать управляемые кодовые версии Oracle.DataAccess(Oracle.ManagedDataAccess), и эта сборка зависит от вторичной сборки, которая также терпит неудачу регистрации из-за того, что она не является "чистой" сборкой PE-формата (в последующих исследованиях заставил меня поверить, что у него есть запрещенная смесь MSIL и сборка). Таким образом, для меня это означает, что управляемая версия кода никогда не может быть загружена в SQLCLR.
Поэтому я остаюсь на этом этапе с вопросами и несколькими ответами. Что, собственно, изменилось в отношении проверки сборки между 2005/2008/2008R2 и 2012 годом, которая теперь предотвратит проверку данной сборки? Существуют ли какие-либо опции или решения, позволяющие получить Oracle.DataAccess для регистрации? В противном случае это приведет к перенастройке/перенастройке проекта в .NET 4.0. Устранение этого компонента из нашей системы было бы монументальной головной болью, поэтому любые решения или предложения были бы весьма полезны.
