.NET Code Access Security is based on assemblies and evidence. Evidence can be anything deduced from the assembly, but typically it is created from the source of the assembly — whether the assembly was downloaded from the Internet, an intranet, or installed on the local machine (if the assembly is downloaded from another machine it will be stored in a sandboxed location within the GAC and hence is not treated as being installed locally). Permissions are applied to entire assemblies, and an assembly can specify the minimum permissions it requires through custom attributes. When the assembly is loaded the CLR will use the evidence for the assembly to create a permission set of one or more code access permissions. The CLR will then check to make sure that this permission set contains the required permissions specified by the assembly.

.NET code can perform a code access security demand. This means that the code will perform some privileged action only if all of the assemblies of all of the methods in the call stack have the specified permission. If one assembly does not have the permission a security exception is thrown.

The .NET code can also perform Linked Demand for getting the permission from the call stack. In this case the CLR will look for only one method in the call stack in the TOP position has the specified permission. Here the stack walk-through is bound to one method in the call stack by which the CLR assumes that all the other methods in the CALL STACK have the specified permission.

The Assembly is a new concept that the .NET framework introduces to make programming more easier. The .NET framework introduces assemblies as the main building blocks of your application. An application can contains one or more assemblies. An assembly can be formed in one or more files. This all depends on your programming needs.

An assembly can consist of the following four elements:

• Your code, compiled into MS intermediate language (MISL). This code file can be either an EXE file or a DLL file.
• The assembly manifest, which is a collection of metadata that describes assembly name, culture settings, list of all files in the assembly, security identity, version requirements, and references to resources. The assembly manifest can be stored with the intermediate code, or in a standalone file that contains only assembly manifest information.
• Type metadata
• Resources

The main and only required element of the above four elements is the assembly manifest. The remaining elements are optional depending on your requirements.

As we have mentioned above, an assembly can be formed into a single physical file. In this case all the above four elements will be stored inside this file (either an EXE, or a DLL file). Or it can be formed in more than one file, and in this later case we call it a multi-file assembly. In multi-file assembly the above four elements can be stored in separate files like module files for code, resources files for images, or other files required by the application. Note that the files that forms the multi-file assembly are not physically linked, instead they are linked through the assembly manifest.

Assemblies are mainly introduced to solve the problems of versioning, DLL conflicts, and simplifying the process of deployment.

Most end users have encountered versioning or deployment problems when they do install a new application or a new version of an existing one. There are many situations where you install a new application only to find an existing one stopped working, and the system can not recover from that. Many developers spent a lot of time trying to retain the registry entries consistence in order to activate a COM class. All this frustration occurs because of versioning problems that occur with component-based applications.

Versioning Problems

There are two versioning problems that arise with WIN32 applications. The first one is that versioning rules are enforced by the operating system not between the pieces of an application. Backward compatibility between the new piece of code and the old one is the current approach of versioning and this is hard to maintain in most applications. Beside that only a single version of an application is allowed to be present and executing on a computer at any given time. The second problem is that there is no way to preserve consistency between groups of components that are built together and the current present group at run time.
An assembly can have two types of versions. The first one which we call "Version Number" consists of a four-part string with the following format:

<Major Version>.<Minor Version>.<Build Number>.<Revision Number>

DLL Conflicts

As a result of the above two versioning problems, DLL conflicts do occur. Which is: when installing a new application an existing one may break because of that the new one installed a new version of a component or a DLL that is not fully backward compatible with the previous one.

Assembly Locations

An assembly can be placed into one of the following three locations:

• Under the application directory or subdirectories. This is the most common location for placing an assembly. If your assembly uses a culture other than the default one which is "en-US", you have to put it under a subdirectory with this culture name.
• In the global assembly cache, which is a machine code cache installed whenever the common language runtime is installed. You deploy your assembly to the global assembly cache when you want to share it with multiple applications.
• On an ftp server.

The location of an assembly determines whether the common language runtime can locate it when it is referenced, and whether this assembly can be shared with other applications or not.

The @Assembly directive is used to make your ASP.NET page aware of external components. This directive supports two attributes:

@Assembly Directive

The @ Assembly directive can be used in .aspx pages, .ascx files, .master pages and .asax files.

<%@ Assembly Name="assemblyname" %>
<%@ Assembly Src="pathname" %>

Name: A string that represents the name of the assembly to link. Here you should mention the filename without the extension.

Src: The path to a source file to dynamically compile and link against.

You must include either a Name or a Src attribute in an @ Assembly directive, but you cannot include both within the same directive. If you need to use both of these attributes, you must include multiple @ Assembly directives in the file.

An assembly is the actual .dll file on your hard drive where
the classes in the .NET Framework are stored. For example, all the classes contained in the ASP.NET Framework are located in an assembly named System.Web.dll.
More accurately, an assembly is the primary unit of deployment, security, and version control in the .NET Framework. Because an assembly can span multiple files, an assembly is often referred to as a “logical” dll.
There are two types of assemblies: private and shared. A private assembly can be used by only a single application. A shared assembly, on the other hand, can be used by all applications located on the same server.
Shared assemblies are located in the Global Assembly Cache (GAC). For example, the System.Web.dll assembly and all the other assemblies included with the .NET Framework are located in the Global Assembly Cache.
The Global Assembly Cache is located physically in your computer’s \WINDOWS\Assembly folder.
Before you can use a class contained in an assembly in your application, you must add a reference to the assembly.
By default, an ASP.NET application references the most common assemblies contained in the Global Assembly Cache:
. mscorlib.dll
. System.dll
. System.Configuration.dll
. System.Web.dll
. System.Data.dll
. System.Web.Services.dll
. System.Xml.dll
. System.Drawing.dll
. System.EnterpriseServices.dll
. System.Web.Mobile.dll
In addition, websites built to target the .NET Framework 3.5 also reference the following assemblies:
. System.Web.Extensions
. System.Xml.Linq
. System.Data.DataSetExtensions
You can target a website to work with the .NET Framework 2.0, .NET Framework 3.0, or.NET Framework 3.5. Within Visual Web Developer, select the menu option Website,Start Options and select the Build tab. You can select the framework to target from a dropdown list.
To use any particular class in the .NET Framework, you must do two things. First, your application must reference the assembly that contains the class. Second, your application must import the namespace associated with the class.
In most cases, you won’t worry about referencing the necessary assembly because the most common assemblies are referenced automatically. However, if you need to use a specialized assembly, you need to add a reference explicitly to the assembly. For example, need to interact with Active Directory by using the classes in the System.DirectoryServices namespace, then you will need to add a reference to the System.DirectoryServices.dll assembly to your application.
Each class entry in the .NET Framework SDK documentation lists the assembly and namespace associated with the class. For example, if you look up the MessageQueue class in the documentation, you’ll discover that this class is located in the System.Messaging namespace located in the System.Messaging.dll assembly.
If you are using Visual Web Developer, you can add a reference to an assembly explicitly by selecting the menu option Web Site, Add Reference, and selecting the name of the assembly that you need to reference. For example, adding a reference to the System.Messaging.dll assembly results in the web configuration file added to your application.
Web.Config:-
configuration
system.web
compilation
assemblies
add assembly=”System.Messaging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A”/
/assemblies
/compilation
/system.web
/configuration

Related Topic: