Moving System.Runtime.CompilerServices.ExtensionAttribute to mscorlib breaks StructureMap Scans of Namespaces containing ExtensionMethods and possibly other IOC scenarios - by Matt Wrock

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


6
0
Sign in
to vote
ID 726702 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 2/26/2012 7:12:13 PM
Access Restriction Public

Description

It seems that moving System.Runtime.CompilerServices.ExtensionAttribute to mscorlib breaks StructureMap Scans of Namespaces containing ExtensionMethods and possibly other IOC scenarios. 

Unless structuremap is explicitly told to ignore Attributes, it evaluates any attributes on the class being scanned. It tries to examine them using reflection and looks as though the system reflection classes try to load the ExtentionAttribute from the mscorlib assembly where that attribute would be at compile time but not at run time if the code was compiled on a .net 4.5 install and run on a 4.0 install.

I am able to work around this by adding y.IgnoreStructureMapAttributes(); to my scanning rules which tells StrctureMap not to worry about analyzing the Attributes on classes.

Due to the popularity of Structuremap and that this may occur in other Reflection based scenarios with analyzing the attributes of a class containing Extension methods, this may be a fairly serious compatibility issue. It only took me one day of trying vs11 beta/.net 4.5 to run into this.
Sign in to post a comment.
Posted by Microsoft on 3/22/2012 at 10:21 AM
As Matt observed, this issue has to do with how ILMerge.exe is run. Type forwarding (in this case of the ExtensionAttribute type) is considered a non-breaking change, in the sense that it is transparent, in the supported scenarios, to the runtime, as well as our compilers. Compilers or compiler-like tools (which ILMerge is one of) are expected to support type forwarding, just like they are expected to support other features of the runtime. Furthermore, the supported way of running compilers is by explicitly and completely referencing the reference assemblies of the appropriate Multi-Targetting pack.

More information is already available here:
http://www.mattwrock.com/post/2012/02/29/What-you-should-know-about-running-ILMerge-on-Net-45-Beta-assemblies-targeting-Net-40.aspx

Also, a MSDN article providing more details is due to be released. I will reference it here when that happens.

Best Regards,
Mircea Trofin
Microsoft.
Posted by Microsoft on 3/22/2012 at 10:20 AM
As Matt observed, this issue has to do with how ILMerge.exe is run. Type forwarding (in this case of the ExtensionAttribute type) is considered a non-breaking change, in the sense that it is transparent, in the supported scenarios, to the runtime, as well as our compilers. Compilers or compiler-like tools (which ILMerge is one of) are expected to support type forwarding, just like they are expected to support other features of the runtime. Furthermore, the supported way of running compilers is by explicitly and completely referencing the reference assemblies of the appropriate Multi-Targetting pack.

More information is already available here:
http://www.mattwrock.com/post/2012/02/29/What-you-should-know-about-running-ILMerge-on-Net-45-Beta-assemblies-targeting-Net-40.aspx

Also, a MSDN article providing more details is due to be released. I will reference it here when that happens.

Best Regards,
Mircea Trofin
Microsoft.
Posted by Microsoft on 3/13/2012 at 3:46 AM
Thanks again for your feedback. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by AlbertWeinert on 3/3/2012 at 2:00 PM
i don't use ILMerge "in" my problem.

https://connect.microsoft.com/VisualStudio/feedback/details/728055/net-4-5-runtime-breaks-structuremap-registry-of-convention-with-registry-base-class

4.0 is ok, 4.5 breaks it.
Posted by Matt Wrock on 3/2/2012 at 8:20 AM
My issue ended up being directly related to ILMerge.exe merging assemblies and specifying mscorelib as the location of ExtensionAttribute which breaks in 4.0. To fix, I had to pass the C:\Program Files\Reference
Assemblies\Microsoft\Framework\.NETFramework\v4.0 directrory s the TargetPlatform switch to ILMerge. See http://www.mattwrock.com/post/2012/02/29/What-you-should-know-about-running-ILMerge-on-Net-45-Beta-assemblies-targeting-Net-40.aspx for details.
Posted by AlbertWeinert on 2/29/2012 at 12:10 PM
The workaround with IgnoreStructureMapAttributes() didn't worked for me.
Posted by AlbertWeinert on 2/29/2012 at 12:10 PM
.NET 4.5 Beta has more problems with StructureMap, also not related with Extensions Methods.

Conventions registered with the AssemblyScanner over a Registry get not processed, which is sad .. running the processing of the conventions works.
Posted by Matt Wrock on 2/27/2012 at 7:45 AM
After more investigation, its looking like this is related to ilMerging StructureMap with my binaries. I was having problems using the MS Ajax minifier on javascript where content was being minified to 0 bytes when running 4.5 compiled bits on 4.0. I also ilmerge that assembly (ajaxmin.dll). After testing with non merged assemblies everything worked even with the call to IgnoreStructureMapAttributes() commented out. So before proceeding further, I will do more troubeshooting focusing on ilmerge. At any rate, its looking like something that needs to be addressed with ilMerge. Do you have test cases addressing scenarios with ilmerge? Any guidance on using ilMerge on 4.5 to be run on 4.0? I'll research further but if you have info handy on this topic that would be great if you could share it.
Posted by MS-Moderator08 [Feedback Moderator] on 2/27/2012 at 1:26 AM
Thank you for reporting this issue. Could you please attach a sample project to help us reproduce this issue?