Tal vez estoy presionando el sobre aquí, pero estoy desesperado por aprovechar NuGet para facilitar el infierno DLL en el que me he encontrado.

Tenemos 4 productos principales que todos viven en repositorios Mercurial interrelacionados. Todos ellos "comparten" 3 ensamblajes principales y luego todo lo demás es más o menos específico del producto. Ahora es muy difícil de administrar porque un producto se ha actualizado a .NET 4.0 y está usando dependencias externas que requieren .NET 4.0, mientras que otro producto está atascado en .NET 3.5 por razones en las que ni siquiera quiero entrar.

Por lo tanto, hemos perdido nuestra capacidad de combinar diferencias entre productos.

Para solucionarlo, quiero sacar los 3 ensamblajes principales y convertirlos en su propio proyecto con su propio ciclo de lanzamiento, y tener el cuidado de asegurarme de que puedan compilar tanto contra .NET 3.5 y 4.0, y luego convertirlos en Paquetes de NuGet que contienen múltiples versiones de framework.

PERO, también quiero que los desarrolladores puedan explorar la fuente de estos proyectos.

Así que configuré unservidor NuGet privado y unservidor de SymbolSource privado. Luego fusioné cuidadosamente todos los cambios de todos los repositorios juntos, y deseché todo, excepto mis ensamblajes centrales. Luego edité cuidadosamente los archivos .csproj para que, en lugar de la plataforma AnyCPU, cada proyecto tenga objetivos de plataforma de 3.5 y 4.0, que especifiquen constantes condicionales (para controlar características específicas de la plataforma como System.Dynamic) y establezca la versión de la estructura.

Luego configuro las configuraciones de la solución para "3.5 Debug", "3.5 Release", "4.0 Debug" y "4.0 Release". Cada uno apunta a la Configuración apropiada (Depuración o Lanzamiento) y la Plataforma (3.5 o 4.0).

Puedo construir todo bien dentro de Visual Studio para cualquier plataforma. Ahora tengo un problema cuando se trata de NuGet, porque hay dos formas de crear un paquete, y ambas tienen una debilidad, a menos que me esté perdiendo algo:

Paquete por archivo de proyecto

nuget pack MyProject.csproj -Build -Symbols -Version <insert-from-build-server> -Properties "Configuration=Release;Platform=3.5;"

Los problemas con esto son:

Mientras que la versión 3.5 está compilada y empaquetada, la salida dice "Creación de proyectos para el marco de destino '.NETFramework, Versión = v4.0'".Si desempaqueto los paquetes resultantes, los ensamblajes están bajolib\net40 Cuál está mal.No creo que haya ninguna forma de empaquetar 2 destinos de framework de esta manera, tienes que hacerlo de la otra manera con carpetas y convenciones.Estoy dispuesto a aceptar que no se pueden empaquetar los marcos y crear 2 paquetes llamados MyProject (que haría como 4.0) y MyProject.V35 ... sin embargo, no puedo averiguar cómo tener el mismo proyecto y nuspec y terminar con 2 resultados diferentes con diferentes ids.

Paquete por archivo Nuspec

Con este método, tengo que hacer todo el msbuilding y luego hacer un montón de copia de archivos para configurar una estructura de carpetas como

* MyProject.nuspec
* net40
    * MyProject.dll
    * MyProject.pdb
* net35
    * MyProject.dll
    * MyProject.pdb

Entonces puedo corrernuget pack MyProject.nuspec pero luego no hay una fuente para ir con los símbolos, porque sin el archivo .csproj, NuGet no tiene forma de averiguar dónde obtener todos los archivos de origen, y no veo ninguna documentación sobre cómo hacer esto usando las convenciones de directorio ya sea.

Así que mis preguntas son:

¿Hay alguna manera de agregar archivos de origen a un paquete basado en convenciones?¿Hay una manera de empaquetar un paquete basado en proyecto dos veces con diferentes identificadores?¿Hay otra avenida que quizás no haya considerado?

Cualquier pensamiento sería muy apreciado.