2012-05-03 1 views
1

J'ai une solution composée de plusieurs projets (toutes les bibliothèques de classes). Disons: A, B, C, D, E.ILmerge et les références d'assemblage

A, B et C fournissent la fonctionnalité de base et doivent être distribués ensemble. D et E fournissent des adaptateurs qui ne sont pas nécessairement nécessaires dans toutes les situations. Donc, naturellement, je veux classer A, B et C en un seul ensemble (nommé ABC) avant de distribuer. Le problème est que lorsque les projets sont compilés, D et E ont des références à A, B et/ou C, pas ABC. Donc quand plus tard j'essaye de référencer ABC, D et E dans un autre projet, j'obtiens des erreurs de compilation en disant quelque chose comme: "Argument d'instance: impossible de convertir 'A.IBoo' en 'A.IBoo'". Dans VS, je peux également voir que les signatures d'assemblage (noms) sont différentes, bien sûr.

Y at-il un bon moyen de résoudre ce problème?

Je sais que je pourrais probablement utiliser la politique de l'éditeur, mais ce n'est pas joli.

En outre, je sais que je peux combiner des projets dans la solution originale et éviter d'utiliser ILmerge mais je préférerais ne pas.

Répondre

2

J'ai rencontré un problème similaire. Il s'est avéré que j'avais les types référencés deux fois. Une fois dans l'assemblage combiné et une fois dans les projets séparés. C'était frustrant comme l'enfer.

Vous pouvez supprimer les projets et référencer uniquement l'ensemble combiné en le traitant plus comme une bibliothèque ou les projets peuvent être combinés dans une opération de post-construction.

Une autre possibilité consiste à aliaser l'espace de noms global (http://msdn.microsoft.com/en-us/library/c3ay4x3d(v=vs.80).aspx) et de référencer l'assembly combiné. L'inconvénient est que vous serez toujours derrière les adaptateurs. Sans voir les projets réels, voici ce que je ferais: Je séparerais les projets ABC et les mettrais dans leur propre solution. Avec un événement de post-construction, je courais ILMerge. Assurez-vous que cette version est bien nommée. Cela vous épargnera des maux de tête sur la route.

Les projets D et E seraient dans une solution avec une référence à l'ensemble combiné ABC.

Encore une fois sans voir le code et les dépendances, c'est difficile à dire. Cela dépend aussi de la fréquence des changements. Si je fais des changements dans ABC pour accommoder DE, deux solutions deviendraient très vieilles.

+0

Merci de présenter plusieurs options. J'ai des références internes et externes comme dans votre cas. En fait, le projet dont je parle est celui-ci: https://github.com/Kostassoid/Anodyne, build.cmd peut 'expliquer' ce que je fais jusqu'ici. La division d'une solution est probablement la meilleure idée, mais puisque c'est un projet jeune, je dois travailler sur chaque partie assez souvent. – Kostassoid