I don't think your problem is related to lazy loading. System.EnterpriseServices.Wrapper.dll is not an assembly -- it's the secondary module of the multi-module System.EnterpriseServices.dll assembly. An AssemblyDefinition object only exists for the primary module (other modules don't contain the corresponding headers); for secondary modules, the Assembly property will return null.
On 1/26/2013 19:23, Jonas Fischer wrote: > I found the problem - All ModuleDefs where Assembly where null > targeted a Assembly that realy has not been loaded. > In my case it was system.enterpriseservices.wrapper.dll that is seems > to be used but is not referenced in a microsoft/ dot net framework > library thats why I hate lazy assembly loading in dot net. > I currently fixed this problem with workarounds but I think that such > a case should give a exeption but if I do so I think I can not inspect > any/ many assembly(ies) that uses the dot net framework... > > Am Freitag, 25. Januar 2013 22:05:37 UTC+1 schrieb Jonas Fischer: > > Hey, > currently I have some issues while getting the assembly (fullname) > or related information that provides me the possibility to compare > Assemblies including at least their Version, Name, PublicKeyToken > (if any) from a ModuleDefinition, that i got for example from a > TypeDefinition. > My problem Is that in some cases I dont have everything loaded > into my ModuleDef so Assembly is null. > I now looking for a way to do that - What I can say - I have > loaded all references AssemblyDefenitions but seperate, so I may > be able to use these or adjust them to their parents. > > -- > -- > -- > mono-cecil > >
signature.asc
Description: OpenPGP digital signature
