• Choose a category
• All
• Classic-Fiction

By Root 5796 0

the difference between Name and Src is minimal, although Name points to an existing and ready-to-load assembly. The source file referenced by Src is compiled only the first time it is requested. The ASP.NET runtime maps a source file with a dynamically compiled assembly and keeps using the compiled code until the original file undergoes changes. This means that after the first application-level call, the impact on the page performance is identical whether you use Name or Src.

Any assemblies you register through the @Assembly directive are used by the compiler at compile time, which allows for early binding. After the compilation of the requested ASP.NET file is complete, the assembly is loaded into the application domain, thus allowing late binding. In the end, any assemblies listed through the directive (implicitly through the root configuration or explicitly through the application configuration) is loaded into the AppDomain and referenced on demand.

Important

Removing an assembly from the Visual Studio project doesn’t help much to keep the AppDomain lean and mean. To ensure you load all the assemblies you want and only the ones you want, you should insert the following code in your configuration file:

...

The tag removes all default configurations; the subsequent tags add just the assemblies your application needs. As you can verify for yourself, the default list will likely load assemblies you don’t need.

In debug mode, you can track the list of assemblies actually loaded in the AppDomain for the site using the following code:

var assemblies1 = Assembly.GetExecutingAssembly().GetReferencedAssemblies();

var assemblies2 = AppDomain.CurrentDomain.GetAssemblies();

The size of the two arrays can vary quite a bit. The former counts just the dynamically referenced assemblies at the current stage of execution. The latter counts the number of assemblies physically loaded in the AppDomain (which can’t be unloaded unless you recycle the application).

The @Import Directive

The @Import directive links the specified namespace to the page so that all the types defined can be accessed from the page without specifying the fully qualified name. For example, to create a new instance of the ADO.NET DataSet class, you either import the System.Data namespace or specify the fully qualified class name whenever you need it, as in the following code:

System.Data.DataSet ds = new System.Data.DataSet();

After you’ve imported the System.Data namespace into the page, you can use more natural coding, as shown here:

DataSet ds = new DataSet();

The syntax of the @Import directive is rather self-explanatory:

<%@ Import namespace="value" %>

@Import can be used as many times as needed in the body of the page. The @Import directive is the ASP.NET counterpart of the C# using statement and the Visual Basic .NET Imports statement. Looking back at unmanaged C/C++, we could say the directive plays a role nearly identical to the #include directive. For example, to be able to connect to a Microsoft SQL Server database and grab some disconnected data, you need to import the following two namespaces:

<%@ Import namespace="System.Data" %>

<%@ Import namespace="System.Data.SqlClient" %>

You need the System.Data namespace to work with the DataSet and DataTable classes, and you need the System.Data.SqlClient namespace to prepare and issue the command. In this case, you don’t need to link against additional assemblies because the System.Data.dll assembly is linked by default.

Note

@Import helps the compiler only to resolve class names; it doesn’t automatically link required assemblies. Using the @Import directive allows you to use shorter class names, but as long as the assembly that contains the class code is not properly referenced, the compiler will generate a type error. In this case, using the fully qualified class name is of no help because the compiler lacks the type definition. You might have noticed that, more often than not,