¿Cuál es la diferencia entre un proyecto compartido y una biblioteca de clases en Visual Studio 2015?

240

Estaba mirando las nuevas características para Visual Studio 2015 y Shared Project surgió mucho, pero no entiendo cómo es diferente usar una Biblioteca de clases o una Biblioteca de clases portátil. ¿Alguien puede explicar?

Editar: Proyecto compartido es una nueva característica en Visual Studio 2015 y es diferente a una Biblioteca de clases portátil. Entiendo lo que es una Biblioteca de clases portátil. Lo que estoy tratando de entender es cómo un proyecto compartido difiere de una biblioteca de clases. Ver enlace a continuación.

http://www.c-sharpcorner.com/UploadFile/7ca517/shared-project-an-impressive-features-of-visual-studio-201/

c# .net visual-studio-2015 Indy411
fuente
Ver: diferente entre la biblioteca de clases y la biblioteca de clases portátil en Visual Studio
Behzad

Respuestas:

238

La diferencia entre un proyecto compartido y una biblioteca de clases es que este último se compila y la unidad de reutilización es el ensamblaje.

Mientras que con el primero, la unidad de reutilización es el código fuente, y el código compartido se incorpora en cada ensamblaje que hace referencia al proyecto compartido.

Esto puede ser útil cuando desea crear ensamblajes separados que se dirigen a plataformas específicas pero que aún tienen código que se debe compartir.

Ver también aquí :

La referencia del proyecto compartido aparece debajo del nodo Referencias en el Explorador de soluciones, pero el código y los activos en el proyecto compartido se tratan como si fueran archivos vinculados al proyecto principal.

En versiones anteriores de Visual Studio 1 , podría compartir el código fuente entre proyectos agregando -> Elemento existente y luego eligiendo Vincular. Pero esto era un poco torpe y cada archivo fuente separado tenía que seleccionarse individualmente. Con el movimiento de soportar múltiples plataformas dispares (iOS, Android, etc.), decidieron facilitar el intercambio de fuentes entre proyectos al agregar el concepto de Proyectos Compartidos.

1 Esta pregunta y mi respuesta (hasta ahora) sugieren que Shared Projects era una nueva característica en Visual Studio 2015. De hecho, hicieron su debut en Visual Studio 2013 Update 2

Damien_The_Unbeliever
fuente
1
Digamos dos proyectos que hacen referencia al mismo proyecto compartido. Si uno de esos agrega una referencia al otro, ¿obtiene errores de declaración de tipo duplicados?
Asad Saeeduddin
3
@Asad: no lo he comprobado, pero espero que no. Puede tener dos tipos distintos, con los mismos nombres y declarados dentro de los mismos espacios de nombres pero existentes dentro de diferentes ensamblajes. Eso no es un error, per se.
Damien_The_Unbeliever
Tenía exactamente la misma pregunta que el OP en 2017, pero ahora tenemos .net standard 2.0 . ¿No son obsoletos los proyectos compartidos? ¿Si creas una nueva aplicación webapp o uwp hoy?
JP Hellemons el
1
@JPHellemons: el estándar .net es bueno, pero si necesita salirse de eso por cualquier motivo (por ejemplo, si hay funcionalidad disponible solo en plataformas específicas ), un Proyecto Compartido podría ser un enfoque decente.
Damien_The_Unbeliever
1
Decimos que con un proyecto compartido podemos compartir archivos Javascript. ¿Cómo usamos eso en un bundleConfig?
Leth
34

Encontré más información de este blog .

  • En una biblioteca de clases, cuando se compila el código, se generan conjuntos (dlls) para cada biblioteca. Pero con Shared Project no contendrá ninguna información de encabezado, por lo que cuando tenga una referencia de Shared Project se compilará como parte de la aplicación principal. No habrá dlls separados creados.
  • En la biblioteca de clases solo se le permite escribir código C #, mientras que el proyecto compartido puede tener algo como archivos de código C #, archivos XAML o archivos JavaScript, etc.
Indy411
fuente
77
una biblioteca de clases también puede tener .xaml (controles de usuario)
Predeterminado el
21

Las diferencias cortas son

1) PCL no tendrá acceso completo a .NET Framework, como lo ha hecho SharedProject.

2) #ifdef para el código específico de la plataforma: no puede escribir en PCL (la opción #ifdef no está disponible en una PCL porque está compilada por separado, como su propia DLL, por lo que en el momento de la compilación (cuando se evalúa el #ifdef) no sabe de qué plataforma formará parte ), donde puede hacerlo como proyecto compartido.

3) El código específico de la plataforma se logra usando Inversion Of Control en PCL, donde al usar las declaraciones #ifdef se puede lograr lo mismo en Shared Project.

Puede encontrar un excelente artículo que ilustra las diferencias entre PCL y proyecto compartido en el siguiente enlace

http://hotkrossbits.com/2015/05/03/xamarin-forms-pcl-vs-shared-project/

Venkataramana Madugula
fuente
18

Como otros ya escribieron, en resumen:


reutilización compartida del proyecto en el nivel de código (archivo), lo que permite la estructura de carpetas y los recursos también


reutilización de pcl en el nivel de ensamblaje

Lo que más me faltaba de las respuestas aquí para mí es la información sobre la funcionalidad reducida disponible en una PCL: como ejemplo, tiene operaciones de archivo limitadas (me faltaba mucha funcionalidad de File.IO en un proyecto multiplataforma de Xamarin).

En más detalle,
proyecto compartido :
+ Puede usar #if cuando se dirige a múltiples plataformas (por ejemplo, Xamarin iOS, Android, WinPhone)
+ Toda la funcionalidad del marco disponible para cada proyecto de destino (aunque debe compilarse condicionalmente)
o Se integra en el momento de la compilación
- Tamaño ligeramente mayor de ensamblajes resultantes
: necesita Visual Studio 2013 Update 2 o superior

pcl :
+ genera un ensamblado compartido
+ utilizable con versiones anteriores de Visual Studio (anterior a la actualización 2 de 2013)
o vinculado dinámicamente
- funcionalidad limitada (subconjunto de todos los proyectos a los que se hace referencia)

Si tiene la opción, recomendaría ir a un proyecto compartido, generalmente es más flexible y más potente. Si conoce sus requisitos de antemano y un PCL puede cumplirlos, también podría tomar esa ruta. PCL también impone una separación más clara al no permitirle escribir código específico de la plataforma (lo que podría no ser una buena opción para colocarlo en un ensamblado compartido en primer lugar).

El enfoque principal de ambos es cuando apunta a múltiples plataformas, de lo contrario, normalmente usaría solo un proyecto de biblioteca / dll ordinario.

Andreas Reiff
fuente
9

Del libro VS 2015 sucintamente

Proyectos compartidos permite compartir código, activos y recursos en múltiples tipos de proyectos. Más específicamente, los siguientes tipos de proyectos pueden hacer referencia y consumir proyectos compartidos:

  • Consola, Windows Forms y Windows Presentation Foundation.
  • Aplicaciones de Windows Store 8.1 y aplicaciones de Windows Phone 8.1.
  • Aplicaciones de Windows Phone 8.0 / 8.1 Silverlight.
  • Bibliotecas de clases portátiles.

Nota: - Tanto los proyectos compartidos como las bibliotecas de clases portátiles (PCL) permiten compartir código, recursos XAML y activos, pero, por supuesto, hay algunas diferencias que pueden resumirse de la siguiente manera.

  • Un proyecto compartido no produce un ensamblaje reutilizable, por lo que solo se puede consumir desde la solución.
  • Un proyecto compartido admite el código específico de la plataforma, ya que admite variables de entorno como WINDOWS_PHONE_APP y WINDOWS_APP que puede utilizar para detectar en qué plataforma se está ejecutando su código.
  • Finalmente, los proyectos compartidos no pueden tener dependencias en bibliotecas de terceros.
  • En comparación, una PCL produce una biblioteca .dll reutilizable y puede depender de bibliotecas de terceros, pero no admite variables de entorno de la plataforma.
Tilak
fuente
7

La biblioteca de clases es un código compilado compartido.

El proyecto compartido es el código fuente compartido.

Shadi Namrouti
fuente