ASP.NET7

pre- and/or post-processed. 

How does CAS work?

The CAS security policy revolves around two key concepts - code groups and permissions. Each

.NET assembly is a member of a particular code group, and each code group is granted the

permissions specified in a named permission set.

For example, using the default security policy, a control downloaded from a web site belongs to the

‘Zone - Internet‘ code group, which adheres to the permissions defined by the ‘Internet‘ named

permission set. (Naturally the ‘Internet‘ named permission set represents a very restrictive range

of permissions.) 

Who defines the CAS code groups?

Microsoft defines some default ones, but you can modify these and even create your own. To see the

code groups defined on your system, run ‘caspol -lg‘ from the command-line. On my system it looks

like this:

Level 3 Machine

Code Groups:

1.  All code: Nothing

1.1.  Zone - MyComputer: FullTrust

1.1.1.  Honor SkipVerification requests: SkipVerification

1.2.  Zone - Intranet: LocalIntranet

1.3.  Zone - Internet: Internet

1.4.  Zone - Untrusted: Nothing

1.5.  Zone - Trusted: Internet

1.6.  StrongName - 0024000004800000940000000602000000240000525341310004000003

000000CFCB3291AA715FE99D40D49040336F9056D7886FED46775BC7BB5430BA4444FEF8348EBD06

F962F39776AE4DC3B7B04A7FE6F49F25F740423EBF2C0B89698D8D08AC48D69CED0FC8F83B465E0

8

07AC11EC1DCC7D054E807A43336DDE408A5393A48556123272CEEEE72F1660B71927D38561AABF5

C AC1DF1734633C602F8F2D5:

Note the hierarchy of code groups - the top of the hierarchy is the most general (‘All code‘),

which is then sub-divided into several

groups, each of which in turn can be sub-divided. Also note that (somewhat counter-intuitively)

a sub-group  can be associated with a more permissive permission set than its parent. 

How do I define my own  code group?

Use caspol. For example, suppose you trust code from  www.mydomain.com and you want it have full

access to your system, but you want to keep the default restrictions for all other internet sites.

To achieve this, you would add a new code group as a sub-group  of the

‘Zone - Internet‘ group, like this:

caspol -ag 1.3 -site www.mydomain.com FullTrust

Now if you run caspol -lg you will see that the new group has been added as group 1.3.1: 

1.3.  Zone - Internet: Internet

1.3.1.  Site -  www.mydomain.com: FullTrust 

Note that the numeric label (1.3.1) is just a caspol invention to make the code groups easy to

manipulate from the command-line. The underlying runtime never sees it. 

How do I change the permission set for a code group?

Use caspol. If you are the machine administrator, you can operate at the ‘machine‘ level -

which means not only that the changes you make become the default for the machine, but also

that users cannot change the permissions to be more permissive. If you are a normal (non- admin)

user you can still modify the permissions, but only to make them more restrictive. For example, to

allow intranet code to do what it likes you might do this:

caspol -cg 1.2 FullTrust

Note that because this is more permissive than the default policy (on a standard system), you

should only do this at the machine level - doing it at the user level will have no effect. 

I can‘t be bothered with aLL this CAS stuff. Can I turn it off?

Yes, as long as you are an administrator. Just run: caspol -s off 

Can I Look at the IL for an assembLy?

Yes. MS supply a tool called Ildasm which can be used to view the metadata and IL for an assembly. 

Can source code be reverse-engineered from IL?

Yes, it is often relatively straightforward to regenerate high-level source (e.g. C#) from IL. 

How can I stop my code being reverse-engineered from IL?

There is currently no simple way to stop code being reverse-engineered from IL. In future it is

likely that IL obfuscation tools will become available, either from MS or from third parties. These

tools work by ‘optimising‘ the IL in such a way that reverse-engineering becomes much more

difficult.

Of course if you are writing web services then reverse-engineering is not a problem as clients do

not have access to your IL. 

Is there buiLt-in support for tracing/Logging?

Yes, in the System.Diagnostics namespace. There are two main classes that deal with tracing - Debug

and Trace. They both work in a similar way - the difference is that tracing from the Debug class

only works in builds that have the DEBUG symbol defined, whereas tracing from the Trace class only

works in builds that have the TRACE symbol defined. Typically this means that you should use

System.Diagnostics.Trace.WriteLine for tracing that you want to work in debug and release builds,

and System.Diagnostics.Debug.WriteLine for tracing that you want to work only in debug builds. 

Can I redirect tracing to a fiLe?

Yes. The Debug and Trace classes both have a Listeners property, which is a collection of sinks

that receive the tracing that you send via Debug.WriteLine and Trace.WriteLine respectively. By

default the Listeners collection contains a single sink, which is an

instance of the DefaultTraceListener class. This sends output to the Win32 OutputDebugString()

function and also the System.Diagnostics.Debugger.Log() method. This is useful when debugging, but

if you‘re trying to trace a problem at a customer site, redirecting the output to

a file is more appropriate. Fortunately, the TextWriterTraceListener class is provided for this

purpose. 

What are the contents of assembLy?

In general, a static assembly can consist of four elements: The assembly manifest, which contains

assembly metadata. Type metadata.

Microsoft intermediate language (MSIL) code that implements the types. A set of resources. 

What is GC (Garbage CoLLection) and how it works

One of the good features of the CLR is Garbage Collection, which runs in the background collecting

unused object references, freeing us from having to ensure we always destroy them.

In reality the time difference between you releasing the object instance and it being garbage

collected is likely to be very small, since the GC is always running.

[The process of transitively tracing through all pointers to actively used objects in order to

locate all objects that can be referenced, and then arranging to reuse any heap memory that was not

found  during this trace. The common  language runtime garbage collector also compacts the memory

that is in use to reduce the working space needed for the heap.] 

Heap:

A portion of memory reserved for a program to use for the temporary storage of data structures

whose existence or size cannot be determined until the program is running. 

Differnce between Managed code and unmanaged code ?

Managed Code:

Code that runs under a ”contract of cooperation” with the common  language runtime. Managed code

must supply the metadata necessary for the runtime to provide services such as memory management,

cross-language integration, code access security, and

automatic lifetime control of objects. All code based on Microsoft intermediate language (MSIL)

executes as managed code. 

Un-Managed Code:

Code that is created without regard for the conventions and requirements of the common language

runtime. Unmanaged code executes in the common  language runtime environment with minimal services

(for example, no garbage collection, limited debugging, and so on). 

What is MSIL, IL, CTS and, CLR ? 

MSIL: (Microsoft intermediate language)

When compiling to managed code, the compiler translates your source code into Microsoft

intermediate language (MSIL), which is a CPU-independent set of instructions that can be

efficiently converted to native code. MSIL includes instructions for loading, storing,

initializing, and calling methods on objects, as well as instructions for arithmetic and logical

operations, control flow, direct memory access, exception handling, and other operations. Before

code can be executed, MSIL must be converted to CPU-specific code, usually by a just-in-time (JIT)

compiler. Because the common  language runtime supplies one or more JIT compilers for each computer

architecture it supports, the same set of MSIL can be JIT-compiled and executed on any supported

architecture.

When a compiler produces MSIL, it also produces metadata. Metadata describes the types in

your code, including the definition of

each type, the signatures of each type‘s members, the members that your code references, and other

data that the runtime uses at

execution time. The MSIL and metadata are contained in a portable executable (PE) file that is

based on and extends the published

Microsoft PE and Common Object File Format (COFF) used historically for executable content. This

file format, which accommodates 

MSIL or native code as well as metadata, enables the operating system to recognize common language

runtime images. The

presence of metadata in the file along with the MSIL enables your code to describe itself,

which means that there is no need for type libraries or Interface Definition Language (IDL). The

runtime locates and extracts the metadata from the file as needed during

execution. 

IL: (Intermediate Language)

A language used as the output of a number of compilers and as the input to a just-in-time (JIT)

compiler. The common  language

runtime includes a JIT compiler for converting MSIL to native code. 

CTS: (Common Type System)

The specification that determines how the common  language runtime defines, uses, and manages types 

CLR: (Common Language Runtime)

The engine at the core of managed code execution. The runtime supplies managed code with services

such as cross-language

integration, code access security, object lifetime management, and debugging and profiling support. 

What is Reference type and vaLue type ?

Reference Type:

Reference types are allocated on the managed CLR heap, just like object types.

A data type that is stored as a reference to the value‘s location. The value of a reference type is

the location of the sequence of bits

that represent the type‘s data. Reference types can be self-describing types, pointer types, or

interface types