c# - una - Optimización de la creación de soluciones de Visual Studio: ¿dónde colocar los archivos DLL?

dll visual studio

Question

Descubrí que el tiempo de compilación de la solución C # con muchos proyectos es mucho más rápido si no tienes habilitado "copiar local" en todas partes. Hice algunas pruebas y parece que (al menos para nuestra solución) podríamos aumentar el tiempo de compilación en un factor de 2-3 simplemente eliminando "Copiar local". Esto probablemente significa que tenemos que almacenar bibliotecas en algún directorio común.

¿Alguna sugerencia / mejores prácticas sobre cómo lograr esto? Tenga en cuenta que me gustaría mantener referencias a los proyectos, no a las DLL.

Answer 1

Me gusta la configuración de la carpeta Bin Lib de nivel superior que es común en los sistemas basados ​​en Unix, por cierto, el cambio a este tipo de sistema también facilitará mucho la vida de su ingeniero de lanzamiento. La creación del instalador se simplifica mucho al tener que extraer todo de una carpeta. Dll luego iría en la papelera ...

Answer 2

Reorientamos el directorio de salida de proyectos para que sea ../../Debug (o ../../Release) Nuestras libs también se ubican en estos directorios.

Establecemos las rutas de referencia en cada proyecto para que sean el directorio Debug o Release en consecuencia (esta configuración se conserva en los archivos del usuario, ya que es una referencia absoluta en lugar de relativa)

Mantenemos las referencias del proyecto como referencias del proyecto. Todas las referencias dll han copiado local falso y la versión específica es falsa a menos que sean dlls a nivel del sistema que sabemos que estarán en el GAC en todas las máquinas desplegadas.

Esto funciona como un tratamiento y compilaciones manuales en las compilaciones de IDE mimic scripted desde la línea de comandos (usando MSBuild)

Los proyectos de prueba no para implementación no dirigen su salida al directorio centralizado Debug | Release, solo usan la ubicación predeterminada estándar (y usan copy local para evitar problemas con el bloqueo)

Las versiones de la biblioteca pueden ser modificadas por el proceso de compilación automatizado reemplazando los archivos DLL en los directorios de depuración y liberación.

Answer 3

Recomiendo construir a .. / .. / Build si su aplicación se extiende a través de soluciones. (Si solo tiene una solución, puede considerar .. / Build.) Visual Studio, de forma predeterminada, recuperará los archivos de referencia en su carpeta de salida. Sin embargo, al compilar sin VS utilizando MSBuild, debe agregar la carpeta de compilación como ruta de referencia como se muestra en el siguiente ejemplo:

  <Target Name="BuildApp">
    <MSBuild
        Projects="@(ProjectReference)"
        Targets="Rebuild"
        Properties="ReferencePath=../../Build;$(LibraryFolder)" >
    </MSBuild>
    <OnError ExecuteTargets="BuildFailed" />
  </Target>

El ejemplo también me lleva a mi segundo argumento. No creo que deba usar su carpeta de compilación como carpeta de la biblioteca, ya que esto puede llevar a que los proyectos individuales sobrescriban erróneamente los ensamblados de la biblioteca, por ejemplo, al utilizar Copiar local. Debes tener un control estricto sobre las versiones de tu biblioteca, así que te sugiero que lo mantengas separado. (Los desarrolladores necesitarían agregar esta ruta en VS como ruta de referencia).

También puede optar por separar .. / .. / Build en .. / .. / Release y .. / .. / Debug como lo sugiere ShuggyCoUk .