Ref.Emit baked Type returns Assembly object different from AssemblyBuilder that created it - by Jeroen Frijters

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.

Sign in
to vote
ID 302592 Comments
Status Resolved Workarounds
Type Bug Repros 1
Opened 10/4/2007 9:44:59 AM
Access Restriction Public


Pre-Orcas when you called Type.Assembly on a Ref.Emit created Type you'd get back the AssemblyBuilder that created the type, but on Orcas Beta 2 you now get back a different object.
While I appreciate that this is an improvement, I don't think this type of breaking change is compatible with the whole red/green bits philosophy.
Sign in to post a comment.
Posted by Jeroen Frijters on 10/29/2007 at 10:35 PM
I've changed my code to work around this issue, so it is no longer a blocker for me.

My runtime needs to implement access control, so it is critical that I'm able to check whether two types are in the same assembly or not.

I now use Assembly.Equals() instead of doing an identity comparison. Hopefully that will continue to work.

BTW, there is a second scenario that will break because of this change. If you want the AssemblyBuilder that an already finished type was built with, previously you could simply use Type.Assembly and cast that down to AssemblyBuilder, now you'll have to maintain the mapping yourself.

Like I said in the original report, by itself this change makes perfect sense (and I'm big fan of Partial Trust), but overall, I don't think that breaking changes like this (in a Service Pack) are in the best interest of the .NET Framework.
Posted by Microsoft on 10/29/2007 at 4:05 PM
Hi Jeroen,

Thanks for your feedback on Reflection.Emit! Yes, this is unfortunately one of the changes we needed to introduce as part of our feature work for Reflection.Emit in Partial Trust (which is newly delivered in Orcas Redbits). Though a comparison for equality will fail, we'll hope that the relevant members of the Assembly object will behave as you expect (as if it were the actual source AssemblyBuilder). We apologize for any convenience this may have caused. If this is a serious blocker for you, please let us know more about your scenario and we can follow up.

Again, our apologies for this inconvenience and thanks for all your feedback.

Reflection Feature Team
.NET Common Language Runtime
Posted by Microsoft on 10/4/2007 at 5:24 PM
Thanks for your feedback. We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you,
Visual Studio Product Team