Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

?id=7c517035-3e1a-4798-8219-41d316173fb4

¿Qué es la carpeta "ref" que hay en los resultados de compilar un proyecto con .NET 5?

Imagen ornamental

En .NET 5, cuando compilas un proyecto, se generan los archivos finales dentro de la carpeta bin\Release\net5.0 de tu proyecto. Dentro de esta encontrarás las DLL de la aplicación, los ejecutables (si los hay), algunos archivos JSON de configuración y los archivos de depuración (.pdb). Pero además, verás que hay una carpeta llamada ref que tiene dentro algunas DLL aparentemente iguales a las de tu aplicación. ¿Para qué sirve esa carpeta y sus DLL? ¿La tienes que distribuir con tu aplicación?

IMPORTANTE: en .NET 6, tras bastantes discusiones en GitHub, se decidió que estos ensamblados de referencia se iban a generar de nuevo bajo la carpeta "obj" y no en "bin" para evitar confusiones y dado que no tienen un uso muy habitual. No obstante, todo lo demás explicado en este post sigue siendo válido.

Dentro de esta carpeta ref hay  lo que se llaman Reference Assemblies o ensamblados de referencia. Estos ensamblados tan solo contienen la interfaz pública de un ensamblado y los metadatos mínimos sobre la parte pública de los mismos. Esto contrasta con los ensamblados "normales", los que van con tu aplicación, que se denominan ensamblados de implementación.

Los ensamblados de referencia representan un contrato de tu aplicación con el compilador y están atados a una versión concreta. De este modo, si los distribuyes como si fueran una especie de Kit de Desarrollo (SDK) de tu aplicación, otros desarrolladores pueden añadirlos como referencias a sus proyectos y pueden usarlos para compilar contra esa versión específica sin necesidad de tener el código completo. Se suele usar, por ejemplo, si tu aplicación permite plugins o extensiones, para crearlos sin que necesites tener de verdad las DLL finales y pudiendo asegurar que cumplen con lo que espera una versión concreta de tu aplicación. De este modo, no tienes que distribuir el ensamblado, que como sabes, si no está ofuscado es muy fácil de ver su código.

Microsoft los utiliza para sus SDKS. Por ejemplo, .NET Standard proporciona el ensamblado del contrato, netstandard.dll, que representa el conjunto de APIs comunes compartidas entre distintas plataformas .NET. Las implementaciones de estas API están contenidas en ensamblados diferentes en distintas plataformas, como mscorlib. dll en .NET Framework o System.Private.CoreLib.dll en .NET Core. Una biblioteca que tiene como destino .NET Standard puede ejecutarse en todas las plataformas que admiten .NET Standard, y puedes verificar que va a funcionar porque tienes ese contrato en el ensamblado de referencia.

Los ensamblados de referencia deben tener el mismo aspecto que los reales desde el exterior. Por lo tanto, tienen el mismo nombre de archivo, nombre de ensamblado, identidad de ensamblado y todo lo demás, y por eso te parece que están repetidos dentro de la carpeta ref. Pero no es así. Están ahí para permitir que el sistema de compilación los utilice como sustitutos de los reales. Y dado que estos ensamblados no contienen ninguno de los detalles de implementación (el código real), solo cambian cuando cambia la interfaz de los contenidos.

En tu propio proyecto, MsBuild utiliza estos ensamblados de referencia para acelerar el proceso de compilación, generando y comparando el ensamblado de referencia cada vez que el código compilado cambia.

Si no hay otros proyectos en tu solución que hagan referencia al proyecto concreto que genera esos ensamblados de referencia, realmente no te servirán de mucho, salvo que tengas pensado pasárselos a otros desarrolladores para que los usen como referencia. Así que los puedes borrar. Incluso, si no quieres ni que se generen, puedes desactivar su generación añadiendo esta línea al archivo del proyecto (.csproj):

<ProduceReferenceAssembly>false</ProduceReferenceAssembly>

De este modo ya no se generará la carpeta ref en las próximas compilaciones.

Te dejo un enlace a la documentación oficial de .NET para esta característica, con muchos más detalles sobre cómo crearlos y utilizarlos: Ensamblados de Referencia en Microsoft Docs.

¡Espero que te resulte útil!

Fecha de publicación:
José Manuel Alarcón Fundador de campusMVP, es ingeniero industrial y especialista en consultoría de empresa. Ha escrito diversos libros, habiendo publicado hasta la fecha cientos de artículos sobre informática e ingeniería en publicaciones especializadas. Microsoft lo ha reconocido como MVP (Most Valuable Professional) en desarrollo web desde el año 2004 hasta la actualidad. Puedes seguirlo en Twitter en @jm_alarcon o leer sus blog técnico o personal. Ver todos los posts de José Manuel Alarcón
Archivado en: Lenguajes y plataformas

Boletín campusMVP.es

Solo cosas útiles. Una vez al mes.

🚀 Únete a miles de desarrolladores

DATE DE ALTA

x No me interesa | x Ya soy suscriptor

La mejor formación online para desarrolladores como tú

Comentarios (4) -

Ivan Montilla
Ivan Montilla

Hola José Manuel. Tengo una pequeña pregunta, yo estoy trabajando en un proyecto en el que precisamente sí que tengo que distribuir un SDK del mismo y desconocía esto. Hasta ahora lo que estoy haciendo, es utilizar un proyecto SDK que contiene sólo interfaces (y algunas clases de entidades) y luego tengo un proyecto que contiene el método Main de mi aplicación e implementa las interfaces del proyecto SDK. De esta forma, distribuyo vía NuGet el paquete con sólo las interfaces y la implementación queda fuera en otro proyecto.

Ahora que he conocido esto, estoy pensando en distribuir únicamente los ficheros ref para el SDK. ¿Se puede hacer paquetes NuGet de los ficheros ref sin ningún problema? ¿funcionaría todo igual?

Un saludo ;)

Responder

José Manuel Alarcón
José Manuel Alarcón

Hola Iván:

No deberías tener ningún problema. Están pensadas para esto.

Saludos.

Responder

Kevin Trejo
Kevin Trejo

Hola José, disculpa tengo un proyecto escolar en donde tengo que describir el porque se crean todas las carpetas al crear un proyecto en visual studio y visual code, y me di cuenta de que existen dos carpetas dentro del bin que son las carpetas de ref y la de refint, la de ref es la que mencionas en tu sitio, sin embargo no encontre informacion de la carpeta de refint ni aquí ni en otros sitios, me preguntaba si me podrias solucionar esta duda... gracias de antemano.

Responder

José Manuel Alarcón
José Manuel Alarcón

Hola Kevin:

Es una buena pregunta. Yo pienso que la carpeta "refint" contiene los ensamblados de referencia, exactamente igual que la carpeta "ref" solo que se generan en un momento diferente del proceso de compilación, aunque son iguales. La carpeta "refint" es una carpeta, en teoría temporal, que se genera durante el proceso de compilación para contener los resultados intermedios del proceso, y de hecho se puede controlar su ubicación con un parámetro de MSBuild (learn.microsoft.com/.../common-msbuild-project-properties). Posteriormente, de cara a la distribución de los ensamblados de referencia, se crea una carpeta "ref" que contiene esos mismos ensamblados.

El caso es que en .NET 5 se decidió que iban a meter la carpeta "ref" como resultado de la compilación final, y por eso aparecía en "bin" como indico en el post. Pero en .NET 6 decidieron tras bastantes discusiones (https://github.com/dotnet/msbuild/issues/6543) que com eso casi nunca se usa, iban a volver a moverlo para "obj" por defecto (aunque, coo digo) es puede controlar con ese parámetro), y de hecho con .NET 6 sacaron un post indicando este "breaking change" (que no lo es tanto porque se usa muy poco) para explicar el cambio: learn.microsoft.com/.../write-reference-assemblies-to-obj

Espero que esto te lo aclare.

Responder

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.