|
.NET Terms in English
Assembly:
These are Programs / EXE files and Libraries with .DLL extensions that are
created with .NET compilers. Although assemblies have similar file extensions to
Windows Programs and libraries (EXE and DLL) they are not an executable program
or library and require the Common Language Runtime (about 18 megs of
files) to run. However, an assembly needs no specific language runtimes
(i.e. VB.net assemblies do not require VB.net libraries installed, and C#
libraries do not require any special C# libraries installed) instead needing the
CLR. If you can load and examine an EXE or DLL with ILDASM.exe
utility, it is no doubt a .NET assembly. If not it is pre .NET technology,
CLR (Common Language Runtime):
This set of libraries and real-time compilation tools are required on any
machine that will run .NET assemblies. The CLR has essential components - the
Common Type System (CTS) so all languages will understand data types and
structures for example. The CLR has optional components too -- on the
Intel/Windows Platform some 25,000 objects are included with CLR. But not all
these optional components make sense to port to all Platforms: DirectX may make
sense on a MAC, but not a Solaris box. Or as another example, not all the
security and encryption libraries that are supported on Win2k make sense to port
to the Win 9x/ME family due to time constraints and lack of interest.
GAC (Global Assembly Cache):
If a .NET component is called so frequently, it should remain compiled in memory
continuously the GAC is the place it must reside.
Metadata:
collectively, the segments of the assembly that deal with versioning,
deployment and attributes are called Metadata. This metadata contained within
the assembly means .NET assemblies can be copied to a machine and immediately be
capable of conversing with any version of a .NET components via their
metadata and even inherit their methods, properties and code without source code
access. This conversation to various versions can occur side-by-side regardless
of how many versions of a component are on a machine thanks to bundled metadata.
Prior to .NET COM objects so deployment of a COM
component required modifying the registry of machine to register a component and
dependencies and effectively only one version of component could be "current".
This is because COM components had internal vtables, dependencies, and bindings
to other DLLs were handled by separate files and registry entries that are a
necessity.
Managed Code: Most assemblies built with
.NET all emit managed code, which means the following:
- Pointers are not used in the code. Event
mapping is handled by type-safe delegates.
- All memory addressing and parameter passing is
done without pointers and unlike the win32 api, data-type errors are caught at
compile time. If it is in MSIL format, the parameters are known to match the call
signature. Since parameters are checked, buffer overrun security attacks can
not happen at a low-level.
- All memory access is via garbage collected
objects even primitive variables (Ints, strings, longs, etc.) and arrays are
protected from bounds overflows and inappropriate data. Since garbage collection is automatic managed
programs cannot leak memory, even if programmers never dereference objects.
- Pointers and Win32 API calls are not allowed
in managed code without a penalty since they would compromise this. Any code
with those is for a securty standpoint unmanaged.
- Security is much tighter than unmanaged code.
No matter how deep the call stack (i.e. a function A calls sub B that creates
an object C that creates another object D that reads the disk) managed code
grant security privileges for a code action only after it has verified the
trust level of all parties and every code action runs at the lowest level of
trust involved. So even if I am the sysadmin, and I run trusted managed code
written by Ted. If Teds code scrapes a website in one of his I/O calls deep
inside, the level of trust drops from mine and Teds level to untrusted (the
website trust level) this eliminates a whole class of security hacks. If
unmanaged code is ever included in managed code, the entire DLL is trusted
less.
- Managed code has enough metadata (version
info, object tree layout) that it can be xcopied and executed without
registering it with MTS or REGSRVR32. It also has the object tree and code in
MSIL format so that another managed program can inherit and override, extend
methods in an OO fashion WITHOUT source-code.
MSIL : (Microsoft Intermediate Language)
These sets of portable instructions are generated by a .NET compiler, and are a
blueprint to specify all the code that may be JIT compiled. The JIT compiler
does per-method compilation, so that only methods called in programs are
compiled into the machine code. But since managed code is not 16-bit or 32-bit
or 64-bit JIT an existing assembly can be cpoied and when run is JIT compiled to 64-bit code on
a new Pentium chip, or even MAC motorola code (if MS puts out a JIT compiler) without
the programmer ever needing to make a new assembly -- the IL is not
Windows/Intel/32-bit specific.
JIT Compiler
"Just In Time" compiler transfers MSIL to native machine code. The JIT
compiler is optimized for quality code but may not JIT compile the fastest. The
Econo JIT compiler compiles faster but does not generate the most optimized
code. The code is not in a format that can be interpreted or executed. The goal
of MSIL is to act as a blueprint for Jitting code, not to be Jitted code.
Unmanaged Code
Any windows code prior to .NET (any version of VB before VB.net, C++, etc.)
is considered unmanaged code. Any .NET code built with Pinvoke operator and/or
makes a Win32api call or executes code written with pre .NET compilers is
considered unmanaged code. This affects its trust level, and since unmanaged
code does not contain metadata, must be deployed according to complex COM and/or
C++/VB runtime and/or MTS/COM+ deployment rules.
|