visual-studio - tag - visual studio code tutorial español pdf

Mejores prácticas con Nuget: ¿depurar o liberar?

Question

Actualmente, incluyo las compilaciones de lanzamiento con Nuget para las compilaciones oficiales en nuget.org, pero empaqueté las compilaciones de depuración con Nuget para las fuentes de símbolo que se envían a symbolsource.org.

EDITAR: (Jon Skeet, con algunos prejuicios del desarrollo de Noda Time)

NuGet ahora admite empujar tanto a la galería NuGet como a symbolsource.org (o servidores similares), según lo documentado . Desafortunadamente, hay dos requisitos contradictorios aquí:

• Cuando solo utiliza una biblioteca sin necesidad de depuración, realmente desea una versión de lanzamiento. Para eso son las versiones de lanzamiento, después de todo.
• Al depurar en una biblioteca con fines de diagnóstico, realmente desea una versión de depuración con todas las optimizaciones adecuadas deshabilitadas. Para eso están las versiones de depuración, después de todo.

Eso estaría bien, pero NuGet no permite (por lo que puedo decir) que las versiones de lanzamiento y depuración se publiquen de manera útil, en el mismo paquete.

Entonces, las opciones son:

• Distribuya las compilaciones de depuración a todos (como se muestra en el ejemplo en los documentos) y viva con cualquier tamaño y resultados de rendimiento.
• Distribuya las compilaciones de lanzamiento a todos y viva con una experiencia de depuración ligeramente deteriorada.
• Vaya por una política de distribución realmente complicada, que potencialmente ofrezca paquetes de liberación y depuración por separado.

Los dos primeros realmente se reducen al efecto de las diferencias entre las compilaciones de depuración y lanzamiento ... aunque vale la pena señalar que también hay una gran diferencia entre querer entrar en el código de una biblioteca porque quieres verificar un comportamiento y querer para depurar el código de una biblioteca porque cree que ha encontrado un error. En el segundo caso, probablemente sea mejor obtener el código de la biblioteca como una solución de Visual Studio y depurar de esa manera, por lo que no estoy prestando demasiada atención a esa situación.

Mi tentación es seguir con las compilaciones de lanzamiento, con la expectativa de que relativamente pocas personas necesitarán depurar, y las que lo hagan no se verán muy afectadas por las optimizaciones en la compilación de lanzamiento. (El compilador JIT hace la mayor parte de la optimización de todos modos).

Entonces, ¿hay otras opciones que no habíamos considerado? ¿Hay otras consideraciones que inclinar la balanza? ¿Está empujando los paquetes de NuGet a SymbolSource lo suficientemente nuevo como para que la "mejor práctica" realmente no se haya establecido?

Answer 1

El ejemplo en la Creación y publicación de un paquete de símbolos hace referencia a los archivos en los directorios de depuración como fuentes para los archivos dll y pdb.

Especificación del contenido del paquete de símbolos

Un paquete de símbolos se puede construir mediante convenciones, desde una carpeta estructurada de la manera descrita en la sección anterior, o se puede especificar su contenido usando la sección de archivos. Si desea construir el paquete de ejemplo descrito anteriormente, puede poner esto en su archivo nuspec:

<files>
  <file src="Full/bin/Debug/*.dll" target="lib/net40" /> 
  <file src="Full/bin/Debug/*.pdb" target="lib/net40" /> 
  <file src="Silverlight/bin/Debug/*.dll" target="lib/sl40" /> 
  <file src="Silverlight/bin/Debug/*.pdb" target="lib/sl40" /> 
  <file src="**/*.cs" target="src" />
</files>

Dado que el propósito de publicar los símbolos es permitir que otros pasen por su código durante la depuración, parece más prudente publicar una versión del código destinada a la depuración sin optimizaciones que puedan afectar el paso del código.

Answer 2

Estoy completamente de acuerdo con tu conclusión. Paquetes NuGet con RELEASE y SymbolSource con depuración. Parece bastante raro pasar directamente a los paquetes y el error ocasional de depuración con optimizaciones habilitadas podría ser aceptable.

Si realmente hubiera un problema, creo que la solución ideal sería que NuGet lo respalde. Por ejemplo, imagine que, al depurar, podría reemplazar el DLL de lanzamiento con el incluido en el paquete SymbolSource.

Idealmente, lo que sucedería entonces es que nuget pack SomePackage -Symbols contra una versión de lanzamiento crearía un paquete nuget de lanzamiento, pero un paquete de símbolos de depuración. Y el complemento VS se actualizará para que sea lo suficientemente inteligente como para ver la asociación y extraer los ensamblados de depuración cuando se ejecuta en un depurador y cargarlos en su lugar. Algo loco, pero sería interesante.

Sin embargo, simplemente no veo suficientes personas quejándose de esto que valdría la pena en este momento.

El equipo NuGet acepta solicitudes de extracción. :)

Answer 3

Hablando en nombre de SymbolSource, creo que la mejor práctica es:

1. Empuje los paquetes de contenido binario + a nuget.org solamente (o cualquier otro feed de producción)
2. Empuje los paquetes de contenido binario + de depuración a un feed de desarrollo:
   • en la premisa
   • en myget.org
   • en nuget.org como paquetes previos a la publicación.
3. Empuje los paquetes de símbolos binarios + de liberación y depuración a symbolsource.org o cualquier otra tienda de símbolos.

Mientras estamos en esto, es un error común pensar que las compilaciones de versión y depuración en .NET realmente difieren mucho, pero asumo que la diferenciación está aquí debido a varios códigos que pueden o no estar incluidos en cualquiera de las compilaciones, como Debug . Afirmaciones.

Dicho esto, realmente vale la pena presionar ambas configuraciones a SymbolSource, porque nunca se sabe cuándo va a necesitar depurar el código de producción. De forma remota en producción para hacerlo más difícil. Necesitará la ayuda que puede obtener de sus herramientas cuando eso suceda. Lo cual obviamente no deseo sobre nadie.

Todavía hay un asunto a considerar con respecto al control de versiones: ¿es correcto tener 2 paquetes diferentes (compilar en depuración y en versión) compartiendo 1 número de versión? SymbolSource lo aceptaría, porque extrae paquetes y almacena binarios en ramas de modo de compilación separadas, SI SOLO NuGet permite etiquetar los paquetes en consecuencia. No hay forma en el presente de determinar si un paquete es de depuración o de modo de lanzamiento.