Fixing conflicting types in C# .NET caused by ILMerge

I have an interesting 开发者_如何学Cproblem which I would like an easy fix for. I have a "library" assembly that is referenced in both a "client" project and a "test" project in a solution in Visual Studio. The problem is that the test project also references the client project, and we must use ILMerge to merge the library assembly with the client assembly for deployment. Since the library assembly is merged with the client assembly, I get an error about types in my library assembly existing in both the originally referenced library assembly and in the merged assembly when the test project attempts to build.

The real problem is that we have ILMerge running in a post-build step on the client project; the best solution would be to move that to the actual deployment process. However, our current tooling would make that difficult to implement.

Is there a way to tell .NET that the type might be in more than one assembly and that's OK (considering they're actually the same assembly, but just merged with another assembly in one case)?

So, if i understand it correctly, your test project has a reference to the library and to the client, which in turn has the library merged in...So, at build time for test you get two references of the same library. I think the solution is to remove the library reference from the test project and only reference the client, which will have everything you need.

If I understood correctly, if you were to reference the merged assembly only in your tests, you will get access to all types, making a reference to the library assembly unnecessary, and thus eliminating the problem with ILMerge.

You might want to add a reference to the binary "client" output (which would be the merged file), and add a manual build dependency to control the correct compilation order.

I did this in a project of mine by editing the CSPROJ file manually, overriding the "CopyFilesToOutputDirectory" target to not only compile, but also merge the "client" during the build, but a post build event should also do the trick (I did some other unrelated changes at the same time which forced me to change the target behavior).

I then edited the other project file referencing the merged DLL to use the reference like this:

<Reference Include="MyMergedLib, Version=1.2.3.4, Culture=neutral, PublicKeyToken=3d58c5c8efc41aa9, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\MyMergedLib\$(OutputPath)MyMergedLib.dll</HintPath>
</Reference>

This makes sure that VS always takes the correct version (debug/release). Maybe this helps.

Well, you could use a customized version of ILLink (instead of ILMerge) to fix this issue.

Or, you could just tweak it to remove the duplicate assembly.

See Source Code here. Note that ILLink is a C++ program..