Microsoft .net Tutorial

Deploying .NET Applications - III

2008-08-25T03:15:00.000-07:00

Merge Modules are a feature of Windows Installer that provides a standard method for delivering components, ensuring that the correct version of a component is installed. Merge Modules is something that we would give to a developer and not the end user. For example, if we want to distribute our DLL to another developer, we’ll create a Merge Module for it and distribute our DLL in a Merge Module. While deploying a finished product the developer will include this Merge Module in his MSI project and give it to the end user. Merge Modules are used to install components that are shared by multiple applications.

Now let us proceed with creation of a Merge Module. Here we have assumed that a Class Library stands created and the .DLL named ‘mylib.dll’ is ready. To create a merge module we need to select Merge Module from the project templates available and name it, say mergesetup. On doing so we are taken to the File System Editor. The File System Editor is shown in the following figure.

The File System Editor has two folders—Common Files Folder and Module Retargetable Folder falling under ‘File System on Target machine’. Files present in a Merge Module are generally sharable files hence Common Files Folder is a good option to deploy the files. Whichever file we copy in this folder gets deployed to the Common Files folder of the target machine. Here too we have an option of adding special folders to the File System Editor by right clicking on the left pane and selecting the desired folder. Files deployed in these folders would get deployed to corresponding folders on the target machine.

The other folder, i.e. the Module Retargetable Folder, offers a lot of flexibility in deciding where files should be installed. Let us see how. Now suppose the author of the merge module is not sure where the developer wants the file to get deployed on the end user’s machine. In such a case the author of the Merge Module must copy this undecided file into the Module Retargetable Folder and set a default location for this file using the Properties window. This gives the developer a chance to change or retarget the location of the file later while deploying the whole application to the end user. Let us see how it is done.

For this we need to copy ‘mylib.dll’ in the Module Retargetable Folder and set the DefaultLocation property of the Module Retargetable Folder to [GAC]. Next we must build the Merge Module. On doing so a ‘mergesetup.msm’ file would get created in the debug folder. We can now give this ‘.msm’ file to the developer.

Now assume that the developer creates a Setup project called ‘msimerge.msi’. To add the Merge Module to the project he needs to right click on the project name in the Solution Explorer and select Add | Merge Module. He can then browse for ‘mergesetup.msm’ and add it to his project. Now to retarget the file all he needs to do is open the Properties window of the ‘mergesetup.msm’ and set the Module Retargetable Folder property to any desired location. For example, if he wants the file to get installed in Common Files Folder and not GAC as specified by the author of the Merge Module then he might change the property. The Module Retargetable Folder property falls under the MergeModuleProperties in the Properties window.

Now whenever the end user installs the ‘msimerge.msi’, ‘mylib.dll’ gets installed in the Common Files Folder. Note that the developer can (and surely will) add his own application and associated files in ‘msimerge.msi’ along with ‘mergesetup.msm’ for deployment.

CAB Projects

Unlike the other deployment project types, there are no editors provided for working with CAB projects. Files and project outputs can be added to a CAB project through Solution Explorer, and properties can be set in the Properties window or in the Project Property pages.

For .NET deployment, a CAB file can contain only one assembly, and the CAB file must be assigned the same name as the contained assembly, but with the ‘.cab’ extension. For example, if we create a cabinet file for ‘mylib.dll’, we need to name the cabinet file as ‘mylib.cab’. Creating a cab file is very simple. Let us see how to create it.

To create a Cabinet or CAB project we select the Cabinet Project template from the New Project dialog and name it, say mylib. To add files to this project, we need to right click on the project name and select Add | Files. This would add the specified files in the project and on building the project the ‘mylib.cab’ file would get created which can be deployed to target machines. Double clicking on the cab file extracts the files compressed in it.

Deploying Windows Applications On Web

We have discussed two cases here. First we have explained the method by which a Windows application (.exe) can be executed directly on the web and second by which an installer (.msi) of the Windows Application can be downloaded from the web. For both the scenarios we have assumed that ‘windowsapp1.exe’ stands created. And for both we first need to create a Web Setup project.

To create a Web Setup project we selected the Web Setup Project from the project templates and named it websetup. On doing so, the File System Editor of websetup would get opened. Now we need to add ‘windowsapp1.exe’ to the Web Application Folder as shown in the following figure.

Next we need to change two of the properties of the Web Application Folder. First we have to set the AllowDirectoryBrowsing property to True. This property determines whether users can see a hypertext listing of files and subdirectories in a virtual directory. If it is set to True, users can browse for it. Next we have to set the VirtualDirectory property to myweb. Now we need to build websetup and copy the ‘websetup.msi’ file to the web server. On double clicking the MSI file the project would get installed. To test the project we need to start Internet Explorer and type the ‘http:\\computername\myweb’ URL. You will see the name of the ‘windowsapp1.exe’ file in the browser window. On clicking filename the EXE would get executed. For the second scenario we need to follow the same steps as given above, but instead of copying the EXE to the Web Application Folder, we need to copy an MSI (winsetup.msi) project, which includes the EXE to the folder. Then on deploying and installing ‘websetup.msi’ we would get the window displaying the name of the ‘websetup.msi’ file. On clicking it we would be presented with a dialog box that gives us options to install or download the MSI. On installing or downloading the MSI we would be able to execute the Windows application.

Setup Wizard

As told to you earlier the Setup Wizard helps us to start the deployment projects. The wizard guides us through the steps of creating setup program that contains all information required for installation. The steps in the Setup Wizard are self-explanatory. As soon as we select Setup Wizard, give the project a name (say wizsetup) and press OK, we are presented with a Welcome dialog.

On clicking ‘Next’ we are presented with the Step 2 window of the wizard. It asks us type of project we intend to make. Suppose we select the first option and click ‘Next’, we get the third dialog box. Here the Wizard asks us to add the files we wish to deploy. We can add the files by clicking on the ‘Add’ button and browsing for the desired files. On clicking the ‘Next’ button the Wizard presents us with the summary of the project. We had selected the first option and hence on clicking the ‘Finish’ button the Wizard takes us to the File System Editor of the project. We can now build the project as we would build any deployment project.

Deploying .NET Applications - II

2008-08-25T03:12:00.000-07:00

Sometimes our application may require some pre-requisites before installation. For example, our application may demand that Internet Explorer 5.0 or higher must be installed on the target machine. This calls for a check that must be satisfied for successful installation of the application. We can apply Launch Conditions in such cases. If the condition specified during this step (here, Internet Explorer installed) is not fulfilled then the installation halts. Note that here this step is intended to demonstrate the concept of launch conditions and ‘windowsapp1.exe’ has no actual dependency on Internet Explorer.

To add launch conditions we need to right click on the project in the solution explorer and select View | Launch Conditions. On doing so a Launch Condition Editor will get opened. Next we need to right click on the Requirements on Target Machine node and we would be presented with 5 options to choose from—Add File Launch Condition, Add Registry Launch Condition, Add Windows Installer Launch Condition, Add .NET Framework Launch Condition, and Add Internet Information Services Launch Condition. As the names suggest we can check for the specified entities on the target machine and if these entities are present on the target machine, the installation proceeds otherwise it halts.

Here we have added the Add File Launch Condition. On doing so two nodes called Search For File1 and Condition1 would get added in the Search Target Machine and Launch Conditions nodes respectively falling under the Requirements on Target Machine node. We changed the properties shown in the following table for the Search For File1 entity.

Property	Changed to...	Used
Name	Search For Internet Explorer	Specifies the name used in Launch Condition Editor.
FileName	Iexplore.exe	Specifies the name of a file to search for.
Folder	[ProgramFilesFolder]	Specifies the folder where a file search will start.
Depth	3	Specifies the number of levels of subfolders to search for a file.
MinVersion	5.00	Specifies the minimum version number for a file in the file search.

Now we need to specify the launch condition. To do so we must set the Condition property of the Condition1 entity to FILEEXISTS1. Note that in the Properties window of Search For File1 the Property property is set to FILEEXISTS1. We can also specify a message through the Properties window that would be displayed if the condition evaluates to false (i.e. if file is not found) at installation time.

Changing Icons

We can change icons for our application using the Properties window. To change the icon for the shortcuts we must select the shortcut file and set the Icon property of the file to any .ico file. Note that we need to first copy this file to the Application Folder to make it available.

On the same lines we can change the icon of the setup file that would be displayed in the Add/Remove Programs Window. To do so, we must right click on winsetup in Solution Explorer and select Properties. This would display the Properties window of the whole solution. Here we need to set the AddRemoveProgramsIcon to any desired file.

Adding File Associations

Suppose our application creates files having the user–defined extension (for example, we can serialize data in a file having the .mine extension) and now we wish that on double clicking such a file it should automatically get opened in our application. To achieve this we must use file associations. File Associations allows the developer to associate user-defined file types with his or her application. Assume that we need to deploy a file called myfile.mine with our application. To deploy it along with the application we first need to copy it in the Applications Folder. After installation whenever the user double clicks on this file it should get opened with windowsapp1.exe. Note that here too we have made an assumption for demonstration purpose that our application is creating files having .mine extension. Actually windowsapp1.exe is too simple and does not do any serialization or file I/O.

Now to associate this file with our application we must right click on the project name in the Solution Explorer and select View | File Types. On doing so we are presented with the File Types Editor. Next we need to right click on the node and select Add File type. Now we need to give any file name (here we have used file1) along with the extension (.mine) in the Properties window. This ensures that any file with the .mine extension would get opened with our application. Note that we need not specify the dot ( . ) while mentioning the extension. After this we have to set the Command property of the file to windowsapp1.exe. The File Types Editor along with the Properties window is shown in the following figure.

Now on re-building the project and running the installer, myfile.mine would get deployed along with the application. And moreover whenever the user double clicks on this file it gets opened with our application.

Adding Custom Actions

Custom actions allow us to run code at the end of an installation to perform actions that cannot be handled during installation. For example, if we wish to create a database after installation and before running the deployed application, we need to add the DLL or EXE, which would create a database, as a custom action. We can add custom actions through the Custom Actions Editor. The Custom Actions Editor can be opened by right clicking on the project name and selecting View | Custom Actions. The Custom Actions Editor is shown in the following figure.

This editor contains four folders, each corresponding with a phase of installation—Install, Commit, Rollback, and Uninstall. Custom actions are run in the same order that they are displayed in the editor. They can be reordered by dragging with the mouse or through the Cut and Paste commands on the Edit menu. All the Custom Actions run at the end of installation. In addition to the custom actions we add, there are 5 pre-defined custom actions included in Visual Studio .NET—Event Log, Message Queue, Performance Counter, Service, and Service Process components. We can also add these pre–defined Custom Actions in our project.

Deploying to Special Folders

In addition to the folders mentioned in the previous section—Application Folder, User’s Desktop, and User’s Programs Menu—we can add more folders to the File System Editor through the ‘Add Special Folders’ menu. If we right click on the left pane of the File System Editor we get a popup menu offering fourteen folders from which we can select the ones that we can add.
On selecting a folder from this menu it gets added to the ‘File System on Target Machine’ tree. This provision is made so that we can deploy our files to these specific folders on the target machine. For example, if we have a signed assembly and we wish to deploy it in the Global Assembly Cache of the target machine, all we need to do is add the Global Assembly Cache folder in the File System Editor and copy our signed assembly to it. On installing the application on the target machine one can find the assembly installed in the Global Assembly Cache.

That brings us to the end of discussion on how we can customize our MSI project according to the requirement of the application we want to deploy. If we wish to deploy the application on the development computer while building it, we have to right click on the project name in the Solution Explorer and select Install. And if we wish to deploy it on another computer then, as it might be very obvious to you by now, we need to distribute the winsetup.msi file.

Deploying .NET Applications

2008-08-25T03:08:00.000-07:00

Though distributing libraries in the form of DLLs was a major step forward, it suffered from the now in-famous DLL hell. COM could avoid this but it had no versioning mechanism. Moreover a COM component had foot-prints at so many places that if one of them got modified/corrupted, the application used to break down. .NET has come up with more sophisticated approaches for deployment and versioning.

Deployment Issues

Deployment is a process by which you distribute a finished application or component to be installed on other computers. In Visual Studio .NET, deployment is based on Microsoft Windows Installer technology. Microsoft Windows Installer is a service shipped with Windows Me, Windows 2000, and Windows XP. It is used for installation and configuration of applications to be installed. Every .NET application is deployed in the form of one or more assemblies. Assemblies may be deployed as regular standalone files (DLL or EXE files), or they may be deployed using CAB, MSI, or MSM files. The simplest way of deploying a private assembly is to use an XCOPY, i.e. copying the assembly in the desired folder. On the other hand we can deploy shared assemblies by installing them in the Global Assembly Cache of the target machine by using the Gacutil.exe.

To help programmers develop setup and deployment solutions, Visual Studio .NET provides several templates and wizards. We can create a setup or deployment project by selecting ‘Setup and Deployment Projects’ in the ‘New Project’ dialog box shown in the following figure.

Let us first discuss the types of projects shown in the dialog box and see the usage of each. Later we have illustrated how to deploy different types of applications using these projects.

Setup Project

A setup project builds a Windows Installer file or an MSI file with the .msi extension. This file is used to install the specified files and resources on the target machine automatically. The .msi file contains the application, any dependent files, information about the application such as registry entries, and instructions for installation. When the .msi file is distributed and run on another computer, you can be assured that everything necessary for installation is included; if for any reason the installation fails (for example, the target computer does not have the required operating system version), the installation will be rolled back and the computer returned to its pre-installation state.

CAB Project

A CAB project creates a cabinet file with the .cab extension. It is much like a Zip file, compressing a number of specified files into an easy to use and easy to deploy package. The resulting cabinet (.cab) file can then be deployed or downloaded. The files present in the .cab file can be extracted by double-clicking the .cab file.

Merge Module Project

A Merge Module project produces a merge module file having a .msm extension. A Merge Module is a single package that contains all files, resources, registry entries, and setup logic necessary to install a component.

Merge Modules are used to install components that are shared by multiple applications. The basic distinction between a Merge Module (.msm) and a Windows Installer (.msi) is based on the user using these components. Whatever we wish to deploy directly to the end user of the application (executable files, documents, HTML pages) should be packaged in a Windows Installer, whereas, whatever we wish to deploy to the developer (DLLs, controls, resources) should be packaged in a Merge Module. The developer can then repack it in a Windows Installer for distribution to the end user. It is possible to put multiple components into a single Merge Module but it's best to create a Merge Module for each component in order to handle versioning problems. Once you have distributed a Merge Module it should never be modified; instead you should create a new Merge Module for each successive version of your component.

Web Setup Project

Web Setup Project helps us to deploy web-based applications. In addition to this any Windows application or its installer can be deployed to a web server so that users can later download and run them from a web site. In order to deploy web-based application we will have to build a Web Setup Project, copy it to the web server and run the installer to install it on the server.

Setup Wizard

The Setup Wizard is used to help us start creating any of the above-discussed projects in a fast and simple manner. We just have to follow some simple steps the wizard leads us through and the wizard does the initial job for us. Next we may extend the project further as per our requirements. Now let us understand the projects discussed above in detail.

Setup Projects

We know that a Setup Project creates an .msi file, which actually installs the application on the target computer. To demonstrate this we plan to deploy a simple Windows application using the Setup Project. Here we have assumed that the Windows application stands created and the .EXE named windowsapp1.exe is ready. To deploy this Windows application we need to select ‘New | Project’ and select ‘Setup and Deployment project’ from the available options. Next we must select ‘Setup Project’ as the project template and specify the name (say winsetup) and the location of the setup project and click OK. Then we are taken to the File System Editor. The File System Editor is shown in the following figure.

The File System Editor has three folders—the Application Folder, the User’s Desktop folder and the User’s Programs Menu folder. These folders actually represent the folders on the target machine. For example, whatever you put in User’s Desktop will be deployed on the desktop of the target machine. From the three folders in the file system editor, files from Application Folder would be deployed in the Program Files folder; typically it is ‘C:\Program Files\Company Name\Application Name’ of the target machine. User’s Desktop folder contains files and folders that would appear on the desktop of the target machine on a per-user basis. Typically the path is ‘C:\Documents and Settings \username\Desktop’. User’s Programs Menu folder contains user’s program groups that would usually get deployed in ‘C:\Documents and Settings \username\Start Menu\Programs’.

Now we need to add the Windows application EXE file into this project. For this we must right click on the Application Folder. A menu is popped. We must select Add | File and on doing so an ‘Add Files’ dialog is popped. Now we need to browse for ‘windowsapp1.exe’ file so that it gets added to the Application Folder. We can add the EXE to User’s Desktop and User’s Programs Menu as well but while doing so we must keep in mind that these two folders are on per-user basis. This means that only the user who installs the application would be able to access the file on his desktop and not the other users.

This completes the basic steps needed to build an installer. We can now build this project and an installer called ‘winsetup.msi’ would get created in the debug folder. Now all we need to do is to distribute this installer and on running the installer on the target machine the application would get installed there.

On running the installer we get a series of screens depicting different stages of installation. Note that if our application needs more files than just the ‘windowsapp1.exe’ then we can copy them to any of the above-mentioned folders.

There is much more to a Setup Project than what we discussed above. We saw the simplest form and there are several more features that we need to explore. All the deployment capabilities discussed below are not mandatory and we can customize our installation process according to the needs of our application.

Adding Shortcuts

We can add shortcuts to our application in any of the 3 folders. For this we need to right click on the application file (‘windowsapp1.exe’) that we added to the project and select ‘Create shortcut to windowsapp1.exe’. On doing so a shortcut for our application would get created. Now we must drag this shortcut in the User’s Desktop Folder. If we wish to add a shortcut in User’s Programs Menu also, we need to create another shortcut in the same manner discussed above and drag it in the folder. On building and installing the application, the shortcuts get added in the specified folders of the target machine.

Adding Registry Entries

We can make a provision that some registry entries would be added for a particular application during installation of the application. We can then access these entries later through our application’s code at run-time. To add the registry entries we must right click on winsetup in the Solution Explorer and select View | Registry. On doing so we will be presented with the Registry Editor shown in the following figure.

Suppose we wish to add a key-value pair to HKEY_CURRENT_USER | Software | [Manufacturer]. For this we must right click on it and select New | Key. We can rename the key as per our wish. To add a value we need to right click on the newly formed key and select the type of value we wish to add, i.e. whether it should be a String value, a DWORD value, a Binary value, etc. We can set it to some value using the Properties Window. Now if we build winsetup and install the application, the entry would be made in the registry. We can verify this by executing the Registry Editor RegEdit through the ‘Start | Run’ dialog box.

Adding Custom Installation Dialog Boxes

Once the MSI file is built and we double click on it, the installation starts. The user is presented with five dialog boxes during installation. These dialog boxes are predefined dialog boxes that get added to our project by default. We can customize these dialogs or new dialog boxes to our project using the User Interface Editor. This editor can be opened by right clicking on the project in Solution Explorer and selecting ‘View | User Interface’.

The User Interface Editor shows a tree control containing two sections—Install and Administrative Install. The Install section contains dialog boxes that will be displayed when any end user runs the installer. Administrative installation is a feature of Microsoft Windows Installer that allows us to install a source image of an application on a network share. Users in a workgroup who have access to the network share can then install the application from the source image. The User Interface Editor allows us to specify a different set of installation dialog boxes that will be displayed when an administrator installs the application to a network share via the command line as shown below:

Msiexec.exe /a Setup1.msi

This will start the installer of our application and dialog boxes specified for the Administrative Install will be displayed.

The default set of predefined dialog boxes is displayed in the User Interface Editor; we can rearrange or delete these if we wish. The default set of dialog boxes varies according to the type of deployment project. Predefined dialog boxes are divided into three categories:

Start Dialog Boxes

Start dialog boxes are displayed before the installation begins. Commonly they are used to gather customer information or to allow the user to change the installation directory.

Progress Dialog Boxes

A progress dialog box is displayed to provide feedback on the progress of an installation.

End Dialog Boxes

End dialog boxes are displayed once the installation has finished successfully. Common uses are notifying the user that the installation is complete or to allow the user to launch the application.

We can remove dialog boxes from the default set as per our wish or reposition them using the right click | Move Up/Move Down options. Note that all combinations are not possible here. For example, we cannot remove the Progress dialog box and place it in the Start dialog boxes category after the Welcome dialog box.

Now in addition to these dialog boxes we can add and configure our own custom dialog boxes that would get displayed during the installation. To do so we need to right click on the desired category and select ‘Add Dialog’. On doing so the Add Dialog Box gets displayed.

Here we are presented with several ready-made dialog boxes that we may want to get displayed during installation. Following table indicates the use of these dialog boxes.

Dialog Box	Purpose
RadioButtons (2 buttons)	Gives the user a choice between two options through two radio buttons.
RadioButtons (3 buttons)	Gives the user a choice between three options through three radio buttons.
RadioButtons (4 buttons)	Gives the user a choice between four options through four radio buttons.
Checkboxes A, B, or C	Gives the user a choice to add 1, 2, 3 or 4 checkboxes in the same dialog.
Customer Information	Used to retrieve information including name, company, and serial number.
Textboxes A, B, or C	Used to retrieve custom information using 1, 2 or 3 text boxes.
License Agreement	Displays a license agreement for the user to read and acknowledge.
Read Me	Allows the user to view any Read me file in .rtf format.
Register User	Allows the user to submit registration information.
Splash	Displays a Splash Screen in .bmp format during installation.

Out of the several dialog boxes listed in this table we would discuss only the ones that are likely to be used more commonly. These include the Checkbox dialog box, Read Me Dialog box and the Splash dialog box.

The Checkbox Dialog Box

Suppose during installation we plan to ask the user whether he wants to add the ‘Disclaimer.txt’ file along with ‘windowsapp1.exe’ or not. To control this we plan to add the Checkbox dialog box. If the user checks the Checkbox, the text file gets installed. To add this custom dialog box we have followed the same steps discussed above and added the Checkboxes (A) Dialog. This dialog box would get added as the last dialog box of the Start dialog boxes category. So we can move it up by two positions. Next we have changed some properties of the Checkboxes (A) dialog box. These are shown in the following table.

Property	Changed to...
BannerText	Disclaimer
BodyText	Do you want to install the Disclaimer text file?
Checkbox1Label	Install Disclaimer
Checkbox1Value	Unchecked
Checkbox1Visible	True
Checkbox2Visible	False
Checkbox3Visible	False
Checkbox4Visible	False

Note that we have changed the visible property of the remaining checkboxes to false because we need just one checkbox. Now we need to add a folder in the Application Folder named Disclaimer. For this we must right click on the Application Folder and select ‘Add | Folder’. This would add a new folder we have renamed it to Disclaimer. Next we added a text file called ‘Disclaimer.txt’ to this folder. Hence the Application Folder would contain the ‘windowsapp1.exe’ along with the Disclaimer folder holding the ‘Disclaimer.txt’ file. Then comes the most important step of setting the Condition property of the ‘Disclaimer.txt’ file so that it would only get installed when the checkbox is checked. To do this we need to open the Properties Window of the ‘Disclaimer.txt’ and set its Condition property to CHECKBOXA1=1. On building the winsetup.msi project, and double clicking it we are presented with this dialog box in the second step of the installation process. The Disclaimer dialog box is shown in the following figure.

The Read Me Dialog box

This dialog box displays the Read Me file during installation procedure and installs it along with the application. To demonstrate this we must add the Read Me dialog box in the Start dialog boxes category. Next we need to associate a Rich Text File (rtf) with this dialog box. For this we have to create a ‘ReadMe.rtf’ file and add it to the Applications Folder. Next we have to set the ReadmeFile attribute of the Read Me Dialog box to this file. We can browse for this file and since we had added it to the Applications Folder we will find it there. Note that we cannot browse beyond the three folders (Application Folder, User’s Program and User’s Programs Menu), hence if we wish to make any file available in the project we have to first get it copied in one of these. Now after re-building the project and installing it we are presented with this Read Me dialog box as the 5th step of installation and this file gets copied along with the folder.

The Splash Dialog Box

We added the Splash dialog box just after the Welcome dialog box. The User Interface Editor after addition of all the dialog boxes is shown in the following figure.

To display a splash screen in the Splash dialog box, all we need to do is to set the SplashBitmap property of the dialog to a ‘.bmp’ file. To make the file available we must first add it to the Application Folder. On re-building this project and running the installer we are presented with the Splash dialog box.

In the next part we would see how to add launch conditions to the setup project.

What is .NET?

2008-08-25T02:25:00.000-07:00

Though not documented there are two nightmares known in the programming world. One is the development nightmare and another is the distribution nightmare. Let�s elaborate on this.

Suppose we wish to develop an Internet application that allows businesses to communicate vital information with each other across existing communication lines. Let�s look at typical solution that can be offered to this problem using Microsoft technologies. If the application is an n-tier application then we would need HTML, DHTML & Java Script in the front-tier; VBScript, ASP, MTS, C++, VB, COM in the middle-tier and SQL, ADO in the back-tier. Developers possessing sufficient skill in all of these areas are few and costly. In short, a perfect recipe for development nightmare.Even if the developers are able to successfully develop the applications, they would be required to spend hours battling component version conflicts (popularly known as DLL Hell) when the time comes to install their products. Assured distribution nightmare, in short.

Sun�s solution to this problem could be to use Java applets and servlets in the front-tier, Enterprises Java Bean (EJB) or CORBA or RMI in the middle-tier, and JDBC and a suitable database in the back-tier. The common theme here is every developer should learn Java language. This is a far-fetched dream. Though an attempt to make every programmer a Java programmer has met with more than a lukewarm success, the ground reality is that there would be several languages in existence, each camp having its own faithful band of programmers.

.Net is an attempt to bring order to this chaos. .Net is a development platform that makes it easier for programmers using different languages to quickly create robust internet applications. Let�s now see how .Net makes Internet development easier.

Language Of Choice

A developer can pick the .Net language that he likes most, write components in it, and share the compiled binary version of his component with other developers using other .Net languages. As on date there are 22 languages including VB, C++, C#, COBOL, etc. from which the programmer can choose. Microsoft has made the specifications for .Net development platform freely available to compiler vendors in the form of Common Language Specification (CLS). Vendors can develop compilers that produce standard binary code confirming to the CLS.

Easy DeploymentDeployment in a .Net environment involves a mere file copy. There are no versioning problems as all the version information is included in the metadata (data about data) that is distributed with the component. Even different versions of the same component can run side by side on the same machine.

Less Plumbing Code

VS.Net development environment eliminates a lot of hand coding by providing wizards and liberal use of drag & drop functionality. .Net also provides standard classes that developers can use to create powerful applications quickly.]

.Net Framework

.Net is actually wrapper around the operating system. Software developed with .Net doesn�t have to worry about operating system tasks like File Handling and Memory Allocation. Even though Microsoft doesn�t say so, this appears to be a silent preparation for the future where the software developed for .Net would be portable to a wide variety of Hardware and OS. Beta version of VS.Net supports all versions of Win2000, Windows NT4, Win9X and Windows ME. .Net makes development of Internet applications as easy as Desktop applications. Secondly, it provides a very high level of integration of front, middle and back-tier. The following figure shows major components of .Net framework.

Figure 1.1: .Net Framework

Let�s now understand these three components.

The Common Language Runtime

A runtime is an environment in which programs are executed. For example, to execute a program written in VB6, the machine must have a VB runtime (msvbvm.dll) installed. Similarly VC++ programs and Java programs too require unique runtime components. Since different languages require different runtime the developer�s life becomes more difficult. Imagine a situation where an ActiveX control has been developed in VB. While downloading this component a user may also have to download the VB runtime if it is not already installed on the machine. And imagine what would be the solution if Windows weren�t installed on the machine.

To avoid such problems .Net introduces a single Common Language Runtime (CLR) that all .Net languages share. The following figure shows how CLR works

Figure 1.2: Execution Process Under .Net Framework

Once our code is written, we compile it, and the compiler translates it to Microsoft Intermediate Language (MSIL). MSIL is a CPU-independent set of instructions that can be efficiently converted to native (CPU dependent) code. MSIL code is a language independent code. The Linker then links the IL code converted by one language compiler with the IL code compiled by another language compiler. The result is an EXE or DLL, containing the IL code, which is saved to disk. VS.Net comes with different language compilers to generate IL code. Then on execution, the IL code and any requested functionality from the .Net base classes is brought together. The JIT compiler process the combined code creating managed native code (Code that targets the runtime is called managed code. The runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used.), which is passed to the CLR.

Net Base Classes

.Net supplies a library of base classes that developers can use to implement applications quickly. Developers can either use them by building objects from these classes and invoking the class methods. Alternately they can derive new classes from these standard classes.

These classes include:

Classes and types related to basic database management.
Classes to debug an application and to trace the execution.
Types that allow reading/writing to files and other data streams.
Members to calculate common mathematical quantities.
Capability to inspect metadata.
Types, which enable security capabilities.

User and Program Interfaces

This forms the top layer in the .Net architecture. This includes Windows Forms, Windows Application Services, Web Forms and Web Services. Windows forms (often called as WinForms) offer a new way to create standard Win32 desktop applications. Web Forms provide a powerful, form-based user-interface for the web. Web Services provide a mechanism for programs to communicate over the Internet using SOAP (Simple Object Access Protocol). These services are similar to COM/DCOM services that were used for object brokering & interfacing. However, Web Services allow integration with non-Microsoft platform as well.
The potential of Web Services is unlimited. For example, a software company may provide a Web Service to calculate income tax. Any company that wants to calculate income tax can subscribe to this Web Service. The customer company need not deploy the income tax calculator. It simply needs to access the Web Service. The company offering the service can dynamically update it to accommodate new taxation rates. The subscribers won�t have to do anything to get the new updates. In future a collection of such Web Services may replace packaged software. Other Web Services that can be developed include weather information, stock quotes, shipping status, news items, etc. I think you get the picture now.�

Printing Through .NET

2008-08-25T02:24:00.000-07:00

Any sophisticated application would definitely have support for printing. .NET facilitates printing with the help of a PrintDocument component. Along with this we can make use of the various dialog boxes that are commonly used for printing.

The PrintDocument Component

.NET supports printing through methods and properties of the PrintDocument component. The PrintDocument component is available in the Toolbox and when added to a form, it appears in the component tray at the bottom of the Windows Forms Designer. This is because the PrintDocument component is not visible at runtime.

The PrintDocument class represents the PrintDocument component and falls under the System.Drawing.Printing namespace. Typically in a printing application we call the Print( ) method of the PrintDocument class. It also contains properties such as DefaultPageSettings, which gets or sets page settings that are used as defaults for all pages to be printed, PrinterSettings, which gets or sets the printer that prints the document. The class contains events like BeginPrint, EndPrint and PageEvent. BeginPrint is raised when the Print( ) method is called and before the first page of the document is printed. Here we can do any initializations if needed. EndPrint event is raised when the last page of the document has been printed. We can do cleaning up jobs here. The PrintPage event is raised when it’s time to print the current page. We can write code in the handler of this event to do the desired printing. Hence the order of events raised when Print( ) method is called is BeginPrint, PrintPage and then EndPrint. In the following sections, we have programmed simple examples that illustrate how to use the PrintDocument component to achieve printing.

Printing A Salary Slip

Let us see an example where we wish to print salary slip of an employee. Here we have created a Windows Form Application named Salaryslip. We have added 5 textboxes to the form to gather information about the employee—a ‘Name’ textbox named name, a ‘Month’ textbox named month, a ‘Gross Salary’ textbox named sal, a ‘Tax’ textbox named tax and a ‘Total’ textbox named total. We have added these textboxes to collect information about an employee like his name, his salary, the tax he needs to pay, etc. Next we have calculated his salary according to the tax. We have also added two buttons to the form—a ‘Print’ button named print and a ‘Calculate’ button named cal. As soon as the user clicks on the Calculate button the salary gets calculated and if he clicks on the Print button the salary slip gets printed. Next we have added the PrintDocument component to our form. It gets added in the component tray. We have changed the name of the component from PrintDocument1 to mypdoc.

We have added an event handler called cal_Click( ) to handle the Click event of the Calculate button. This handler is shown below:

private void cal_Click ( object sender, System.EventArgs e )
{

int t = int.Parse ( sal.Text ) - int.Parse ( tax.Text ) ;
total.Text = t.ToString( ) ;

}

Here we have subtracted the tax from the gross salary and stored it in an integer variable called t. Then we have set the Text property of the textbox named total to t (we converted t from an integer to a string). On clicking the Print button the event handler called print_Click( ) would get called. This handler is shown below:

private void print_Click ( object sender, System.EventArgs e )
{

mypdoc.Print( ) ;

}

In this handler we have simply called the Print( ) method of the PrintDocument class. Whenever the Print( ) method is called the events are raised. We have not added handlers for the BeginPrint and EndPrint handlers. We have added a handler for the PrintPage event. If we double click on mypdoc in the component tray of the Windows Form Designer, the mypdoc_PrintPage( ) event handler gets added automatically to the code. This handler is shown below:

private void mypdoc_PrintPage ( object sender, System.Drawing.Printing.PrintPageEventArgs e )
{

Graphics g = e.Graphics ;
SolidBrush b = new SolidBrush ( Color.Black ) ;
Pen p = new Pen ( Color.Black, 3 ) ;
Font f = new Font ( "Arial", 10 ) ;

g.DrawString ( "Name", f, b, 30, 50 ) ;
g.DrawString ( empname.Text, f, b, 130, 50 ) ;

g.DrawString ( "Month", f, b, 30, 70 ) ;
g.DrawString ( month.Text, f, b, 130, 70 ) ;

g.DrawString ( "Gross Salary", f, b, 30, 100 ) ;
g.DrawString ( sal.Text, f, b, 130, 100 ) ;

g.DrawString ( "Tax", f, b, 30, 120 ) ;
g.DrawString ( tax.Text, f, b, 130, 120 ) ;

g.DrawString ( "Total", f, b, 30, 140 ) ;
g.DrawString ( total.Text, f, b, 130, 140 ) ;

Font f1 = new Font ( "Arial", 15, FontStyle.Bold ) ;
g.DrawString ( "KNK Pvt Ltd", f1, b, 50, 10 ) ;

g.DrawRectangle ( p, 14, 4, 180, 175 ) ;
p.Width = 2 ;
g.DrawRectangle ( p, 22, 95, 165, 75 ) ;

}

PrintPageEventsArgs provides data for the PrintPage event. Using this class we have retrieved the Graphics object using which we will do the painting. Next we have created Pen, Brush and Font objects. Then using these objects we have printed the strings.
Run the program. Enter the salary and tax and click the Calculate button. The result would get displayed in the Total text box. Figure 1 shows the form with salary details.

Figure 1

As soon as we click the Print button, the ‘Printing’ dialog indicating the number of page that is getting printed gets displayed. The salary slip that gets printed is shown in Figure 2.

Figure 2

The .NET Framework

2008-08-25T02:19:00.000-07:00

Not in the distant past we used different programming models for developing Windows desktop application and web based application. Programming a Windows desktop application using VB or VC++ was pretty different than programming a web based application using technologies like ASP, COM, etc. With the launch of .NET this differentiation has been obscured. .NET offers a consistent programming model irrespective of the type of application that we intend to build. Using .NET compliant languages we can create every sort of application, be it a Windows desktop application, a web application, a database application, a DLL, a setup and deployment project, a distributed application, etc.

Many of Microsoft’s new technologies were extensions and improvements of previous ones. For example, COM was extended from OLE and COM+ was extended from COM. Obviously, this was to maintain the backward compatibility. Though these extensions could solve the problems at hand, they ultimately led to more complexities. Microsoft’s new .NET technology is a welcome deviation from this path. It has been thought out and designed from scratch. It does not mean that .NET is not backward compatible. We can import the existing components to work in .NET. We can also create components in .NET that can be used by the existing clients. .NET is a new framework for programming Windows. It provides an application execution environment that manages memory, addresses versioning issues and improves the reliability, scalability, and security of your application.

Microsoft has upgraded VB and languages like C++, COBOL, etc. to target the .NET environment. In addition to these languages, it has provided a fresh .NET compliant language—C#. It is natural to think that migration from Microsoft’s popular Visual Basic language to VB.NET or transition from VC++ to VC++.NET would be smooth. But one quick look at C# would convince you that in many cases coding in C# is more clean, pleasant and efficient.

There are two main components of .NET framework—.NET Framework Base Class Library (FCL) and Common Language Runtime (CLR). Let us understand each of them.

The base class library is an extensive common class library that can be used by any .NET compliant language. These classes encapsulate a high degree of functionality that programmers can use in their programs. The library includes classes for creating and displaying windows forms, web forms, serialization, accessing network and internet, manipulating XML documents, accessing databases, etc.

Common Language Runtime is the heart of .NET framework. It actually manages the code during execution. The code that runs under CLR is called ‘managed code’. The code that is executed under .NET runtime gets benefits like cross-language inheritance, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.

Following figure illustrates the components of .NET framework.

The applications created in .NET compliant languages use the classes provided by base class library. These applications run under .NET runtime that manages the lifetime of objects created by applications, throws exceptions, etc.
Let us now take a look at other important features of .NET.

Common Type System: Language interoperability under .NET is possible only when all the languages share a common data type system. For this, common type system (CTS) is introduced. CTS ensures that an int in C# is same as an int in VC++. Under CTS, all the classes are derived from the System.Object class and all the primitive data types are mapped to the structures defined in base class library. CTS also specifies the visibility level (from where the type should be accessible) of data types.

Intermediate Language: A .NET programming language does not compile into executable code; instead it compiles into an intermediate code called Microsoft Intermediate Language (MSIL). IL is a CPU-independent language. The IL code is sent to the CLR that converts the code to machine language using the Just In Time compiler, which is then run on the host machine. Important aspect of IL language is that it provides the hardware abstraction layer. We can view the IL code of our application using the ILDASM tool shipped with Visual Studio.NET.

JIT Compilation: JIT (Just In Time) compiler is a crucial component of .NET framework. The JIT compiler converts IL code into machine code, which is then executed. The JIT compiler does not compile entire code at once because it could hamper the performance of the program. It compiles the code at runtime, at the time it is called. The code that is compiled gets stored until the execution comes to an end. This avoids recompilation of code. The reason why conversion from IL code to machine code takes place at runtime is that, the JIT first gets information of the processor type and convert the IL code so that it would run on that type of processor.

Assemblies: An assembly is a unit containing IL code of a program. It is similar to a DLL file, but difference is that unlike DLL, an assembly is self-describing. Assemblies contain assembly metadata (or manifest) that gives details of the assembly, type metadata describing the types, methods, etc. defined in the assembly and resources.

Garbage Collection: Garbage Collection is a program that is invoked by the CLR to free the memory that is not being used by the application. Because of this technique the programmers no more need to take care of memory leakages, dangling pointers and clean up of memory.
I hope that what we saw above would give you a glimpse of .NET framework. Let us now create a simple program in C# that uses the .NET framework. It is assumed that you have installed Visual Studio.NET on a machine running under Windows NT/2000/XP.

The First C# Program
The steps to create the program are given below.

Start Microsoft Visual Studio.NET from ‘Start | Program | Microsoft Visual Studio.NET’ menu option.
Create a new C# project by selecting ‘File | New | Project’ menu option. A ‘New Project’ dialog would appear. From the ‘New Project’ dialog box select project type as ‘Visual C# Projects’.
Select ‘Console Application’ from the list of Templates.
Select a location where this project should get saved. Give name to the project as Simple. Click the OK button.
A ‘Class1.cs’ file (cs stands for CSharp) would get created with the skeleton code given below.

using System ;
namespace Simple
{

class Class1
{

static void Main ( string[ ] args )
{

}

Now, add the following statement that would display the string “Hello world” on screen.

Console.WriteLine ( “Hello C#” ) ;

Compile and execute the program by pressing Ctrl + F5. The program execution starts from the Main( ) function. Since C# is a pure object-oriented language it does not allow us to create global variables and functions. Instead, all variables and functions including Main( ) should be defined inside a class.

To send output to the screen we have used the WriteLine( ) function. We can display any data type through this function. Since WriteLine( ) belongs to the Console class we have to use the form Console.WriteLine( ) to call it.

To be able to use the Console class in any program we need to import it from a namespace, which has been done in our program through the statement using System. Like the Console class our class is also enclosed in the Simple namespace.

Those who have not done C++ programming may find the terms class and namespace confusing. We would discuss them in detail in the forthcoming articles.