Dot Net

In ASP.NET the Response object is of type HttpResponse and when you say Response.Write you’re really saying (basically) HttpContext.Current.Response.Write and calling one of the many overloaded Write methods of HttpResponse. Response.Write then calls .Write() on it’s internal TextWriter object:

public void Write(object obj){ this._writer.Write(obj);}

HttpResponse also has a Property called Output that is of type, yes, TextWriter, so:

public TextWriter get_Output(){ return this._writer; }

Which means you can to the Response whatever a TextWriter will let you. Now, TextWriters support a Write() method ala String.Format, so you can do this:

Response.Output.Write(”Scott is {0} at {1:d}”, “cool”,DateTime.Now);

But internally, of course, this this is happening:

public virtual void Write(string format, params object[] arg)

{

this.Write(string.Format(format, arg));

}

ActiveX control is a special type of COM component that supports a User Interface. Using ActiveX Control in your .Net Project is even easier than using COM component. They are bundled usually in .ocx files. Again a proxy assembly is made by .Net utility AxImp.exe (which we will see shortly) which your application (or client) uses as if it is a .Net control or assembly.

Making Proxy Assembly For ActiveX Control: First, a proxy assembly is made using AxImp.exe (acronym for ActiveX Import) by writing following command on Command Prompt:

C:> AxImp C:MyProjectsMyControl.ocx

This command will make two dlls, e.g., in case of above command

MyControl.dll

AxMyControl.dll

The first file MyControl.dll is a .Net assembly proxy, which allows you to reference the ActiveX as if it were non-graphical object.

The second file AxMyControl.dll is the Windows Control, which allows u to use the graphical aspects of activex control and use it in the Windows Form Project.

Adding Reference of ActiveX Proxy Assembly in your Project Settings: To add a reference of ActiveX Proxy Assembly in our Project, do this:

Machine configuration file: The machine.config file contains settings that apply to the entire computer. This file is located in the %runtime install path%Config directory. There is only one machine.config file on a computer. The Machine.Config file found in the "CONFIG" subfolder of your .NET Framework install directory (c:WINNTMicrosoft.NETFramework{Version Number}CONFIG on Windows 2000 installations). The machine.config, which can be found in the directory $WINDIR$Microsoft.NETFrameworkv1.0.3705CONFIG, is an XML-formatted configuration file that specifies configuration options for the machine. This file contains, among many other XML elements, a browserCaps element. Inside this element are a number of other elements that specify parse rules for the various User-Agents, and what properties each of these parsings supports.

For example, to determine what platform is used, a filter element is used that specifies how to set the platform property based on what platform name is found in the User-Agent string. Specifically, the machine.config file contains:

platform=Win95

platform=Win98

platform=WinNT

...

In classic ASP all Web site related information was stored in the metadata of IIS. This had the disadvantage that remote Web developers couldn't easily make Web-site configuration changes. For example, if you want to add a custom 404 error page, a setting needs to be made through the IIS admin tool, and you're Web host will likely charge you a flat fee to do this for you. With ASP.NET, however, these settings are moved into an XML-formatted text file (Web.config) that resides in the Web site's root directory. Through Web.config you can specify settings like custom 404 error pages, authentication and authorization settings for the Web sitempilation options for the ASP.NET Web pages, if tracing should be enabled, etc. The Web.config file is an XML-formatted file. At the root level is the tag. Inside this tag you can add a number of other tags, the most common and useful one being the system.web tag, where you will specify most of the Web site configuration parameters. However, to specify application-wide settings you use the tag.

For example, if we wanted to add a database connection string parameter we could have a Web.config file like so.

ADO uses Recordsets and cursors to access and modify data. Because of its inherent design, Recordset can impact performance on the server side by tying up valuable resources. In addition, COM marshalling - an expensive data conversion process - is needed to transmit a Recordset. ADO.NET addresses three important needs that ADO doesn't address:

1. Providing a comprehensive disconnected data-access model, which is crucial to the Web environment

2. Providing tight integration with XML, and

3. Providing seamless integration with the .NET Framework (e.g., compatibility with the base class library's type system). From an ADO.NET implementation perspective, the Recordset object in ADO is eliminated in the .NET architecture. In its place, ADO.NET has several dedicated objects led by the DataSet object and including the DataAdapter, and DataReader objects to perform specific tasks. In addition, ADO.NET DataSets operate in disconnected state whereas the ADO RecordSet objects operated in a fully connected state.

In ADO, the in-memory representation of data is the recordset. In ADO.NET, it is the dataset. A recordset looks like a single table. If a recordset is to contain data from multiple database tables, it must use a JOIN query, which assembles the data from the various database tables into a single result table. In contrast, a dataset is a collection of one or more tables.

Now VB.NET is object-oriented language. The following are some of the differences:

Data Type Changes

The .NET platform provides Common Type System to all the supported languages. This means that all the languages must support the same data types as enforced by common language runtime. This eliminates data type incompatibilities between various languages. For example on the 32-bit Windows platform, the integer data type takes 4 bytes in languages like C++ whereas in VB it takes 2 bytes. Following are the main changes related to data types in VB.NET:

. Under .NET the integer data type in VB.NET is also 4 bytes in size.

. VB.NET has no currency data type. Instead it provides decimal as a replacement.

. VB.NET introduces a new data type called Char. The char data type takes 2 bytes and can store Unicode characters.

. VB.NET do not have Variant data type. To achieve a result similar to variant type you can use Object data type. (Since every thing in .NET including primitive data types is an object, a variable of object type can point to any data type).

. In VB.NET there is no concept of fixed length strings.

. In VB6 we used the Type keyword to declare our user-defined structures. VB.NET introduces the structure keyword for the same purpose.

Declaring Variables

Consider this simple example in VB6:

Dim x,y as integer

A strong name consists of the assembly's identity its simple text name, version number, and culture information (if provided) plus a public key and a digital signature. It is generated from an assembly file (the file that contains the assembly manifest, which in turn contains the names and hashes of all the files that make up the assembly), using the corresponding private key. Assemblies with the same strong name are expected to be identical.

Strong names guarantee name uniqueness by relying on unique key pairs. No one can generate the same assembly name that you can, because an assembly generated with one private key has a different name than an assembly generated with another private key.

When you reference a strong-named assembly, you expect to get certain benefits, such as versioning and naming protection. If the strong-named assembly then references an assembly with a simple name, which does not have these benefits, you lose the benefits you would derive from using a strong-named assembly and revert to DLL conflicts. Therefore, strong-named assemblies can only reference other strong-named assemblies.

There are two ways to sign an assembly with a strong name:

1. Using the Assembly Linker (Al.exe) provided by the .NET Framework SDK.

2. Using assembly attributes to insert the strong name information in your code. You can use either the AssemblyKeyFileAttribute or the AssemblyKeyNameAttribute, depending

An assembly manifest contains all the metadata needed to specify the assembly's version requirements and security identity, and all metadata needed to define the scope of the assembly and resolve references to resources and classes. The assembly manifest can be stored in either a PE (Portable Executable) file (an .exe or .dll) with Microsoft intermediate language (MSIL) code or in a standalone PE (Portable Executable) file that contains only assembly manifest information. The following table shows the information contained in the assembly manifest. The first four items the assembly name, version number, culture, and strong name information make up the assembly's identity.

Assembly name: A text string specifying the assembly's name.

Version number: A major and minor version number, and a revision and build number. The common language runtime uses these numbers to enforce version policy.

Culture: Information on the culture or language the assembly supports. This information should be used only to designate an assembly as a satellite assembly containing culture- or language-specific information. (An assembly with culture information is automatically assumed to be a satellite assembly.) Strong name information: The public key from the publisher if the assembly has been given a strong name. List of all files in the assembly: