This project has moved and is read-only. For the latest updates, please go here.

Latest Nuget (2.1.1) not working without .NET 45


There seems to be some problems when building on a machine with .NET 45, even if build target is set to .NET 40. Was not able to run application on machine without 45, got this error:

Method not found: 'System.Delegate System.Reflection.MethodInfo.CreateDelegate(System.Type, System.Object)'.

Installing 45 fixed the problem. Found some information regarding similar problem at NInject site:


mertner wrote Sep 24, 2012 at 2:13 AM

Good catch!

Our build script is not particularly sophisticated, but sounds like it needs some work.

I should be able to fix it and push a new release within a week.

mertner wrote Sep 27, 2012 at 1:57 AM

I figured out the root cause of the problem, which is that .NET 4.5 performs an in-place update over an existing .NET 4.0 installation. All 4.5 assemblies have version, but types have apparently been moved between assemblies a lot. An assembly compiled for 4.0 (but with .NET 4.5 installed) will reference 4.0 assemblies, but the wrong ones (i.e. where the type was moved rather than where the type was defined in the original 4.0 assemblies). Argh, only Microsoft could come up with something as broken as this.

As a consequence of this in-place-update version-hell it's almost impossible to figure out whether you are referencing the right assemblies and MSBuild does not provide any help choosing the right ones. In the end I had to manually reference the system assemblies and cross fingers that the output references the right assemblies (i.e. works without 4.5 installed).

I've pushed out 2.1.2 with assemblies compiled for 3.5, 4.0 and 4.5. I'd be grateful if you could confirm that they work as expected.

** Closed by mertner 09/26/2012 5:57PM

radomir wrote Oct 1, 2012 at 11:41 AM

Not working here - i still get System.Delegate System.Reflection.MethodInfo.CreateDelegate(System.Type) error referencing Fasterflect on a computer with only .NET 4.0 installed. 2.1.0. works.

radomir wrote Oct 1, 2012 at 11:42 AM

My comment was on 2.1.2. release, sorry for missing that...

mertner wrote Oct 2, 2012 at 10:40 PM

I'm reopening this issue until a solution has been found.

That said, I'm not sure what I can do to solve this problem. I'm already compiling the binaries without the usual implicit mscorlib reference - all references to system libraries are spelled out explicitly and the compiler is told to use assemblies from an explicit reference assembly path.

If this does not produce a clean 4.0 assembly then I am not sure how to go about creating them (on a system with 4.5 installed). And since I cannot build for 4.5 on a system with only 4.0, the two appear to be mutually exclusive.

Ideas, anyone?

radomir wrote Oct 9, 2012 at 7:48 AM

Just tested building 2.1.2 release from source on a computer with 4.0 and #develop - i get no errors with dll built from source.

mertner wrote Oct 14, 2012 at 4:47 PM

I have opened an issue for this problem at Microsoft Connect and am awaiting their response before doing anything else. See for details.

Until a solution is found, people targeting .NET 4.0 should download the Fasterflect source and compile it manually on a PC without .NET 4.5 installed.

aggieben wrote Dec 4, 2012 at 5:50 AM

I am using 2.1.2 and have this issue in Windows Azure where there is no 4.5.

aggieben wrote Dec 4, 2012 at 5:51 AM

I have this issue in Windows Azure (with no 4.5 support) with 2.1.2.

mertner wrote Dec 4, 2012 at 5:03 PM

Yes, that is to be expected, since the binaries have been compiled on a machine with 4.5. In order to use 2.1.2 with 4.0 you need to compile the binaries yourself (on a machine without 4.5).

Sadly, not much progress on the Connect issue yet.

ronnieoverby wrote Dec 9, 2012 at 8:23 PM

Deployed my app to windows server 2003 (which won't allow .net 4.5 installation)

Cant find CreateDelegate :(

I'm using \packages\fasterflect.2.1.2\lib\net40\Fasterflect.dll

This sucks....

mertner wrote Dec 10, 2012 at 4:12 PM

Seriously people, if I could fix this, I would. I could install a VM and compile release binaries in that, but it just seems like a lot of effort. People needing a 4.0-version must already have such a machine and compiling Fasterflect is as easy as cloning the repository and running the build script.

Go vote for the Microsoft Connect issue instead, as it is a fault somewhere in the C# compiler/linker tool chain.

Also of note, there have been very few changes since 2.1.0, so either just stick with that or compile 2.1.2 on a box without .NET 4.5.

richtebb wrote Feb 15, 2013 at 1:57 PM

Unfortunately this problem still exists in the net40 assembly. If, in Powershell, you run
ildasm .\Fasterflect.dll /text | Select-String "mscorlib.*ExtensionAttribute"
you will see that it's still linked to mscorlib (which is where it was moved in .NET4.5).

Not sure if it helps, but there is some stuff here about compiling against the Reference Assemblies rather than the GAC?

mertner wrote Feb 17, 2013 at 2:20 PM

The build script producing the release assemblies already attempts this.

It uses a prepare target to define the appropriate constants and to get the appropriate paths, and then compiles the code using very explicit instructions on what framework to use. The targets for compiling 3.5, 4.0 and 4.5 are all identical and all rely on the prepare target to set the right properties. I've obviously checked that it does return and use the correct folders, yet the problem remains.

I can only conclude that it is a bug in the compiler toolchain (csc, msbuild or some stuff that either uses) and have created a corresponding Microsoft Connect issue, which so far (sadly) has been completely ignored by Microsoft. If you know anyone that could get the issue escalated, that would be awesome.

I could in theory set up a virtual build machine to do the job, but it seems like a rather manual task - something I'm not too keen on introducing, especially since I'm not the only one who may want to put out a new release. Finally, the source is easy to grab and compile (running the build script in the Build folder is all it takes), so people who really need a 4.0-only version can get there with much less effort than I would have to invest.

That said, I'm sorry for the problem and wish it was of a nature where it would easier for us to work around it.

richtebb wrote Feb 18, 2013 at 11:53 AM

I feel your pain, mertner! While it would be easy enough to compile my own version, we are using NuGet to retrieve dependencies, so referencing our home-built assembly would introduce lots of complications. We would have to masquerade as the real FasterFlect in our own NuGet feed (as it's included by Combres) and would then have to ensure that everyone got their feed configurations in the right order :(

For now, Buu Nguyen has released a new Combres package that targets a downlevel version of Fasterflect (2.1.0) that doesn't have the mscorlib problem. It's the only solution I can think of until MSFT get their act together.

Thanks anyway :)

mertner wrote Feb 19, 2013 at 8:01 PM

Ah, yes - I see how that wouldn't work very well.

Buu is currently looking at the problem - hopefully he'll come up with a solution to embarrass me, by somehow making the compiler do the right thing.

However, should he arrive at the same result as me, perhaps you (or someone else following this thread) could do the compilation for us (on a machine with only 4.0) and we could push those binaries in a release. It'd hardly be a long-term fix, but since there is no immediate work going on in Fasterflect it may be a while before the next release.

richtebb wrote Feb 19, 2013 at 10:12 PM

I'd be very happy to build a 4.0 version for you. I'm out of the office tomorrow, but will let you know as soon as it's ready.

buunguyen wrote Feb 19, 2013 at 11:06 PM

I've just pushed 2.1.3. I haven't tested on a net4.0-only machine, but did verify with ildasm that ExtensionAttribute is loaded from System.Core instead of mscorlib. Can someone verify that this release works on .net4.0-only machines?

richtebb wrote Feb 20, 2013 at 1:56 PM

I tried testing Fasterflect directly but even v2.1.2 works on my .NET40 machine, so I can't prove that v2.1.3 fixes anything.

My failure scenario is when Fasterflect is included via Combres. However, I can't test this scenario without a new version of Combres, because the current version targets Fasterflect = 2.1.0 not >= 2.1.0 - if you can provide an updated version of Combres I will re-run the failure scenario.