x64 visual tutorial studio net ndp471 ndp47 microsoft kb4033342 kb3186497 framework for esn enu deploy create allos .net msbuild dependencies deployment-project

visual - Dependencias detectadas de.Net Deployment Project mágicamente no excluidas



ndp471 kb4033342 x86 x64 allos esn (4)

Ok, esto es más un truco que otra cosa :)

Normalmente, en Visual Studio tienes 2 opciones:

a) Excluir los archivos DLL duplicados
o
b) Establezca la propiedad Condition de sus archivos DLL duplicados en algo diferente.

El problema es que con estos dos enfoques, aún tendrás que reiniciarlos mágicamente y recibir la advertencia como antes ...

Lo que funcionó para nosotros es la siguiente solución:

a) Vaya a su proyecto de instalación y cree una carpeta personalizada

b) Establezca la propiedad DefaultLocation de su carpeta personalizada para que sea la misma que la que necesita para colocar esas DLL. es decir, para las aplicaciones ASP.NET el valor es [TARGETDIR] / bin

c) Luego arrastre y suelte TODOS los dlls duplicados en esta carpeta y no debería recibir advertencias ahora.

Eso es. No debería recibir advertencias para esos dlls, si tiene algún extra simplemente arrástrelos a esta carpeta.

Espero que esto ayude.

-Konstantinos

Tengo una solución Visual Studio 2005 .NET que tiene más de 20 proyectos secundarios, incluido un proyecto de implementación. El proyecto de implementación VS2005 .NET tiene varias dependencias detectadas, que se han excluido manualmente y se han agregado manualmente valores corregidos.

A veces, sin embargo, estas dependencias detectadas quedan mágicamente sin excluir, lo que desencadena una advertencia sobre la compilación: ADVERTENCIA: Dos o más objetos tienen la misma ubicación de destino (''[destino del disco] /')

¿Cuál es el desencadenante que causa que una dependencia detectada sea no excluida? ¿Pueden las soluciones de implementación tener sus advertencias tratadas como errores, por lo que la compilación nocturna no continuará?



He tenido el mismo problema y lo he tratado durante aproximadamente un año antes de darme por vencido y pasar a WiX . Tampoco ayudó el hecho de que tuve que "construir dos veces" mis compilaciones porque MSBuild para VS2005 no funcionará con los proyectos de implementación.

De todos modos, es posible que desee considerar algo como WiX para sus instalaciones.


Sucede cuando el proyecto dependiente tiene "Copiar local" configurado en una DLL dependiente. El proyecto de instalación / instalación tiene el origen y la copia de la DLL listados como una dependencia.