Falta la dependencia del proyecto en el proyecto de implementación

Question

Tengo un proyecto de implementación VS2008 que crea un instalador para un par de servicios de Windows.

Cada referencias de servicios varios proyectos diferentes:

 
CustomerName.MailSendingService 
-> CustomerName.Network 
-> CustomerName.Data 
-> CustomerName.Security 

CustomerName.ProductIntegrationService 
-> CustomerName.Core 
-> CustomerName.Security 

Los proyectos de servicio de Windows, los proyectos que hacen referencia, y el proyecto de implementación están todos en la misma solución de VS2008.

He agregado la salida principal de los proyectos de servicio de Windows en el editor del sistema de archivos del proyecto de implementación.

Mi expectativa es que la salida primaria para los proyectos de servicio de Windows incluiría las DLL de los proyectos referenciados. Sin embargo, cuando se genera el proyecto de implementación, falta el archivo DLL de uno de los proyectos a los que se hace referencia. (CustomerName.ProductIntegrationService no se encuentra CustomerName.Security)

Enloquecentemente, las DLL para los otros proyectos a las que hace referencia el servicio de Windows están presentes; solo falta la producción de un proyecto.

(Editar) He verificado que la referencia está configurada en Copiar local en la ventana de propiedades de referencia. La DLL para el proyecto al que se hace referencia se coloca en la carpeta bin \ Release del proyecto de servicio de Windows, pero no se empaqueta en el archivo MSI creado para el proyecto de implementación.

(Editar 2) Siguiendo la sugerencia de Joseph Daigle, verifiqué que la dependencia está en la lista de dependencias para el resultado primario y no está marcada como "excluida", por lo que no parece ser la causa de este problema.

¿Por qué faltaría la producción de un solo proyecto?

Answer 1

Tengo un par de cosas más que añadir después de reproducir el mismo defecto msi sospecha.

1) Cuando agregué la segunda salida del proyecto compartiendo la misma dependencia detectada con el instalador, no se agregó automáticamente la dependencia. Eliminé ambas salidas del proyecto y las agregué en orden inverso. El segundo resultado del proyecto agregado nunca agregó la dependencia detectada. Esto excluye cualquier problema de configuración o código con los proyectos y cómo se agregaron las referencias. Siempre es el segundo que falla.

2) Mi equipo en realidad ha encontrado un segundo problema después de utilizar la solución 'Agregar ensamblaje detectado manualmente'. Inicialmente, agregamos la dependencia desde la ubicación en '\ Program Files \ xxx', pero nos topamos con problemas de compilación en máquinas de 64 bits donde esa misma dependencia estaba en la carpeta '\ Program Files (x86) \ xxx' aunque VS es lo suficientemente inteligente como para manejar este problema al recoger referencias.

• La forma correcta de agregar manualmente el conjunto es navegando a la carpeta bin y agregando el conjunto que se copia localmente. Esto asegura que el ensamblaje correcto estará presente en las máquinas x86 o x64.

Answer 2

no he utilizado todavía Visual Studio 2008, sin embargo en el año 2005 tiene que verificar que la referencia que falta en el proyecto tiene la propiedad Copy Local se establece en true.

Esto copiará el archivo perdido en el directorio de salida.

Answer 3

Además de la respuesta de hectorsq, verifique que la dependencia esté en la lista de dependencias del proyecto de implementación, y que la DLL en cuestión esté marcada para ser incluida.

Answer 4

¿Has probado mirar tu dll en el reflector para ver si realmente depende de la otra dll? VS es lo suficientemente inteligente como para no incluir un ensamblado al que se hace referencia si puede ver que en realidad no lo está usando.

Añadido a esto, incluso si 'pensar' que se está usando, VS puede optimizar su uso de distancia - este es un caso límite, pero lo he visto:

Por ejemplo, si tiene un ' conjunto de constantes con esto en:

public const string LockPanelUrn = "ApplicationRack.LockPanel"; 

VS pegarán la cadena directamente en su código de referencia.

Más allá de eso, le sugiero que elimine y reconstruya su solución de instalación.

Answer 5

¿Agregó esta dependencia de ensamblaje después de crear inicialmente el proyecto de implementación? De ser así, es posible que deba hacer clic con el botón derecho en la carpeta Dependencias detectadas y seleccionar Actualizar dependencias. Recogerá cualquier cosa nueva que se haya agregado desde la última vez que hizo esto.

Answer 6

Puedo verificar que este es un problema para nosotros también. Sospecho que es un error en el proyecto de implementación: solo agrega salida de proyecto dependiente en una ubicación (¿quizás cree que es un dll COM?)

La adición manual de la salida primaria para la DLL faltante parece ser una solución viable.

Answer 7

mira esto - tal vez esto no explica por qué es eso, pero al menos se proporciona alguna solución :)

http://lo-sharpdevs.blogspot.com/2009/07/vs-2008-disappearing-dependencies.html

Answer 8

He tenido un problema similar con el uso de objetos de Microsoft SMO. Tengo un componente binario (X.dll) que utiliza estos objetos SMO de Microsoft que he creado yo mismo. Después de compilar X.dll, lo hago referencia en otro proyecto EXE utilizando X.dll (y no el código). El proyecto del instalador adjunto detecta que necesita los objetos SMO de Microsoft y detecta que son locales para la instalación de mi servidor SQL en la máquina.

El componente X.dll que utiliza los objetos SMO hace referencia a los objetos SMO de Microsoft a través de una carpeta local "Externals" que guardo en una unidad compartida. Todos los módulos se compilan con referencia a ellos, sin embargo, mi proyecto de instalación con mi proyecto EXE detecta los de mi instalación de SQL Server.

Debido a esto, tenemos otra máquina que tiene la carpeta "Externos" con Objetos SMO, pero el proyecto de instalación ya no encontrará los objetos SMO de 'Dependencias Detectadas' ya que no se da cuenta de que los Objetos SMO están en el módulo externo! No estoy seguro de dónde busca los archivos de Dependencia detectada, pero no está mirando dónde originalmente X.dll los recogió, o incluso la carpeta EXE quizás ...