I’ve got a solution consisting of several projects (all class libraries).
Let’s say: A, B, C, D, E.
A, B and C provide core functionality and must be distributed together.
D and E provide some adapters not necessarily needed in every situation.
So, naturally, I want to ILmerge A, B and C into one assembly (named ABC) before distributing.
The problem is that when projects are compiled, D and E have references to A, B and/or C, not ABC. So when later I try to reference ABC, D and E in some other project, I get compilation errors saying something like: “Instance argument: cannot convert from ‘A.IBoo’ to ‘A.IBoo'”. In VS I can also see that assembly signatures (names) are different, of course.
Is there a good way to fix this?
I know I could probably use publisher policy but it isn’t pretty.
Also, I know I can combine projects in original solution and avoid using ILmerge but I’d prefer not to.
I ran into a similar problem. It turned out that I had the types referenced twice. Once in the combined assembly and once in the separate projects. It was frustrating as hell.
You can remove the projects and only reference the combined assembly treating it more like a library or the projects can be combined in a post build operation.
Another possibility is to alias the global namespace (http://msdn.microsoft.com/en-us/library/c3ay4x3d(v=vs.80).aspx) and reference the combined assembly. The downside is you’ll always be a build behind in the adapters.
Without seeing the actual projects, here is what I would do: I’d separate the ABC projects and put them in their own solution. With a post build event, I’d run ILMerge. Make sure this is versioned and strong named. It will save you headache down the road.
Projects D and E would be in a solution together with a reference to the ABC combined assembly.
Again without seeing the code and the dependencies it’s hard to tell. Also it depends on how often changes occur. If I am making changes in ABC to accommodate DE having two solutions would get old really fast.