Quelle est la différence entre un projet partagé et une bibliothèque de classes dans Visual Studio 2015?
J'examinais souvent les nouvelles fonctionnalités de Visual Studio 2015 et de Shared Project, mais je ne comprenais pas en quoi cela diffère de l'utilisation d'une bibliothèque de classes ou d'une bibliothèque de classes portable. Quelqu'un peut-il expliquer?
Modifier: Le projet partagé est une nouvelle fonctionnalité de Visual Studio 2015 et diffère de la bibliothèque de classes portable. Je comprends ce qu'est une bibliothèque de classes portable. Ce que j'essaie de comprendre, c'est la différence entre un projet partagé et une bibliothèque de classes. Voir le lien ci-dessous.
La différence entre un projet partagé et une bibliothèque de classes réside dans le fait que cette dernière est compilée et que l'unité de réutilisation est l'Assembly.
Tandis que dans le premier cas, l'unité de réutilisation est le code source et le code partagé est incorporé dans chaque assembly faisant référence au projet partagé.
Cela peut être utile lorsque vous souhaitez créer des assemblys distincts qui ciblent des plates-formes spécifiques , tout en ayant 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 Studio1, vous pouvez partager le code source entre les projets en ajoutant -> Élément existant, puis en choisissant Lien. Mais c’était un peu maladroit et chaque fichier source séparé devait être sélectionné individuellement. En prenant en charge plusieurs plates-formes différentes (iOS, Android, etc.), ils ont décidé de faciliter le partage des sources entre projets en ajoutant le concept de projets partagés.
1 Cette question et ma réponse (jusqu'à présent) suggèrent que les projets partagés étaient une nouvelle fonctionnalité de Visual Studio 2015. En fait, ils ont fait leurs débuts en Visual Studio 2013 Update 2
J'ai trouvé quelques informations supplémentaires 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 Projet partagé, il ne contiendra aucune information d'en-tête. Ainsi, lorsque vous avez une référence de projet partagé, il sera compilé 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 êtes uniquement autorisé à écrire du code C #, tandis qu'un projet partagé peut contenir des fichiers tels que des fichiers de code C #, des fichiers XAML, 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 dans PCL (l'option # ifdef n'est pas disponible dans une PCL car elle est compilée séparément, sous la forme de sa propre DLL, donc à la compilation temps (lorsque le #ifdef est évalué), il ne sait pas à quelle plateforme 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, tandis qu'en utilisant les instructions #ifdef, vous pouvez obtenir le même résultat dans Projet partagé.
Vous trouverez un excellent article illustrant les différences entre PCL et projet partagé à l'adresse suivante:
http://hotkrossbits.com/2015/05/03/xamarin-forms-pcl-vs-shared-project/
Comme d'autres déjà écrit, en bref:
projet partagé
réutiliser au niveau du code (fichier), en tenant compte de la structure des dossiers et des ressources
pcl
réutilisation au niveau de l’Assemblée
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, vous avez des opérations de fichier limitées (il me manquait beaucoup de fonctionnalités de File.IO dans un projet multiplate-forme Xamarin).
Plus en détail
projet partagé:
+ Peut utiliser #if pour cibler plusieurs plates-formes (par exemple, Xamarin iOS, Android, WinPhone)
+ Toutes les fonctionnalités du framework disponibles pour chaque projet cible (bien que devant être compilées sous condition)
o S'intègre au moment de la compilation
- Taille légèrement plus grande des assemblages obtenus
- Nécessite Visual Studio 2013 Update 2 ou une version ultérieure
pcl:
+ génère une Assemblée partagée
+ utilisable avec les anciennes versions de Visual Studio (mise à jour 2 antérieure à 2013)
o lié dynamiquement
- Fonctionnalités limitées (sous-ensemble de tous les projets par lesquels il est référencé)
Si vous avez le choix, je vous recommanderais d’opter pour un projet partagé, c’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 suivre cette voie. PCL impose également une séparation plus claire en vous empêchant 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'objectif principal des deux est de cibler plusieurs plates-formes, sinon vous utiliseriez normalement uniquement un projet bibliothèque/dll ordinaire.
Extrait du livre VS 2015 succinctement
Projets partagés permet le partage de code, d'actifs et de ressources entre plusieurs types de projets. Plus spécifiquement, 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) autorisent le partage de code, de ressources XAML et d'actifs, mais il existe bien sûr certaines différences qui peuvent être résumées comme suit.
- Un projet partagé ne produit pas un assemblage réutilisable, il ne peut donc être utilisé que depuis 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 la plate-forme sur laquelle votre code est exécuté.
- Enfin, les projets partagés ne peuvent pas avoir de dépendances sur des bibliothèques tierces.
- En 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.
bibliothèque de classe est un code compilé partagé.
Projet partagé est un code source partagé.