vscode visual tag studio code autocompletar visual-studio-2008 deployment-project

visual studio 2008 - visual - Falta la dependencia del proyecto en el proyecto de implementación



vscode html wrap (8)

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

Cada servicio hace referencia a 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 a los que hacen referencia y el proyecto de implementación están todos en la misma solución VS2008.

He agregado el resultado 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)

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

(Editar) Comprobé 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?

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.

Todavía no utilicé Visual Studio 2008, sin embargo, en 2005 debe verificar que la referencia que falta en el proyecto tiene la propiedad Copiar local establecida en verdadero.

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

¿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.

Además, incluso si ''piensas'' que lo estás usando, VS puede optimizar tu uso; 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á la cadena directamente en su código de referencia.

Más allá de eso, te sugiero eliminar y reconstruir tu solución de instalación.

¿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.

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 (¿tal vez cree que es un dll COM?)

Agregar manualmente la salida primaria para la DLL faltante parece ser una solución viable.

Tengo un par de cosas más para agregar después de reproducir el mismo defecto sospechado de msi.

1) Cuando agregué la segunda salida del proyecto compartiendo la misma dependencia detectada al instalador, no 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 realmente acerta un segundo problema después de usar 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 ensamblaje es navegando a la carpeta bin y agregando el ensamblado que se copia localmente. Esto asegura que el ensamblaje correcto estará presente en las máquinas x86 o x64.

He tenido un problema similar con el uso de objetos SMO de Microsoft. 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 "Externa" 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 está dando 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á viendo dónde originalmente X.dll los recogió, o incluso la carpeta EXE quizás ...