net framework enabled disable check activar c# .net sql-server oracle sqlclr

c# - framework - Problemas al registrar Oracle.DataAccess como ensamblado SQLCLR en MS SQL Server 2012



disable clr sql server (1)

De hecho, SQL Server 2012 funciona con .NET Framework 4.0, y solo eso. No hay forma de que pueda cargar múltiples versiones de CLR en SQL Server. Esto es por diseño. SQL Server 2012 tampoco permite cargar conjuntos mixtos. Lo que puede hacer es crear un servicio separado (web) que contenga la funcionalidad actual de .NET 2.0. A continuación, llame a los métodos de ese servicio desde un ensamblado de .NET 4.0 CLR puro que cree. Creo que esta es la solución más probable para su problema.

EDIT 3.5 (Se refiere a poner el Artículo 3 a continuación en la última actualización, pero se pasa por alto. Desgraciadamente)

Ver cómo falla el registro del ensamblaje para mi problema y ver qué información limitada puedo deducir de las huellas de ProcExplorer me lleva a sacar algunas conclusiones sobre algunas cosas. Sin soluciones, solo algunas inferencias

1. Microsoft quiere, en algún momento, permitir que se carguen los ensamblados de Framework 2.0. Hago esta inferencia sobre la base de que si estuvieran exclusivamente vinculados a la noción de excluirlos, la validación podría fallar con una verificación inmediata de los metadatos del marco de una asamblea. La falla sería análoga a la carga de 4.0 ensamblajes en 2008R2, con severos y específicos errores al contrario, diciendo que no debe hacer.

2. Si realizo una actualización a una base de datos 2008R2 que contiene un ensamblado 2.0, el ensamblaje se carga y las funciones de él se activarán en una base de datos SQL 2012. Entonces, la capacidad de ejecutar ensambles basados ​​en 2.0 está muy presente. Conseguir que pasen el cargador es el truco, lo que refuerza mi creencia de que no me sorprenderá descubrir un parche o SP que de repente habilite 2.0 ensamblajes de marco en el CLR.

3. Creo que, ya sea mediante un cambio deliberado o una falla, parte de la semántica de validación implícita en PERMISSION _ SET = UNSAFE ha cambiado en SQL2012. Mi experiencia me lleva a creer que las versiones anteriores de CLR Verifier de SQL Server realizaban el equivalente de un PEVERIFY /MD cuando PERMISSION_SET = UNSAFE se especifica (sin verificar cosas como punteros no administrados), y PEVERIFY /IL cuando no lo es. Sin embargo, me parece que en SQL 2012, el PEVERIFY /IL CLR realiza un PEVERIFY /IL independientemente del indicador de permiso UNSAFE. Me encantaría encontrar si alguien puede verificar esta teoría *

EDIT2

Después de continuar la investigación de este problema, aún no he encontrado una solución para readaptar el proyecto para usar el ahora obsoleto proveedor de System.Data.OracleClient que Microsoft creó hace algunos años. Además, más investigaciones y correos electrónicos me llevan a creer que hay al menos uno o dos avisos de "batería no incluida" sobre los cambios en la validación del ensamblaje entre SQL 2008R2 y SQL 2012, y este ensamblaje parece apuntar precisamente a eso. Más de unas pocas publicaciones en el blog sobre los problemas de registro del ensamblado SQLCLR han llevado a afirmar que no cambió nada en el proceso de validación, sin embargo, registrar el mismo ensamblaje entre dos bases de datos ha generado un problema inexplicable. No puedo encontrar la forma en que SQLServer valida un ensamblado, por lo que en este momento continúo buscando una solución un poco (bueno, completamente) en la oscuridad ... *

Existe un proyecto SQLCLR de larga data dentro de nuestra base de datos MS SQL Server que realiza varias consultas críticas a una base de datos Oracle. Este proyecto ha estado funcionando bien durante aproximadamente seis años, migrando de un ensamblado de 32 bits en SQL 2005 a un ensamblado de 64 bits para MS SQL Server 2008 R2.

A pesar de que el Asesor de actualizaciones de MS SQL 2012 señaló solo problemas generales con la migración SQLCLR con respecto a ciertos tipos geográficos, tuve la sospecha desagradable de que esta migración podría ser realmente problemática. Efectivamente, descubrí que la migración de este proyecto a SQL Server 2012 presenta ahora lo que me temo que es un problema insoluble.

Al intentar registrar este mismo Oracle.DataAccess.dll de 64 bits (2.112.1.0) que ha estado viviendo felizmente en SQL Server 2008R2 (y sus antecesores) durante algún tiempo, la base de datos ahora informa que el ensamblado "falla la verificación". Editar: Mi comprensión siempre ha sido que una asamblea con permisos SEGUROS no pasa por la verificación de validación. ¿Esto no es correcto?

A continuación, se incluye un fragmento de la respuesta de error:

[ : 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] ...

Al darme cuenta de que SQLCLR en 2012 ahora usa .NET 4.0, pensé que quizás la versión 4.0 de la misma DLL podría resolver el problema. Así que descargué la versión de 64 bits de ODAC 12.1.0.1, que proporcionaba la versión específica 4.0 de la biblioteca. Sin embargo, se observaron fallas de creación / validación de ensamblaje similares (pero no idénticas), particularmente en relación con "los tipos de punteros no administrados no se pueden verificar".

Luego traté de usar versiones de código administrado de Oracle.DataAccess (Oracle.ManagedDataAccess), y ese ensamblaje depende de un ensamblaje secundario que también falla en el registro debido a que no es un ensamblado de formato PE "puro" (que la investigación posterior me ha llevado a cree que tiene una mezcla no permitida de MSIL y ensamblaje). Entonces, para mí, significa que la versión del código administrado nunca se puede cargar en el SQLCLR.

Así que me quedé, en este punto, con preguntas y pocas respuestas. ¿Qué ha cambiado exactamente sobre la validación del ensamblaje entre 2005/2008 / 2008R2 y 2012 que ahora evitará que un ensamblaje determinado valide? ¿Hay alguna opción o solución posible para que Oracle.DataAccess se registre? Si eso falla, el proyecto será reconfigurado / redirigido a .NET 4.0 discutible. Eliminar este componente de nuestro sistema sería un dolor de cabeza monumental, por lo que cualquier solución o sugerencia sería muy apreciada.