Advertisment

.Net: The Developer’s Perspective

author-image
PCQ Bureau
New Update

It’s been over one and a half years since the first beta of the .Net framework was released. Since then, it has changed the way applications are written; at least for those who have switched over to the framework for their development. By default, the framework supports development using the following.

Advertisment

VB.Net: With almost the same grammatical syntax, this eases the transition of the existing VB6 community to .Net



VC++.Net: The introduction of managed extensions for C++ not only lets the VC++ developer transit to .Net, but also allows them to develop applications that can reap the benefits of both .Net and the traditional Win32 world


Jscript.Net: Jscript gets a new meaning and becomes one of the main development tools for programming the framework


Visual C#: The latest entry into Microsoft’s development toolset, C# lets you work with the framework as close as you can get, without any legacy baggage to worry about

However, there is still a learning curve. And that is about getting to know the FCLs (Framework Class Libraries), which contain the crux of the functionality that this new development platform has to offer.

Overview



Prior to .Net, whatever applications were designed, they were specific to a particular development tool and platform. For instance, a Win32 DLL written using VC++ 6, and compiled on an Intel platform, would run only on the same environment, ie, Windows running on Intel. We couldn’t have thought of using it on a non-Windows platform. This is because when compiled, the DLL (and for that matter, any application) would contain the underlying microprocessor specific instructions. Hence, it got very closely bound to the processor. The binding with the OS comes into the picture since only Windows runs the true Win32 subsystems, and so, only they can understand and execute Win32 DLLs. And here we are talking actual environments, and not about Win32 emulators.

Advertisment

Another limitation, prior to .Net was that unless your code conformed to the COM (Component Object Model) specification, it wouldn’t be binary reusable by other development environments. For instance, assume we have a DLL exporting its functionality as C++ classes. To consume the exported functionality is easy when the client is written using the same development environment as the DLL exporting the functionality. This is because exported C++ classes are name-mangled by the compilers and this name-mangling scheme is very much compiler specific. Thus, a VB client application cannot even think of consuming the exported DLL functionality.

To address such issues, and more, the COM specification was laid out, which implied that for the code to be binary reusable, ie, for compiled code to be consumed by a client, the functionality must be exported as per the rules of COM specification.

But this had its own issues, like versioning problems, and the fact that it required the COM environment to be in place wherever such binary reusability was required.

Advertisment

What if there was an environment that had the binary code target it, instead of targeting the underlying microprocessor? It would be the job of this environment to run the code over any microprocessor/OS combination, for which the environment would be written. An important implication of this fact would be that the application code produced would be independent of the microprocessor. Our environment would be specific to various microprocessors, and OSs, but not the application code, which would be specific to the environment. Thus, our environment would be a kind of miniature OS/Processor mix, better tagged as a virtual machine. 

Since this virtual machine would expose a common platform for the applications written to target it, wherever this virtual machine would be present, our applications would execute just fine there. The job of the developers would be to write applications targeting this virtual machine, while it will be the job of the virtual machine developers to port it to as many OS/Microprocessor combinations as possible. Thus, our applications targeting the virtual machine would be portable and cross-platform in nature. 

Also, code produced by any language compiler that would be targeting this virtual machine could be easily binary reusable by other language compilers, if the virtual machine would imply some set of common rules for writing applications compliant to it. These rules if followed by all language compilers, cross-language integration and reusability would be promoted. 

Advertisment

The .Net framework is a superset of such a virtual machine, since it not only contains such a virtual machine (referred to as the Common Language Runtime, or CLR), but also contains class libraries, termed as FCL, targeting the CLR, containing a plethora of functionality, from File I/O, to network programming to WebServices to data access and tons more! For more details into the framework, see the .Net series published in PCQuest last year (July 2001 to December 2001). These articles are also available in this month’s CD.

Kumar Gaurav Khanna (Microsoft.Net MVP) runs www.wintoolzone.com

Lets talk about designing GUI-based Win32 applications. Before .Net, both the grammar and the functionality were part of the development tool, like VB or VC++. By grammar, we mean the syntactical construction of an idea, like looping and variable definition in the context of a given language. On the other hand, functionality refers to way things would be done. A classic example of this would be showing a Window to a user. While doing so in VB 6 would simply require the developer to add a form to their project and run it, a VC++ developer would have to derive classes from CWinApp, CFrameWnd, etc to do the same task, not to mention the scores of lines of code that would need to be written. Thus, if either of the two developers were expected to shift to the other platforms for their development needs, not only would they have a learning curve for the grammar, but also from the point of few of functionality, ie, how to do a given task in the new development environment.

Advertisment

With .Net, this intimacy between functionality and grammar has been broken. While any of the .Net-compliant languages offer their respective grammar, the way to do a particular task would remain the same irrespective of the language used. This is because the functionality is no longer part of the language, but has become a part of the .Net runtime environment. So, if you were to show a form using either VB.Net or VC# (or any .Net-compliant language), you would always be using the ShowDialog method of the Form class object in question. Thus, if developers are familiar with the classes that offer required functionality, they are more than half way up, in their transition to learn another .Net language. The only learning curve they would have before them would that be of the grammar of the language, which will always be there.

So, because you can utilize your existing insight of the FCL across languages, you are more productive than you ever were in the days of VS6.

Kumar Gaurav Khanna

Advertisment