Nom du produit define for visual C++ et C#

Question

Notre produit contient un tas de modules répartis sur plusieurs solutions de studio visuel et utilise C++ et C#. Je voudrais définir un nom de produit et de l'utiliser dans le cadre des emplacements de dossier par défaut, les clés de registre, etc.

Quelle est la façon la plus simple de définir ce nom de produit en un seul endroit? Et si je dois utiliser une approche différente pour C++ et C#, que conseilleriez-vous pour chacun d'entre eux?

Answer 1

Ceci est la solution que je vais essayer de mettre en œuvre:

C++ et C# auront chacun leur propre fonction pour obtenir le nom du produit, et ces fonctions auront un nom par défaut.

Le nom par défaut peut être remplacée par la variable d'environnement « PRODUCTNAME », de cette façon, nous pouvons facilement construire notre logiciel sous différents noms que par la modification de cette variable d'environnement.

[Modifier] Ma solution C++ compile une DLL qui contient (entre autres) la fonction:
GetProductName (char * pName, int iSize);
donc le nom du produit n'est maintenant défini qu'à un seul endroit.

Answer 2

Selon Microsoft, il semble que vous devriez être en mesure de mettre tout en 1 solution, alors sous-solutions dans ce:

MSDN Structuring Solutions and Projects

EDIT: article est pour Team Foundation Server, donc je suppose que vous ne pouvez pas nécessairement faire cela.

Answer 3

Je ne peux pas dire nécessairement ce qui serait le plus simple, mais je ne sais ce que nous avons fait ici des thats fonctionne raisonnablement bien. Pour les projets C++, nous avons un fichier d'en-tête commun qui contient #defines pour toutes les chaînes communes non-localisables utilisées par les applications (ProductNames, CompanyName, Version, Clés de Registre, Préfixe/Extensions de fichiers, etc.) . Et le projet individuel inclut et référence ces définitions. J'ai utilisé définit spécifiquement plutôt que des constantes parce que de cette façon je pourrais aussi changer toutes les ressources de Version pour référencer ces mêmes définitions sans aucun problème (En fait, tous les fichiers .rc du projet incluent le même version.rc pour garantir l'uniformité).

Pour nos projets C#, j'utilise une classe simple pour contenir les constantes référencées par les projets C#. Malheureusement, cela laisse deux places pour la maintenance, mais à ce stade, cela fonctionne assez bien et nous avons eu si peu besoin de mettre à jour ces définitions/constantes que nous n'avons pas encore eu besoin d'une approche plus intégrée.

Je serais intéressé à entendre d'autres approches ...