Organisation d'une solution Visual Studio pour deux produits similaires

Question

Nous avons une solution VS2010 qui contient une application de formulaire Windows et 4 projets de bibliothèque de classes (DLL). (Les bibliothèques de classes sont des choses comme BusinessTier, DataTier, CommonCode, ControlLibrary) Le tout est ciblé pour le framework 2.0. Cela a été comme ça pendant trois ans.

Ok

donc notre application a augmenté au point où nous voulons ajouter une grande nouvelle fonctionnalité et le marketing veut déployer comme un produit distinct. Notre produit est utilisé pour remplir des formulaires fiscaux et le deuxième produit remplira d'autres formulaires fiscaux.

Nous voulons nous retrouver avec deux exe (deux MSI d'installation) qui seront vendus/installés/mis à jour indépendamment et qui pourront être exécutés simultanément sur le même ordinateur. La plupart du code est en commun entre les deux applications.

J'essaie de trouver la meilleure façon de structurer la solution pour créer le résultat souhaité. 1) L'option 1 pourrait être de créer un nouveau projet EXE et plusieurs nouveaux projets DLL dans la même solution originale (Say dans un dossier de solution) qui ont des noms uniques, des versions, des guids, etc. avec la plupart des fichiers de code comme des liens vers les fichiers de code dans les DLLs similaires d'origine. Cela nous permet d'avoir deux systèmes complètement séparés avec des noms uniques pour tous les fichiers, les numéros de version, etc., mais permettent une personnalisation à chaque projet/dll. Est-ce une bonne idée ou trop?

2) L'option deux serait de créer un nouveau projet exe dans la solution et de lier les mêmes DLL que le premier projet exe. Cela semble assez simple, mais je ne sais pas si c'est une bonne idée d'avoir deux projets qui utilisent les mêmes DLL. Je ne veux pas vraiment utiliser le GAC. Si nous avons deux exe qui utilisent les mêmes Dll (même si elles seront dans des dossiers d'applications séparés) avec un problème si les DLL ont le même numéro de version/nom, GUID ou un autre GUID?

Quelles sont vos idées?

Comment est-ce que je devrais restructurer la solution pour adapter au nouveau produit?

Answer 1

Go pour l'option 2

Il n'y a pas de problème avec les mêmes Dlls avec les mêmes noms. Si vous déployez les exes dans des dossiers séparés ou si vous les conservez dans des dossiers distincts, cela fonctionnera dans les deux cas.

Je voudrais même aller plus loin et voir comment vous pouvez décomposer davantage l'application en plusieurs assemblys/dll, car cela vous donnera encore plus de flexibilité. Je voudrais également avoir un seul fichier pour AssemblyInfo, et l'ajouter en tant que fichier lié à tous vos projets. Cela signifie que vous avez une seule version à travers tous vos dlls/exes. http://vsh.infozerk.net/options/add-an-existing-file-to-a-project-without-copying-it/