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 Shared Project est arrivé en grand nombre, mais je ne comprends pas comment il est différent d’utiliser une bibliothèque de classes ou une bibliothèque de classes portable. Quelqu’un peut-il expliquer?

Modifier: projet partagé est une nouvelle fonctionnalité de Visual Studio 2015 et est différente 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 ce dernier est compilé et que l’unité de réutilisation est l’assemblage.

Alors que dans le premier cas, l’unité de réutilisation est le code source et le code partagé est incorporé dans chaque assembly 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 dont le code doit toujours être partagé.

Voir aussi ici :

La référence du 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’ils étaient des fichiers liés au projet principal.


Dans les versions précédentes de Visual Studio 1 , vous pouviez partager le code source entre les projets en ajoutant Ajouter -> Élément existant et en choisissant ensuite Lier. Mais c’était un peu maladroit et chaque fichier source séparé devait être sélectionné individuellement. En prenant en charge plusieurs plates-formes disparates (iOS, Android, etc.), ils ont décidé de faciliter le partage des sources entre les projets en ajoutant le concept de projets partagés.


1 Cette question et ma réponse (jusqu’à présent) suggèrent que Shared Projects était une nouvelle fonctionnalité de 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é, les assemblys (dlls) sont générés pour chaque bibliothèque. Mais avec Shared Project, il ne contiendra aucune information d’en-tête. Ainsi, lorsque vous aurez une référence de projet partagé, elle sera compilée dans le cadre de l’application parente. Il n’y aura pas de dll séparés créés.
  • Dans la bibliothèque de classes, vous ne pouvez écrire que du code C # alors que le projet partagé peut avoir quelque chose comme des fichiers de code C #, des fichiers XAML ou des fichiers JavaScript, etc.

In-Short Differences sont

1) PCL ne va pas avoir access complet à .NET Framework, où SharedProject a.

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

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

Un excellent article illustrant les différences entre PCL et Projet partagé peut être trouvé sur le lien suivant

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

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

projet partagé
réutiliser au niveau du code (fichier), en tenant compte de la structure des dossiers et des ressources

pcl
réutiliser au niveau de l’assemblage

Ce qui me manquait surtout dans les réponses, ce sont les informations sur les fonctionnalités réduites disponibles dans un PCL: par exemple, vous avez des opérations de fichiers limitées (il manquait beaucoup de fonctionnalités File.IO dans un projet multi-plateforme Xamarin).

Plus en détail
projet partagé :
+ Peut utiliser #if en ciblant plusieurs plates-formes (ex. Xamarin iOS, Android, WinPhone)
+ Toutes les fonctionnalités du framework disponibles pour chaque projet cible (même si elles doivent être compilées de manière conditionnelle)
o Intègre au moment de la compilation
– Taille légèrement plus grande des assemblages 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 (pré-2013 Update 2)
o lié dynamicment
– Fonctionnalités limitées (sous-ensemble de tous les projets référencés)

Si vous avez le choix, je recommanderais d’aller pour un projet partagé, il est généralement plus flexible et plus puissant. Si vous connaissez vos besoins à l’avance et qu’une PCL peut les satisfaire, vous pouvez également opter pour 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 peut ne pas être un bon choix pour être placé dans un assemblage partagé en premier lieu).

L’objective principal des deux est de cibler plusieurs plates-formes, sinon vous utiliseriez normalement un projet bibliothèque / dll ordinaire.

Du livre VS 2015 succinctement

Les projets partagés permettent de partager du code, des ressources et des ressources entre plusieurs types de projets. Plus précisément, les types de projets suivants peuvent référencer et consumr 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 le partage du code, des ressources XAML et des ressources, mais il existe bien sûr des 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 utilisé qu’à partir de la solution.
  • Un projet partagé prend en charge le code spécifique à la plate-forme, car il prend en charge des variables d’environnement telles que WINDOWS_PHONE_APP et WINDOWS_APP que vous pouvez utiliser pour détecter la plate-forme sur laquelle s’exécute votre code.
  • Enfin, les projets partagés ne peuvent pas avoir de dépendances sur les bibliothèques tierces.
  • En comparaison, une PCL produit une bibliothèque .dll réutilisable et peut avoir des dépendances sur des bibliothèques tierces, mais elle ne prend pas en charge les variables d’environnement de la plate-forme.