ILMerge does not generate body of methods with delegates/lambda compiled by roslyn.

[hubuk]

ccrewriter compiled under VS2015 fails on startup with the following error:
Unhandled Exception: System.TypeLoadException: Could not load type 'Microsoft.Contracts.Foxtrot.Driver.Program' from assembly 'ccrewrite, Version=1.8.10107.11, Culture=neutral, PublicKeyToken=188286aac86319f9' because the method 'InternalMain' has no implementation (no RVA).

It turns out that this is the case for all the method with delegate/lambda in body and only for assemblies produced by roslyn. Much worse scnario is for void returning methods as the loader do not raise an exception for them.

There are few ways we can go:

1. Get an updated version of ILMerge from Mr. @mike-barnett.
2. Locate and replace all the delegate/lambda code in libraries used with ILMerge.
3. Drop ILMerge usage.

[danielcweber]

From my experiments it's impossible anyway to compile ccrewriter with VS2015 since these projects themselves use a lot of Code Contracts Requires/Asserts/you name it and can not be rewritten properly at the moment.

Can you confirm that an updated version of ILMerge will solve the issue ?

[damageboy]

Wouldn't it make sense, for the time being, to only attempt to compile CC with VS2013 for VS2015 in order to bootstrap the CC VS2015 compilation?

[damageboy]

Also, another approache could be to start using the opensource ILRepack instead of ILMerge.
The former is also known to run successfully on Mono/Linux/MacOS

[hubuk]

@danielcweber: +1 ahh, great point. ILMerge update will only resolve missing implementation problem, but each Roslyn related issue will remain.

@damageboy: The problem mentioned by danielcweber is that we cannot use version of CC compiled by VS2013 to bootstrap compilation of CC in VS2015 because CC (even compiled by VS2013) is not able to correctly rewrite Roslyn assemblies. We need to add Roslyn support for CC first and then we will be able to prepare the whole project to be compilable in VS2015. But I really like the idea to use compiled version of CC in build process to bootstrap the compilation.

I will take a look at roslyn related issues ASAP.

[mike-barnett]

I've looked into this with @hubuk and it turns out that it is just a matter of updating ILMerge.exe to the latest version. He's looking into making it a NuGet reference so it will always stay up to date.

[hubuk]

There are some problems in the nuget update functionality so updating ILMerge.exe via NuGet is currently somehow problematic:
NuGet/Home#783

For now I will just update imported ILMerge.exe file to the latest one.

[sharwell]

@hubuk As a workaround, I would prefer the following combination:

1. Create a dummy project file in the folder containing packages.config.
2. Do not add the project file to a solution.
3. Create an issue in this repository to remove that project file after a NuGet release is published which does not have this bug.

[hubuk]

That is a nice workaround. I like it. But I would wait for NuGet team to assess the submitted issue. Eventually it may not be considered as a bug.

[sharwell]

If that is the case, then you could simply close the issue from my step 3 as wontfix. Either way it will continue to work and then we don't have to keep updating binaries in the repository. 😄

[hubuk]

I will cancel my PR.
I am really starting to consider updating ILMerge to a latest version during build as a wrong way to go. Shouldn't it be a conscious decision to start using a new version?
We can just stay with using nuget to download a specific version of ILMerge. This scenario is fully supported by the current version (2.X) of nuget.

And just one question: is there anything else besides keeping repository light that discourages committing binary files?

[sharwell]

@hubuk It's really just about keeping it light. The things you put in Git will become part of every clone operation... forever.

Manual updates to new versions is a good way to go. Otherwise when you change ILMerge in the future, it could affect the output of building an old version of Code Contracts.

[hubuk]

After this one I have no doubts. Thanks. I will prepare a new PR.

[hubuk]

Reopened pull request #60.