Re: IL-to-IL "front-end-compiler" ... ?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Don't remember the name right now but I have seen something similar on the
http://research.microsoft.com site that is AFAIK an object oriented view of
the assembly that you can update to generate updated IL code.

Made a quick search on AOP IL there. This is called the Runtime Assembly
Instrumentation Library (RAIL) :
http://rail.dei.uc.pt/

--
Patrice


"Michael Crawley" <MichaelCrawley@xxxxxxxxxxxxxxxxxxxxxxxxx> a écrit dans le
message de news: 892A4D8A-5670-4CE7-8167-0D731E5F3497@xxxxxxxxxxxxxxxx
There are many source to source compilers for C, C++, and other languages.
CodeDom is .NET's closest attempt for C# and VB.NET. I am trying to
explore
the idea of an IL-to-IL "front-end-compiler" that would take a managed
assembly created by Visual Studio and convert it into a "set of
structures"
proserving the layout of the assembly. Modules would use this "set of
structures" to further manipulate the assembly's original definition in
order
to replace, inject, and rearrange instructions. Finally, the "set of
structures" are written back into a managed IL assembly using
Reflection.Emit.

The advantages I see with this approach would be to avoid the
short-comings
of CodeDom (snipplets, etc.) and to gain independance from
language-dependancy semantics like in C# and VB.NET. Reflection.Emit
cannot
be used by itself because, it is more sequencial nature...IL OpCodes must
be
emitted sequencially where as with the proposed method, IL can be
inserted,
removed, etc. at any time.

There are several obvious disadvantages. Working with IL OpCodes is
typically more error-prone than working with higher-level languages. The
modules that would manipulate the "set of structures" used to modify a set
of
assemblies would be extremely difficult to develop properly. Furthermore,
optimizations made by one IL compiler could be ruined by one of these
modules.

I can see a clear way of reading in the IL into a set of structures. I
can
understand basically how the modifications can take place. However, I am
concerned about writting the final managed IL assembly using
Reflection.Emit.
Past experience with Reflection.Emit has proven Reflection.Emit is a very
unforegiving API. NOP and other instructions are emitted when I thought
they
should not be. I have since realized I did not properly cast the values
of
several the OpCodes. If I remember correctly, some OpCodes yield multiple
IL
instructions in the final assembly. It is almost like there should have
been
more validation and/or strongly-typed instructions to avoid a
misunderstanding of the IL to be in the output assembly. I am concerned
Reflection.Emit might not emit the exact IL that am expecting. On that
note,
should I expect to write my own routines to output a managed IL assembly?

I am still evaluating this approach and have not commited to implement it
yet. I welcome your suggests.


.

Relevant Pages

  • Re: Appl. Security Problems
    ... > Are there instructions on how trust a directorory and the files within it. ... You would simply need to use a URL membership condition rather than a strong ... unusual to use a different signing key for each project within a solution. ... The "typical" schemes are to use a single signing key for all assemblies ...
    (microsoft.public.dotnet.security)
  • Re: find ASPX and ASCX pages in a web project..
    ... One step is missing from your otherwise great instructions: ... you'll need to add a loop to iterate the assemblies: ... >a list of all the ASPX ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: which IL OpCodes call a method
    ... for instructions with the following OpCodes: ... But if you want to know exactly where in the code those assemblies are ... Mattias Sjögren mattias @ mvps.org ...
    (microsoft.public.dotnet.framework.clr)