Right, I got it now. Thanks a lot!

On Mar 5, 10:35 pm, Jb Evain <[email protected]> wrote:
> Hi,
>
> You need to use your custom silverlight resolver to resolve the silverlight 
> mscorlib and System modules.
> From those modules you can get 
> TypeDefinition/FieldDefinition/MethodDefinition.
>
> Then you import references for those in your module.
>
> On Mar 5, 2012, at 9:27 PM, einarwh wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > Thanks again! The references for the primitives are very useful, they
> > cover most of what I need.
>
> > I still don't fully understand the correct way to read modules and
> > type definitions, though (my apologies). Do I need to use
> > ModuleDefinition.ReadModule to do this? The types I need (such as
> > PropertyChangedEventHandler) all reside in system.dll and
> > mscorlib.dll.
>
> > In the example below, is theDefinition a TypeDefinition? Is this
> > something I get from the module I read, or something I create myself
> > and pass to myModule.Import?
>
> > I'm sorry for these basic and naive questions, hopefully my
> > understanding will improve soon!
>
> > Kind regards,
> > Einar
>
> > On Mar 5, 11:01 am, Jb Evain <[email protected]> wrote:
> >> Two things,
>
> >> For primitives, Cecil can automatically create references for you, based 
> >> on the mscorlib you're referencing. So you can use:
>
> >> myModule.TypeSystem.Void as a TypeReference.
>
> >> If you need to import a reference to another type, you have to use Cecil 
> >> to read the module the type is defined is, and call:
>
> >> var reference = myModule.Import (theDefinition);
>
> >> To create a reference scoped for myModule that you can use.
>
> >> On Mar 5, 2012, at 9:41 AM, einarwh wrote:
>
> >>> Even better, how would I use the Cecil type system to create a
> >>> TypeReference for System.Void, for instance?
>
> >>> Kind regards,
> >>> Einar
>
> >>> On Mar 5, 8:54 am, einarwh <[email protected]> wrote:
> >>>> Hi,
>
> >>>> You nailed it! Thanks! I was indeed using
> >>>> TypeReference.Module.Import(typeof(...));
>
> >>>> What would be the correct way to import a TypeReference?
>
> >>>> Currently, I'm doing this to obtain a TypeReference that is used in
> >>>> the definition of the TypeDefinition _typeDef:
>
> >>>> var ns = "<namespace>";
> >>>> var typeName = "<name>";
> >>>> var typeRef = new TypeReference(ns, typeName, _typeDef.Module,
> >>>> _typeDef.Scope);
>
> >>>> Does that make sense?
>
> >>>> Thanks again,
> >>>> Einar
>
> >>>> On Mar 5, 2:36 am, Jb Evain <[email protected]> wrote:
>
> >>>>> Hi,
>
> >>>>> It's hard to tell without you showing some actual IL rewriting code.
> >>>>> First thing that pops into my mind is that if you use the .net type 
> >>>>> system when rewriting the IL, you'll get references to the .net runtime 
> >>>>> type system.
>
> >>>>> Like, if you import a reference to typeof(int), or a System.Type, or a 
> >>>>> MethodInfo, then it will use the running one.
> >>>>> To avoid that you can simply use the Cecil type system.
>
> >>>>> Jb
>
> >>>>> On Mar 4, 2012, at 11:19 PM, einarwh wrote:
>
> >>>>>> Hi,
>
> >>>>>> I'm a Mono.Cecil n00b trying to do some IL rewriting on Silverlight
> >>>>>> assemblies, but I seem to be doing something wrong. The "tampered"
> >>>>>> assemblies (after rewriting) look OK in ILSpy, except for the
> >>>>>> references to .NET framework libraries, which include the
> >>>>>> standard .NET v 4.0 (not Silverlight) of system.dll and mscorlib.dll.
> >>>>>> I guess I must be doing something wrong when I'm importing types? I
> >>>>>> tried to follow the recipe here:
> >>>>>>http://stackoverflow.com/questions/9109506/mono-cecil-fails-to-proces...
> >>>>>> so I use the following code to read the assembly:
>
> >>>>>> var resolver = new DefaultAssemblyResolver();
> >>>>>> resolver.AddSearchDirectory(@"C:\Program Files (x86)\Reference
> >>>>>> Assemblies\Microsoft\Framework\Silverlight\v4.0");
> >>>>>> var assembly = AssemblyDefinition.ReadAssembly(
> >>>>>>     assemblyPath,
> >>>>>>     new ReaderParameters { AssemblyResolver = resolver });
>
> >>>>>> I still seem to have the same problem, though. How do I best debug
> >>>>>> this? How can I spot that I've inserted a faulty reference to the
> >>>>>> regular .NET v4 dlls? I'm trying to inspect the
> >>>>>> TypeReference.Module.Runtime and TypeDefinition.Module.Runtime of the
> >>>>>> various types I use, does that make sense?
>
> >>>>>> Any help would be greatly appreciated.
>
> >>>>>> Kind regards,
> >>>>>> Einar
>
> >>>>>> --
> >>>>>> --
> >>>>>> mono-cecil
>
> >>> --
> >>> --
> >>> mono-cecil
>
> > --
> > --
> > mono-cecil

-- 
--
mono-cecil

Reply via email to