Update 5 Apr 2001: language compatiblity for VB restored.

Update 14 Mar 2001: .NET to support Linux (silicon.com)! Cross compilation for Windows and Linux is already available with Borland's Delphi, but this is the first time it's been talked about from Microsoft.
Of course the press may be overstating the case here: Microsoft's view is that applications from all architectures will be able to interoperate through SOAP (the XML-based protocol for remote procedure calls) - which is fully supported by .NET and indeed already supported through the SOAP toolkit for existing Microsoft development tools.

Microsoft's .NET Future

Beta1 of the .NET framework and the Visual Studio .NET development toolset appeared in late 2000 amid a flurry of marketing hype. It's easy to dismiss product announcements as overenthusiastic marketing, but from a look at the product beta, this is not the case here.  (To get the beta, updates and the final product when it comes out, the best thing to do is get an MSDN Subscription.)

After studying .NET in more detail, we were stunned by the scale and scope of the changes in the new architecture, which amount to a complete redevelopment of the Microsoft development architecture.

.NET - A Total Rewrite

Lessons from Java

Since Microsoft have been prevented from developing their Java toolset further, they have gone a step further..
With .NET, some of the benefits of Java are available to other languages, including C++, C#, Visual Basic, Visual Foxpro and potentially others in future.

Portability and Just-in-Time compilation

The .NET compilers take whatever source code language is being used and compile to a new assembler-like pseudocode called Microsoft Intermediate Language (MSIL).  This is platform-neutral, and a final Just-in-time compilation step (part of the Common Language Runtime ) translates the intermediate language into code for the target processor.

Although .NET applications are initially portable only in a limited sense (across Win32 platforms including Windows2000, NT4, WindowsME/98 and possibly even Windows95), in the future this means that .NET executables can be deployed  across WindowsCE platforms including non-Intel/x86 processors, and we assume the next generation Win64 operating systems (now in Beta known as XP [previously Whistler]).

In theory a simple .NET application will work on any environment for which a .NET Common Language Runtime (CLR) engine exists.  In this  respect the CLR plays a similar role to the Java Virtual Machine.  [In fact it is a mystery to many why MS never did this before, since their popular development tool Visual Basic for years only compiled to a pseudo-code which was interpreted by the runtime, it was always a shame the runtime was not developed for other platforms.]
In fact platform compatibility is in some ways less of an issue today since all applications using internet technologies should be portable across different platforms at the client end, but MS have got the right idea here if the architecture allows a seamless upgrade to take advantage of 64bit Windows and different platforms in the future.  As per Java, buying the hardware should become a decision based on hardware cost-effectiveness without restriction on the actual CPU type and vendor - though even with Java this didn't work for the first few years due to Java Virtual machine incompatibility problems between different hardware vendors.  

Garbage collection

Garbage collection is used instead of COM reference counting:

The .NET framework has a garbage collector, as per Java, whose job is to clean up objects which are no longer in use.  This is in contrast to the COM way of doing things which was to maintain a count of references to each object, and release the object when the count returned to zero.  This had the following problems:

• It was possible to bypass the COM reference counting mechanism, which meant that the reference count could be wrong, leading unpredictable behaviour or simply memory leaks as objects were not released when they should be.
• Circular references could easily prevent objects from being released, again leading to memory consumption:  eg object A has a reference to object B, but object B also has a reference to object A.  When object C releases its references to A and B, they cannot be removed from memory because they still have a reference count of one (they each hold a reference to each other).

The garbage collector solves these problems and is even capable of cleaning up circular object references.

A side effect of this change is that Destructors ( Terminate events in VB) may not be called when you expect (not called as soon as you release an object reference), so you may want to have an explicit Close method for objects currently do a lot of work in their destructor.

Object Oriented Features

• Inheritance - including inheritance of forms (!)
• Function Overloading (functions with the same name but different parameters)
• Parameterized Constructors  (Previously VB did not have the capability of taking arguments, which meant that objects had to be created uninitialised)

See below for more VB changes.

.NET framework libraries

With the upgrade to .NET, languages such as Visual Basic .NET will no longer be intrinsically inferior to Java in terms of the actual language and runtime features, the object oriented features and runtime architecture are indeed similar.

However, the power of a language also comes from the standard libraries supplied, and Java has been strong here from the beginning in its built in support for threading and sockets, and now even more so with the enterprise Java features.

With .NET, MS are supplying enhanced Server objects for Message Queuing, Scheduling, Exception handling, Event logging, Performance Counter, Directory Watcher and many more.
These are on top of the server objects already shipped in Windows2000 such as CDO for SMTP, ActiveDirectory objects, Disk Quota Management and many many more.

With Windows2000 Server and .NET libraries we are a step nearer the Object Oriented operating system envisaged by Redmond a number of years ago.

What, no COM?

COM is replaced by the new Common Language Runtime. [!!]

COM is the long-standing Microsoft mechanism for communication between programming objects, the Microsoft equivalent of CORBA.
It will still exist and CLR components will be able to use COM components (and possibly vice-versa!), for essential backwards compatibility.  However, CLR components will not use COM as their communication mechanism.  Even the new Windows2000 COM+ is replaced by functionality in the new .NET CLR.

Some of the reasons for this change are due to the fundamental architecture changes described above (Lessons from Java), garbage collection instead of reference counting and so on.  

CLR deployment improvement

The CLR eliminates many COM problems with regard to language interoperability, application deployment, and component versioning:  'COM has gained a reputation for being fragile and hard to deploy because it requires registry entries for things like ProgIDs, CLSIDs, IIDs, and type libraries.' (MSDN).   Instead, object references and vtables are resolved as part of the new Just-in-time compilation step.

This allows side-by-side deployment of different versions of the same component and drag and drop deployment (as per Java, no need to explicitly register components).  It is even possible to configure client components to be either tied to particular component versions or to automatically pick up the latest available version of a component.

This will solve a lot of development problems for component developers:  previously (currently) the COM insistence on an immutable interface based on a class id made rapid application development of component-based systems difficult since the component interfaces are constantly changing during this type of development.  Workarounds to resolve this (such as VB Binary Compatibility compilation) had their own problems since repeated compilation created long chains of interface forwarding in the registry (as effectively each compilation creates a new interface and maps the old interface onto the new one).

For more detail on this topic, see MSDN Magazine article.

Interoperability improvements

Interoperability is inherent to .NET since all languages compile to the same MSIL pseudocode.  Beneficial side-effects of this are:

• All languages share the same datatypes so complete compatibility between objects in different languages is guaranteed.
• A single IDE and debugger can debug multiple components in different languages
• All languages have the same object oriented features.
• No IDL:  the COM IDL is a separate and complex language which has caused problems for interoperability:  for example although all VB classes are native COM, VB is only capable of a small subset of COM:  C++ programmers create COM components which frequently contain features which VB is not capable of using.  The interface requirements for different types of components are complex and often not fulfilled properly - and because the interfaces are additions to the toolsets rather than inherent elements confusion arises.

Web Services

SOAP (Simple Object Access Protocol) is intended to become the vendor-neutral standard for doing Remote Procedure Calls over HTTP:  the idea is that by packaging up methods and results in XML, Servers can talk to each other in an independent language with no knowledge required of which operating system is being used on each server.  Bill Gates' vision here is for intelligent agents to collate information from different sources for the internet user. 

You can try out Web Services today with the SOAP toolkit for VisualStudio6:  this allows any COM interface to be exposed over HTTP  [with the restriction that only native COM datatypes can be used].  The configuration tool creates all the code required to expose an interface:  the request and the results are sent packaged as XML, however this is transparent to both client and server application if using the toolkit interfaces.  In the VS6 version there is a little client work to do to set up the call, .NET should be even more transparent.

WindowsDNA Upgrade Notes

The .NET internet solution is an upgrade of the main Windows DNA architecture, ie ASP for presentation, VB business objects.

ASP+

ASP is now compiled with fuller language features - once again, a step closer to Java and the currently superior JSP architecture.
Web Forms are an upgrade to the existing ASP design-time controls.  The idea is that all the code executes on the server, and browser-compatible code is generated - which may be a plain HTML3.2 compatible page for less capable browsers, or a page with client code functionality for Internet Explorer. 

How this actually works is as follows:

• When the form is transmitted to the client, for each visible form field and extra invisible field is transmitted with the additional runtime information about the status of the field (properties/attributes).
• When the form is submitted, the hidden fields are submitted as well so the framework can read the hidden field values and reconstruct an object model of the complete form status for manipulation by the ASP client code.

This incurs an overhead in the size of transmissions and a certain amount of server processing, but saves a lot on the actual programming side since the forms are no longer stateless and you no longer have to write your own code to keep track of the users status.  [And obviously the mechanism is not dependent on sessions, so no scalability problem to upgrade to a server farm.] 

Pocket Internet Browsers

With the Mobile Web forms library different mobile devices can be targeted from the same page (including WML for WAP devices and HTML3.2 for Pocket Internet Explorer on WindowsCE for example).  
This will be a lot easier to develop than the current best available mechanism - XML source, XSLT templates for each output language and XSL ISAPI filter to process client requests according to the client device type.  This mechanism has problems because some of the pecularities of HDML (Handheld Device Markup Language) and WML (Wireless Markup Language) are specifically invalid XML which has resulted in inelegant workarounds.

Visual Basic notes for .NET Future

Most of the features below are really features of the .NET common language runtime rather than VB itself, such as the object oriented features and modern (ie Java-like) language features:

• Object Oriented enhancments:  incuding inheritance, function overloading, parameterised constructors
• Free-Threading
• Structured Exception Handling (try.. catch.. finally)
• Static member data and functions (needed for inheritance) - so you can define methods on the base class that do not use instance data:  in VB this is via Shared keyword which equals the Static keyword in this context in C++, Java and C#.  (Static has two meanings in C++/Java so the invention of the Shared keyword clarifies this and keeps the existing meaning of the Static).
• Option Strict  for strict type checking: catches any type coercion which may cause problems
• ADO.NET enhancements to ADO for disconnected datasets and distributed environments

The IDE and debugger  is also language neutral, so multiple components written in different source code languages can be debugged from the same IDE.

Language Changes

The following features are dropped:

• DHTML Projects, WebClasses, ActiveX Documents (Project Types IIS Application, ActiveX Document Dll/Exe, DHTML Application).  These project types have already come under much criticism for scalability (WebClasses) and interoperability (ActiveX, DHTML) reasons.
• DDE
• Graphics commands for forms, line and shape controls.  These were all fairly poor anyway! Forms object model is also significantly changed including clipboard (new formats), drag-drop etc.
• VB Runtime DLLs  - now the Common Language Runtime, no VB specific runtimes required.

Data Type changes

Fundamental to the .NET interoperability are a common set of data types across all .NET languages.  These changes apply to VB:

• Integer datatype changes:  Long - 64bit (was 32bit), Integer - 32bit (was 16bit), Short 16bit.
• Date data type has changed internally: ensure Date data type is used not Double to avoid future problems
• Variant datatype dropped - now subsumed within 'object' type which can now contain instrinsic types + empty, null etc.  There is some confusion at the moment with Variants of type Object:  if they contain an object, the SET syntax is required to retrieve a reference, but if they don't, SET is illegal syntax.  With this move the SET keyword disappears and more subtly parameterless default properties are removed  [The reason for this is that it is not clear when client code is wanting to use a parameterless default property or a reference the object itself, eg myVariant = myObject].
• Boolean: TRUE is now 1 not -1.  For compatibility with C++ etc.  No problem if boolean data types are used.  Boolean and Bit logic is also changed with new functions bitand, bitor, bitnot, bitxor to avoid confusion with and/or/not logical functions which are now logical functions only.  This will cause problems with IF tests where values are and-ed together.
  Changed April 5 2001 for backwards compatibility. True values returned to other languages will appear as 1 but will appear as 1 internally.
• NULL:  null propagation not supported and many functions now return typed values only whereas previously they returned variants which could be null.
• Arrays are always Zero-based.  Option Base 1 syntax removed
  Restored for compatibility with previous VB codebase.
• As Any in API declarations is dropped, now you have to do a declaration for each type.
• Fixed-length Strings:  dropped for compatibility reasons - these were slow in any case, so it is better to allocate a string buffer if necessary than declare a string as fixed length.
• Pointer manipulation: VarPtr, VarPrtArray, VarPtrStringArray, ObjPtr, StrPtr and also LSET.  Although undocumented these are widely used for API reasons and eg high performance String and array manipulations and conversions:  it's not clear how these sort of functions will be converted, but an AddressOf operator will be available to use function addresses for callbacks.