Common Language Infrastructure (CLI)
Managed Assembly
Managed assembly contain both metadata and intermediate language
(IL) code
Assembler and Disassembler
Usually, developers prefer to program in a high-level language, such as C# or Visual
Basic.NET. The compilers for all these high-level languages produce IL.
However, like any other machine language, IL can be written in assembly
language and Microsoft does provide an IL assembler, ILAsm.exe. Microsoft also
provides an IL disassemble, ILDasm.exe.
Intermediate Language Disassembler [ILDASM]
When it comes to understanding of internals nothing can beat ILDASM
(Intermediate Language Disassembler). Using this tool we can view the IL
of the assembly.
Execute the tool: Go to Visual Studio Command Prompt and type
ILDASM at the command prompt.
Intermediate Language Disassembler [ILDASM]
Code Obfuscation
ILDasm.exe makes it possible to reverse engineer the .Net modules, which
in other words lacks intellectual property protection for their algorithms.
.Net obfuscator utility will help protect reverse engineering the MSIL.
These utilities “scrambles” the names of all the private symbols in your
managed module metadata but not the IL code.
There are several .Net obfuscation tools available in the market like
Skater .NET Obfuscator, etc,...
Code Obfuscation
The below link provides various third party tools for C# programming…
http://msdn.microsoft.com/en-us/vcsharp/aa336818.aspx
Just In Time (JIT)
IL instructions cannot be executed directly by today’s CPUs (although this may
change someday). In order to execute a method, its IL code must first be
converted to native CPU instructions. To make this conversion, the CLR
provides a JIT (just-in-time) compiler or simply JITter.
Just In Time (JIT)
The figure below shows what happens the first time a method is called.
JIT will compile the MSIL as and when the code block is visited by the EE.
Just In Time (JIT)
The figure below shows what the situation looks like when WriteLine is called the
second time:
Just In Time (JIT)
Process incurs a performance hit only the first time (startup time delay).
The important thing to note is that the process incurs a performance hit only
the first time a method is called. All subsequent calls to the method execute at
the full speed of the native code: Verification and compilation to native code is
not performed again.
The compiled code is discarded when the application terminates.
Note that the JIT compiler stores the native CPU instructions in dynamic
memory: The compiled code is discarded when the application terminates. So if
you run the application in the future or if you run two instances of the
application simultaneously (in two different operating system processes), then
the JIT compiler will have to compile the IL to native instructions again.
Just In Time (JIT)
Pre-JIT.
Pre-JIT compiles complete source code into native code in a single compilation
cycle. This is done at the time of deployment of the application.
Econo-JIT
Econo-JIT compiles only those methods that are called at runtime. However,
these compiled methods are removed when they are not required.
Normal-JIT
Normal-JIT compiles only those methods that are called at runtime. These
methods are compiled the first time they are called, and then they are stored in
cache. When the same methods are called again, the compiled code from cache
is used for execution.
Native Image Generator (Ngen) by MS Optimizes this Startup Delay.
Native Image Generator (Ngen) by Microsoft is an approach to reduce the initial
delay. Ngen pre-compiles (or "pre-jits") bytecode in a Common Intermediate
Language image into machine native code. As a result, no runtime compilation
is needed. .NET framework 2.0 shipped with Visual Studio 2005 runs Ngen on all
of the Microsoft library DLLs right after the installation.
Code Verification
While compiling IL into native CPU instructions, the CLR performs a process called
verification. Verification examines the high-level IL code and ensures that
everything it does is “safe.”
For example, verification checks that no memory is read from without having
previously been written to, that every method is called with the correct number
of parameters, that each parameter is of the correct type, that every method’s
return value is used properly, that every method has a return statement, and so
on.
The metadata for each managed module includes all the method and type
information used by the verification process. If the IL code is determined to be
“unsafe,” then a System.Security.VerifierException exception is thrown,
preventing the method from executing.
Code Verification
Code Verification checks that no memory is read from without having
previously been written to
Memory
Heap
100001
Global
Stack
100002
10
Unsafe Code
Unsafe Code
Methods, Types, and Code blocks can
be defined as unsafe.
Using unsafe code
introduces security and
stability risks.
Unsafe Code
Unsafe Code Usage
In some cases, unsafe code may increase an application's performance
by removing array bounds checks.
Unsafe code is required when you call native functions that require
pointers. Eg: Win32 API
Using unsafe code introduces security and stability risks.
PEVerify.EXE
To ensure that all methods in your managed module contain verifiably safe IL,
you can use the PEVerify.exe utility that ships with the .NET Framework SDK.
When Microsoft developers test their C# and Visual Basic.NET compilers, they
run the resulting module through PEVerify to ensure that the compiler always
produces verifiably safe code. If PEVerify detects unsafe code, then Microsoft
fixes the compiler.
AppDomain
In Windows, each process has its own virtual address space. Separate address
spaces are necessary because Windows can’t trust the application code. It is
entirely possible (and unfortunately, all too common) that an application will read
from or write to an invalid memory address.
Placing each Windows process in a separate address space enhances robustness:
One process cannot adversely affect another process. However, by verifying the
managed code, we know that the code does not improperly access memory and
cannot adversely affect another application’s code. This means that we can run
multiple managed applications in a single Windows virtual address space.
The CLR does, in fact, offer the ability to execute multiple managed applications
in a single OS process. Each managed application is called an AppDomain. By
default, every managed EXE will run in its own separate address space.
Application Domain [AppDomain]
.Net Win ASP.Net Web Unmanaged Win
Application Application Application
