c# - solucion - visual studio no compila cambios




La DLL dependiente no se copia a la carpeta de salida de compilación en Visual Studio (10)

Tengo una solución de estudio visual. Tengo muchos proyectos en la solución. Hay un proyecto principal que actúa como inicio y usa otros proyectos. Hay un proyecto que dice "ProyectoX". Su referencia se agrega al proyecto principal. El ProjectX hace referencia a otro DLL .NET (digamos abc.dll) que no es parte de la solución.

Ahora, este archivo abc.dll debe copiarse en la carpeta bin / debug del proyecto principal, pero no se copiará allí. ¿Por qué no se copia, alguna razón conocida?


Agregue el archivo DLL como un elemento existente a uno de los proyectos y se debe ordenar


Aparte de los comunes anteriores, tenía una solución multiproyecto para publicar. Aparentemente, algunos archivos se dirigen a diferentes marcos.

Entonces mi solución: Propiedades> Versión específica (False)


Encontré que si ProjectX hacía referencia al abc.dll pero no usaba directamente ninguno de los tipos DEFINED en abc.dll, entonces abc.dll NO se copiaría a la carpeta de salida principal. (Se copiaría en la carpeta de salida de ProjectX, para hacerlo más confuso).

Por lo tanto, si no está utilizando explícitamente ninguno de los tipos de abc.dll en ninguna parte de ProjectX, coloque una declaración ficticia en algún lugar de uno de los archivos en ProjectX.

AbcDll.AnyClass dummy006; // this will be enough to cause the DLL to be copied

No necesita hacer esto para cada clase, solo una vez será suficiente para hacer que la copia DLL y todo funcione como se espera.

Adición: tenga en cuenta que esto puede funcionar para el modo de depuración, pero NO para la versión. Ver la respuesta de @nvirth para más detalles.


Este es un pequeño cambio en el ejemplo de nvirth

internal class DummyClass
{
    private static void Dummy()
    {
        Noop(typeof(AbcDll.AnyClass));
    }
    private static void Noop(Type _) { }
}

No estoy seguro de si esto ayuda, pero para mí, muchas veces hago referencia a un archivo DLL (que automáticamente lo agrega a la carpeta bin por supuesto). Sin embargo, esa DLL podría necesitar DLL adicionales (dependiendo de qué funciones estoy usando). NO quiero hacer referencia a los de mi Proyecto porque simplemente necesitan terminar en la misma carpeta que el DLL que estoy usando.

Lo logro en Visual Studio "Agregar un archivo existente". Debería poder agregarlo en cualquier lugar excepto en la carpeta Add_data. personalmente, simplemente lo agrego a la raíz.

Luego cambie las propiedades de ese archivo a ...

Build Action = None (teniendo esto configurado como algo como Content, en realidad copia la versión "raíz" a la raíz, más una copia en el contenedor).

Copiar a la carpeta de salida = Copiar si es más nuevo (Básicamente lo coloca en la carpeta BIN solo si falta, pero no lo hace después de eso)

Cuando publico ... mi DLL agregada solo existe en la carpeta BIN y en ningún otro lugar en la ubicación de publicación (que es lo que quiero).


Puede establecer tanto el proyecto principal como la ruta de salida de construcción de ProjectX en la misma carpeta, luego puede obtener todos los dlls que necesita en esa carpeta.


Se encontró con este mismo problema. Información general: antes de construir, había agregado un nuevo Proyecto X a la solución. El Proyecto Y dependía del Proyecto X y el Proyecto A, B, C dependía del Proyecto Y.

Los errores de compilación se debieron a que no se encontraron los dlls del Proyecto A, B, C, Y y X.

La causa principal fue que el Proyecto X creado recientemente se enfocó en .NET 4.5, mientras que el resto de los proyectos de solución se enfocaron en .NET 4.5.1. El proyecto X no se compiló, lo que provocó que el resto de los proyectos tampoco se construyeran.

Asegúrese de que los proyectos recién agregados estén orientados a la misma versión de .NET que el resto de la solución.


Se ve bien cuando lo convierte en un atributo de ensamblaje

[AttributeUsage(AttributeTargets.Assembly)]
public class ForceAssemblyReference: Attribute
{        
    public ForceAssemblyReference(Type forcedType)
    {
        //not sure if these two lines are required since 
        //the type is passed to constructor as parameter, 
        //thus effectively being used
        Action<Type> noop = _ => { };
        noop(forcedType);
    }
}

El uso será:

[assembly: ForceAssemblyReference(typeof(AbcDll.AnyClass))]

Solo una nota al margen de la respuesta de Overlord Zurg.

He agregado la referencia ficticia de esta manera, y funcionó en el modo de depuración:

public class DummyClass
{
    private static void Dummy()
    {
        var dummy = typeof(AbcDll.AnyClass);
    }
}

Pero en el modo Release, el dll dependiente aún no se copió.
Esto funcionó sin embargo:

public class DummyClass
{
    private static void Dummy()
    {
        Action<Type> noop = _ => {};
        var dummy = typeof(AbcDll.AnyClass);
        noop(dummy);
    }
}

Esta información en realidad me costó horas averiguarlo, así que pensé en compartirla.


También puede verificar para asegurarse de que las DLL que está buscando no están incluidas en el GAC. Creo que Visual Studio es inteligente al no copiar esos archivos si ya existe en el GAC en la máquina de compilación.

Recientemente corrí en esta situación en la que había estado probando un paquete SSIS que necesitaba ensamblajes para existir en el GAC. Desde entonces, lo había olvidado y me preguntaba por qué esos archivos DLL no aparecían durante una compilación.

Para comprobar lo que hay en el GAC (desde un símbolo del sistema de Visual Studio Developer):

gacutil -l

O envíe a un archivo para que sea más fácil de leer:

gacutil -l > output.txt
notepad.exe output.txt

Para eliminar un conjunto:

gacutil -u MyProjectAssemblyName

También debo señalar que, una vez que eliminé los archivos del GAC, se publicaron correctamente en el directorio \ bin después de una compilación (incluso para los ensamblados a los que no se hizo referencia directamente en el proyecto raíz). Esto fue en Visual Studio 2013 Update 5.





reference