Dlaczego otrzymuję ExecutionEngineException na .Net 4.0 Assembly.GetCustomAttributes po zainstalowaniu VS2012/.Net 4.5?

Question

Tak prosty jak tytuł. Uaktualniłem rozwiązanie z .Net 2-3.5 na .Net 4, działało dobrze, zainstalowałem VS 2012, a wraz z nim .Net 4.5 i teraz otrzymuję ExecutionEngineException, gdy próbuję odzwierciedlić CustomAttributes z dynamicznie generowane DLL za pomocą następującego kodu:

Assembly assembly = Assembly.LoadWithPartialName("DavesNamespace.Custom"); 
var attributes = assembly.GetCustomAttributes(typeof(ChecksumAttribute), true); 

otrzymuję wyjątek z lub bez określonego typu dla GetCustomAttributes, ale to tylko w tym momencie, że zgłasza wyjątek, zespół został pomyślnie załadowany i mogę faktycznie zobacz kolekcję CustomAttributes, jeśli wstawię punkt przerwania.

Oryginalna wersja .Net 2-3.5 nadal działa od czasu zainstalowania vs2012.

Każda pomoc bardzo doceniona, znalazłem kilka problemów wynikających z vs2012 kończących się ExecutionEngineExceptions szukających w Internecie, ale nic z odpowiedzią. Problem można rozwiązać, usuwając VS2012 i .Net 4.5, ale ponieważ zamierzamy przenieść się do całej firmy VS2013, gdy zostanie wydana, to naprawdę nie jest to rozwiązanie.

EDIT: mam błąd występujących w app próbki, który robi właśnie tego, a wyjątek jest nadal wyrzucane nawet jeśli aplikacja jest zbudowany targetting śladu 4,5

Stos dodany w komentarzach poniżej (to null)

Answer 1

Rozwiązałem problem dla naszej szczególnej sytuacji, chociaż myślę, że root to nieudokumentowana zmiana w sposobie, w jaki .Net 4.5 czyta CustomAttributes na DLL.

Roztwór przenoszenia CustomAttributeBuilder ustawiany z czym ostatnia sprawa przed AssemblyBuilder.Save() [końcu zawartość zespołu została wypełniona] pierwszego thing after AppDomain.CurrentDomain.DefineDynamicAssembly() [Przed każdym zawartości została wypełniona]

Rzeczywisty kod, do którego zgłaszany był wyjątek, nie musiał się zmieniać, chociaż ponownie wykorzystałem zamiennik dla LoadWithPartialName(), który jest tylko Load(),, ale obejście to wciąż działało z LoadWithPartialName().

Możliwe, że dodanie niestandardowego atrybutu po zawartości zestawu powoduje umieszczenie niestandardowego atrybutu w niewłaściwym miejscu? Ale problem jest rejestrowany przez MS, aby się przyjrzeć.