ILMerge strange behaviour

Question

I have an issue using the latest version of ILMerge and I would like if someone can explain me if this is normal. During my search on the web I realized I was not using the latest version of ILMerge so I updated my projects and this is where everything got wrong… First let me explain quickly my project dependencies:

• The dll project A references and uses ILMerge.
• The dll project B references and uses the dll A but it do not reference ILMerge.
• The application project C reference the dll B but it do not reference A nor ILMerge.

My issue is : with the latest version of ILMerge the file is not copied in the output bin folder when the projects B or C are compiled.

With the ILMerge version 2.11.502.0:

• When I build the dll project A the bin folder contains A.dll and ILMerge.exe.
• When I build the dll project B the bin folder contains B.dll, A.dll and ILMerge.exe.
• When I build the dll project C the bin folder contains C.dll, B.dll, A.dll and ILMerge.exe.

However, with the ILMerge version 2.14.1208:

• When I build the dll project A the bin folder contains A.dll and ILMerge.exe.
• When I build the dll project B the bin folder contains B.dll and A.dll.
• When I build the dll project C the bin folder contains C.dll, B.dll and A.dll.

When I made the move to use the latest version of ILMerge I updated the reference in my project A and make sure to set the property Copy Local to true. When I revert back to the older version it works as expected and the file is copied everywhere.

I am using Visual Studio 2012. I have been told by Mike Barnett from Microsoft that this weird behavior exists also with VS2013 but not with VS2015.

Did someone ever encounter a similar issue?

Here is an example: ILMergeIssue.zip

Synovia

Strange question. There is no conceivable point in referencing ILMerge.exe at all, that I can think of anyway. The point of the utility is to have less executable files. Just run it in a post-build event, no reference needed. – Oviparous

Well I am using ILMerge.exe as a dll, if I may say, since I am referencing it and using its API directly from my code instead of doing it in a command prompt. – Synovia

Your NotWorkingILMergeNet4 solution works just fine when I build it on VS2015 Update 2. You need to look at the detailed build trace, focus on the ResolveAssemblyReference and CopyFilesToOutputDirectory tasks. I see it find and copy ilmerge.exe for all three projects. – Oviparous

As I mentioned, Mike Barnett said the same thing: it works with VS2015. However the issue is with VS2012 and VS2013. There is no error with those version. I am not aware of any special verbose mode during compilation to see how/when VS is copying dependency files. – Synovia

Mike's semantic versioning scheme trips a bug in older versions of MSBuild. His assembly version is 2.14.1208.65535, MSBuild doesn't like 65535, looks for a match with 2.14.1208 instead and won't find it . He should have picked 0, like he did for version 2.11.502.0. I can't otherwise tell why he liked 65535 better. – Oviparous

Windows Explorer tells me the version is 2.14.1208.0 but Telerik JustDecompile says the AssemblyVersion is 2.14.1208.65535... So you think that if he changes the last version digit from 65535 to 0 it should work? – Synovia

Windows Explorer can only show the [AssemblyFileVersion]. The [AssemblyVersion] is the problem. Yes. – Oviparous

Thanks I will discuss about this with Mike Barnett. I really appreciate your time Hans! – Synovia

@Synovia What did you find out from Mike Barnett? – Hopson