Compilation errors with ImageResizer 3.2.1

Question

After allowing Nuget to update ImageResizer 3.1.5 to version 3.2.1 my compiles are failing with multiple errors (all same type):

Error 5 Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'

Apparently this is the result of an assembly version mismatch. Deleting all ImageResizer references in the project allows an error-free compile.

Reverting to ImageResizer 3.1.5 also allows a successful compilation.

My project is a simple MVC3 application targeting .NET4 - both ImageResizer 3.1.5 and 3.2.1 are targeting v2.0.50727

Any ideas on how this could be fixed?

Thanks in anticipation!

Penicillate

The author recommends posting queries with this tag to StackOverflow ;) – Penicillate

That's fair :) Let's hope he responds then. – Baudoin

I got a same error after adding version 3.2.1 to one of my projects. In another project the error message was: The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\MyProject\packages\ImageResizer.3.2.1\lib\ImageResizer.dll'. I just uninstalled the package and downloaded an older version manually. I do not understand, why author publishes version 3.2.1 marked as Alpha on NuGet. – Myrmidon

I too have reverted to 3.1.5 for the time being, which works well - after all, ImageResizer is quite an excellent package. Perhaps Nuget makes it all too easy to update to the latest/greatest versions....reminds me of my crack-like addiction to keep flashing new Kernels and ROMs to my phone ;) – Penicillate

I posted the package on NuGet because I considered the bugs it fixed more important than the bugs it was likely to introduce. So far this bug has only affected certain project configurations, and there are many workarounds. – Partly

Answer 1

Update (Jun 20th 2012): The best solution is for the project to roll back extension method support. ImageResizer 3.2.2 will no longer offer extension methods, but some of the functionality will be duplicated in the ResizeSettings and Instructions classes to minimize breakage for those who have already coded against the new alpha APIs.

ImageResizer V4 will most likely require .NET 3.5, and will re-introduce the missing features.

---

Update: please see this question instead if you have any solutions to this catch-22.

I apologize for the issues. I'm still trying to gather data and discover a long-term solution, but this is what I have so far:

Workaround A:

In Solution Explorer, expand the References folder in your project, select ImageResizer, and go to Properties. Change the Aliases field from 'global' to 'ir'.

Workaround B:

Set your project to use .NET 2.0, save, then revert it back to using .NET 3.5 or .NET 4.

Workaround C:

Manually remove your System.Core reference and add the correct one back. (The usual culprit is an upgraded project with a System.Core 3.0 reference in a 3.5 project). On ASP.NET, you can do this in web.config.

Workaround D:

Revert to 3.2.0, but only if you're using C#.

Why this is happening

VisualStudio/MSBuild find multiple definitions of System.Runtime.CompilerServices.ExtensionAttribute in the project during compilation, but instead of picking the public copy defined in System.Core, the compiler decides to use the internal, assembly-local copy defined in ImageResizer.dll. Then it complains because other assemblies can't reach it. Inane.

What should happen

Microsoft has used this technique several times in the past without issues, and it's widely documented. The compiler is supposed to pick the public instance for project-wide use, but instead it's picking the 'internal' copy. And this isn't affecting many developers; and only a few can reproduce it with a new project.

Public vs. Internal

V2.3.0 defined ExtensionAttribute as public instead of internal. This caused a compile-timer error in VB projects, but not in C# projects. I immediately released 2.3.1 with it marked internal, but I'm now seeing problems with C# projects instead. Catch-22 here.

It works for other people... and Microsoft! Why me?

http://www.danielmoth.com/Blog/Using-Extension-Methods-In-Fx-20-Projects.aspx

http://www.codethinked.com/using-extension-methods-in-net-20

http://kohari.org/2008/04/04/extension-methods-in-net-20/

Using extension methods in .NET 2.0?

The 'hack' was even featured in MSDN magazine.

How you can help

I need more data to completely figure this out. If you're experiencing the issue, please e-mail a .zip file of the project to [email protected], and include your VisualStudio/.NET version numbers (Go to Visual Studio, Help, About, and click Copy Info, then paste it into the e-mail).

Hopefully I'll be able to find the exact circumstance(s) that trigger the problem.

Update - just found this article which implies the only solution is creating multiple versions of the assembly. But Microsoft didn't! What am I missing? Also, NuGet doesn't support 2.0 vs 3.5 versioning, so unless I can find a single-assembly solution I might have to drop 2.0 support.

Partly

Many thanks for your prompt response. I have sent an archive of my full project to you via email and will try your suggestions above during this afternoon. – Penicillate

@Sean Just got a conclusive answer on the linked page from the IronPython developer who had a similar issue. Extension methods will have to be rolled back in V3.2.2. I've found a way to minimize code breakage by inserting an intermediate base class, but people who've taken full advantage of all the extension methods may have to change code. – Partly

Hotfix online: downloads.imageresizing.net/… – Partly

Please send feedback to [email protected], I'd like to go live with the new version in a few hours. – Partly