Tenemos un proyecto de Entity Framework con varios modelos configurados con .NET 4 y VS2010. Entonces tenemos varios proyectos que necesitan usar este proyecto de entidad. Compilamos con éxito el proyecto EF en una DLL. También hemos agregado con éxito la referencia EF dll en múltiples proyectos, que está funcionando muy bien.Compartir Entity Framework Library en varios proyectos
El problema ahora es que tenemos varios programas (ASP.NET y aplicaciones de consola) que hacen referencia a este EF dll y el dll se copia localmente para cada programa de llamada, cuando hacemos un cambio al dll de EF, tenemos para entrar en cada proyecto y reemplazar el dll de EF con la nueva compilación.
He estado buscando mucho para compartir bibliotecas e incluso proyectos EF en múltiples proyectos. Aunque he encontrado varios, parece que no puedo encontrar un buen ejemplo de que pueda hacer un trabajo para mi situación o que no sea tan antiguo como para que sea irrelevante.
Ese es el problema general que estoy teniendo. Para dar una mejor idea de los problemas que estoy enfrentando, me enfocaré en un proyecto en particular. Este es un proyecto de formulario web ASP.NET para en intranet. Si agregamos la referencia EF dll y permitimos que el proyecto copie el dll localmente, el EF funciona fantásticamente. Sin embargo, debido a que tenemos proyectos múltiples, ahora debemos tratar de centralizar el DLL de EF en algún lugar donde los procesos múltiples lo puedan compartir. No estoy tratando de configurar esto para que se acceda a un dll de EF en múltiples servidores. Me complace instalar una copia de la DLL en servidores individuales si es necesario.
Mi deseo es crear un directorio de "bibliotecas comunes" en cada servidor, ejemplo simplificado "C: \ OurLibraries". Luego pondríamos o dlls de EF (y tal vez otros más adelante) en esta carpeta y permitiremos que los diversos programas/procesos accedan a la copia común de la DLL de EF. Me he asegurado de que la "copia local" de EF dll haya sido eliminada del proyecto de intranet y haya agregado una referencia al archivo "C: \ OurLibraries \ OurEF.dll". Todo se desarrolla correctamente y el proyecto de intranet funciona bien hasta que intenta mostrar una página que tiene referencias de EF y luego muestra un mensaje de error:
"No se pudo cargar el tipo 'EntityNS.ProductDBEntity'."
Si activo "copia local" en la referencia, el sitio de intranet funciona bien nuevamente. Parece que no puedo encontrar esa configuración mágica que me permita compartir el DLL de EF.
me han tratado las siguientes cosas en base a varios puestos, pero sin éxito:
La firma del montaje y la adición a la GAC. Experimentado el mismo problema que tenerlo en "C: \ OurLibraries"
Añadiendo el directorio "C: \ OurLibraries" a la variable de entorno PATH.
cambiado mi cadena de conexión para el EF en mi archivo web.config intranet de eliminar de la cadena del "O": /Ecomedate.csdl|res:///Ecomedate.ssdl|res:///Ecomedate .msl; proveedor = Sistema ... a ; proveedor = Sistema ...
(basado en este post: Sharing Entity framework objects across projects?)
he pasado muchas horas trabajando en esto y foros que buscan y publicaciones. Sé que tiene que haber una manera de hacerlo, de lo contrario, la reutilización del código y el uso compartido de DLL parece inútil, por lo que cualquier ayuda que pueda sugerir sería apreciada.
Aquí hay esfuerzos adicionales que he realizado y en respuesta a algunas de las publicaciones hasta el momento.
También aquí está lo que he experimentado con el GAC hasta ahora. - en una computadora con VS2010 instalado, el gacutil se encuentra en C: \ Program Files \ Microsoft SDK ... y desde el foro en preguntas "Where is the gacutil" el tono general es que gacutil ahora se considera una herramienta de desarrollo y no destinado para su uso en entornos de prueba. Gacutil no es parte de la Server 2008 o .Net 4 Marco, por lo que hay varias sugerencias sobre cómo implementar y hacer frente a las DLL GAC
- en primer lugar, la vieja manera de instalar, usar el gacutil, sino por usando psexec para copiar y llamar a gacutil en el servidor de producción. Puedo hacer que psexec ejecute el gacutil desde una caja dev local a un servidor prod y obtenga un código de retorno de 0, éxito; sin embargo, no puedo encontrar una manera de ver realmente que está instalado en el servidor de producción, porque no hay gacutil en el servidor de prod, no puedo usar algo como gacutil/l DataEntity.dll para ver información en dll instalado ... incluso si se instaló correctamente.
- Intenté copiar los archivos gacutil.exe y gacutil.exe.config en el servidor de producción para intentar ejecutar desde allí. Mientras el programa se ejecuta y proporciona el número de versión del gacutil, no responde a ningún modificador de línea de comando como gacutil.exe/i DataEntity.dll o gacutil.exe/l DataEntity. Simplemente muestra la información de la versión de gacutil nuevamente y se detiene.
- Alguien sugirió en un foro instalar el SDK de Microsoft en la máquina prod. Aunque podría tener que considerar esto debido a la falta de éxito hasta el momento, realmente no me gusta la idea de instalar un SDK en mis entornos de producción.
- Traté de encontrar herramientas como el Administrador de GAC Remoto para ver y administrar, pero el último desarrollo en ese proyecto de código abierto fue 2008, así que cuando trato de usarlo para ver el GAC, quiero mostrarme c: \ Windows \ assembly gac dlls, pero .NET 4 ahora usa C: \ windows \ Microsoft.NET \ assembly para almacenar dlls de GAC, por lo que parece que puedo encontrar alguna forma de ver o mantener archivos DLL en el gac del servidor de producción remoto. Si ejecuto un comando dir DataEntity.dll/s en c: \ windows en el símbolo del sistema, encuentro el dll incrustado en el directorio C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL, pero si trato de ver el archivo a través del explorador en C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL, no puedo ver el dll, así que no puedo encontrar una herramienta que me permita administrar (instalar, enumerar, desinstalar) los archivos DLL en C: \ Windows \ Microsoft .NET \ assembly \ GAC_MSIL en el servidor de producción 2008 del servidor.
- Hubo una sugerencia de instalar dlls en gac mediante arrastrar y soltar. Estoy tratando de automatizar nuestro proceso de implementación, por lo que tener que arrastrar y soltar manualmente no tiene mucho sentido. ¿Funciona también una copia para el directorio C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL? Lo he intentado, pero de nuevo, ya que no puedo encontrar una herramienta que me permita ver los archivos DLL instalados/registrados, no puedo decir si funcionó o no.
- Otra sugerencia fue crear un instalador que simplemente se instalaría en el GAC. Intenté este método y encontré un par de problemas. Primero fue un proceso muy manual. No pude encontrar la manera de desinstalarlo de GAC y luego instalar la nueva versión de DLL en gac; insistía en que desinstalara la instalación anterior primero. En segundo lugar, cuando traté de desinstalar el dll, seguía diciendo que estaba siendo utilizado por otra aplicación. Intenté reiniciar y luego desinstalarlo, pero no ir. Finalmente descubrí que era IIS y tuve que cerrar IIS, desinstalar, reiniciar, instalar y luego reiniciar IIS. Esto es un dolor en el pero para tratar de automatizar.
Parece que debe haber una mejor manera de desplegar dlls a un entorno de producción en un directorio compartido. Simplemente quiero probar y poner DataEntity.dll en un directorio c: \ MyLibraries y haga que los procesos accedan a esa única copia de la DLL. Microsoft lo hace con C: \ Archivos de programa \ Archivos comunes, por lo que debería ser posible, pero ahora he pasado días tratando de encontrar una manera que funcione que reduzca considerablemente los esfuerzos de mantenimiento impuestos por las opciones del GAC o del instalador, reduzca la número de dlls duplicados, y evitar pasar por alto el reemplazo de dlls si se permite 'copiar localmente'.
Nunca he hecho lo que está intentando hacer, pero intentaría cargar el perfil de usuario del grupo de aplicaciones y asegurarme de que tiene permiso para el directorio "C: \ OurLibraries". ¿O ya lo intentaste? –
¿Por qué no dejar que cada proyecto tenga su propia copia local? si cambia el dll, es probable que desee/necesite reconstruirlos de todos modos, por lo que no está claro qué obtendrá al centralizarlo, aparte del dolor de control de versiones (en mi humilde opinión) cuando necesite actualizar las aplicaciones y no pueda hacerlo por partes. –