Quelle est la différence entre un projet partagé et une bibliothèque de classes dans Visual Studio 2015?

Je regardais les nouvelles fonctionnalités de Visual Studio 2015 et le projet partagé est venu beaucoup mais je ne comprends pas en quoi c'est différent d'utiliser une bibliothèque de classes ou une bibliothèque de classes portable. Quelqu'un peut-il expliquer?

Modifier: le projet partagé est une nouvelle fonctionnalité de Visual Studio 2015 et est différent d'une bibliothèque de classes portable. Je comprends ce qu'est une bibliothèque de classes portable. Ce que j'essaie de comprendre, c'est comment un projet partagé diffère d'une bibliothèque de classes. Voir le lien ci-dessous.

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

La différence entre un projet partagé et une bibliothèque de classes est que cette dernière est compilée et l'unité de réutilisation est l'assembly.

Alors qu'avec le premier, l'unité de réutilisation est le code source, et le code partagé est incorporé dans chaque assemblage qui référence le projet partagé.

Cela peut être utile lorsque vous souhaitez créer des assemblys distincts qui ciblent des plates-formes spécifiques mais qui ont toujours du code à partager.

Voir aussi ici :

La référence de projet partagé apparaît sous le nœud Références dans l'Explorateur de solutions, mais le code et les actifs du projet partagé sont traités comme s'il s'agissait de fichiers liés au projet principal.

Dans les versions précédentes de Visual Studio ¹ , vous pouviez partager le code source entre les projets en ajoutant -> Élément existant, puis en choisissant de lier. Mais c'était un peu maladroit et chaque fichier source séparé devait être sélectionné individuellement. Avec le passage à la prise en charge de plusieurs plates-formes disparates (iOS, Android, etc.), ils ont décidé de faciliter le partage de source entre les projets en ajoutant le concept de projets partagés.

¹ Cette question et ma réponse (jusqu'à présent) suggèrent que les projets partagés étaient une nouvelle fonctionnalité dans Visual Studio 2015. En fait, ils ont fait leurs débuts dans Visual Studio 2013 Update 2

J'ai trouvé plus d'informations sur ce blog .

• Dans une bibliothèque de classes, lorsque le code est compilé, des assemblys (dll) sont générés pour chaque bibliothèque. Mais avec Shared Project, il ne contiendra aucune information d'en-tête, donc lorsque vous avez une référence Shared Project, elle sera compilée dans le cadre de l'application parent. Il n'y aura pas de DLL distinctes créées.
• Dans la bibliothèque de classes, vous êtes uniquement autorisé à écrire du code C # tandis que le projet partagé peut avoir n'importe quoi comme des fichiers de code C #, des fichiers XAML ou des fichiers JavaScript, etc.

Les différences en bref sont

1) PCL ne disposera pas d'un accès complet à .NET Framework, contrairement à SharedProject.

2) #ifdef pour le code spécifique à la plate-forme - vous ne pouvez pas écrire en PCL (l' option #ifdef n'est pas disponible dans un PCL car elle est compilée séparément, comme sa propre DLL, donc au moment de la compilation (lorsque le #ifdef est évalué) il ne sait pas de quelle plateforme il fera partie. ) où en tant que projet partagé, vous pouvez.

3) Le code spécifique à la plate-forme est obtenu en utilisant Inversion Of Control dans PCL, où en utilisant les instructions #ifdef, vous pouvez obtenir la même chose dans Shared Project.

Un excellent article qui illustre les différences entre PCL et projet partagé se trouve sur le lien suivant

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

Comme d'autres l'ont déjà écrit, en bref:

réutilisation partagée du projet au niveau du code (fichier), permettant également la structure des dossiers et les ressources

pcl
réutilisation au niveau assemblage

Ce qui me manquait le plus dans les réponses ici, ce sont les informations sur les fonctionnalités réduites disponibles dans un PCL: à titre d'exemple, les opérations sur les fichiers sont limitées (il me manquait beaucoup de fonctionnalité File.IO dans un projet multiplateforme Xamarin).

Plus en détail,
projet partagé :
+ Peut utiliser #if lors du ciblage de plusieurs plates-formes (par exemple Xamarin iOS, Android, WinPhone)
+ Toutes les fonctionnalités du framework disponibles pour chaque projet cible (mais doivent être compilées conditionnellement)
o S'intègre au moment de la compilation
- Taille légèrement plus grande des assemblys résultants
- Nécessite Visual Studio 2013 Update 2 ou supérieur

pcl :
+ génère un assemblage partagé
+ utilisable avec les anciennes versions de Visual Studio (mise à jour pré-2013 2)
o lié dynamiquement
- fonctionnalité limitée (sous-ensemble de tous les projets par lesquels il est référencé)

Si vous avez le choix, je vous conseille d'aller en projet partagé, il est généralement plus flexible et plus puissant. Si vous connaissez vos besoins à l'avance et qu'un PCL peut les satisfaire, vous pouvez également emprunter cette voie. PCL impose également une séparation plus claire en ne vous permettant pas d'écrire du code spécifique à la plate-forme (ce qui pourrait ne pas être un bon choix pour être placé dans un assembly partagé en premier lieu).

L'objectif principal des deux est lorsque vous ciblez plusieurs plates-formes, sinon vous utiliseriez normalement juste un projet de bibliothèque / dll ordinaire.

Extrait du livre VS 2015 succintly

Les projets partagés permettent de partager du code, des actifs et des ressources sur plusieurs types de projets. Plus précisément, les types de projets suivants peuvent référencer et consommer des projets partagés:

• Console, Windows Forms et Windows Presentation Foundation.
• Applications Windows Store 8.1 et applications Windows Phone 8.1.
• Applications Windows Phone 8.0 / 8.1 Silverlight.
• Bibliothèques de classes portables.

Remarque: - Les projets partagés et les bibliothèques de classes portables (PCL) permettent de partager du code, des ressources XAML et des actifs, mais bien sûr, il existe certaines différences qui peuvent être résumées comme suit.

• Un projet partagé ne produit pas d'assemblage réutilisable, il ne peut donc être consommé qu'à partir de la solution.
• Un projet partagé prend en charge le code spécifique à la plate-forme, car il prend en charge les variables d'environnement telles que WINDOWS_PHONE_APP et WINDOWS_APP que vous pouvez utiliser pour détecter sur quelle plate-forme votre code s'exécute.
• Enfin, les projets partagés ne peuvent pas avoir de dépendances sur des bibliothèques tierces.
• Par comparaison, un PCL produit une bibliothèque .dll réutilisable et peut avoir des dépendances sur des bibliothèques tierces, mais il ne prend pas en charge les variables d'environnement de plate-forme

La bibliothèque de classes est du code compilé partagé.

Le projet partagé est un code source partagé.