Google Answers Logo
View Question
Q: Microsoft .NET technology ( Answered 5 out of 5 stars,   2 Comments )
Subject: Microsoft .NET technology
Category: Computers > Programming
Asked by: jim2003-ga
List Price: $30.00
Posted: 26 May 2003 16:29 PDT
Expires: 25 Jun 2003 16:29 PDT
Question ID: 209092
What is the .NET technology? I am a power user of Access and Excel,
competent at a low level at Visual Basic; understand the basics of
Application Server technology; understand the basics of Microsoft
Exchange Server; have created Data Access pages in Access. Yet I have
no clue what .NET is. Can you enlighten me.

Request for Question Clarification by mathtalk-ga on 02 Jun 2003 22:11 PDT
Hi, jim2003-ga:

A few days back I posted the comment below in response to your
question, as clarified by your interaction with jbf777-ga.  If you
have still an interest in learning more about design philosophy behind
Microsoft's .Net technology, I'd appreciate hearing from you.

Thanks in advance, 

Clarification of Question by jim2003-ga on 03 Jun 2003 05:10 PDT
OK. This has been helpful. Sounds like I am not the only one confused
by this term. If you will give me one or two vivid 'for instances'
about how a layman might use .Net, I will accept that and close the
question. Thanks for staying with me.

Subject: Re: Microsoft .NET technology
Answered By: mathtalk-ga on 06 Jun 2003 08:20 PDT
Rated:5 out of 5 stars
Hi, jim2003-ga:

Just in Time Compilation

To a "simple" end-user perhaps the most compelling benefit of .Net
technology is the JIT compilation.  This allows Microsoft to "migrate"
an application from one hardware platform to the next in a uniform and
transparent manner.

Although .Net applications still appear to be packaged as .exe and
.dll files, as Windows programs have from the 16-bit days, under the
hood there is something very novel.  The typical "end-user" code that
is supplied is actually in Common Intermediary Language (CIL or more
often simple IL), which is compiled (just in time) upon the first
invocation of a program or library (and the results of the compilation
saved into a new "assembly cache" so that it will in all probability
only be compiled once per session).

Therefore next year when you get that 64-bit Windows system we've all
been dreaming about, old .Net applications will not need to be
specifically upgraded by their vendors.  The migration from 16-bit
Windows to 32-bit Windows was quite a hassle, by comparison.  Example:
 I'd supplied a 16-bit DLL to a client who distributed it to employees
to use with an Excel spreadsheet for modeling retirement benefits. 
When it came time to migrate to a 32-bit version of Windows and hence
of Excel, the whole ballgame had changed.  Not so with .Net
applications; the 64-bit implementation of the .Net common runtime
should simply pick up the IL distributables and go with them,
transparently handling all the recompilation and linking issues to
take advantage of new processor instructions and any new runtime


Although Microsoft's main focus with the Common Intermediary Language
was language interoperability, rather than cross-platform portability,
who looks a gift horse in the mouth?

A couple of notes about this JIT compilation/IL assembly approach. 
Long time users will recall that Pascal and some other language
systems supported "cross platform portability" by providing
distributables in p-code, an approach not unlike that taken by Sun
Microsystem's Java.  One issue there, however, was performance,
because the "intermediate" code was interpreted, not compiled by the
p-code engine (or Java virtual machine).  Here Microsoft avoids the
performance issue and even turns the situation to some advantage (the
one-time compilations per session and caching seem to have benign
performance penalties).

A related issue is the ease with which a "high level" language like IL
might be subject to decompilation attacks, where a proprietary
implementation is at stake.  To handle this Microsoft offers an option
for tough encryption of the IL code.   I've not worked with the
encryption mechanism myself, so I don't have any first-hand knowledge
of how well or easily it applies, but presumably this is key to
obtaining commercial vendor buy-in for the .Net platforms.

One more comment about IL:  it's not a standard set in stone. 
Although we may expect any extensions to IL (or more properly, CIL) to
be conservative (in the sense of forward compatibility), new .Net
languages will almost certainly require such extensions.  One of my
first questions to Microsoft was whether any of the .Net languages
would support coroutines.  That ability, which is a big convenience in
implementing AI-like very high level languages, is not supported in
the existing IL standard.  See here, however, for proposed extensions
to IL for supporting functional languages like Haskell:

[ILX: Extending the .NET Common IL for Functional Language

Ubiquitous XML

For the power-user such as yourself I expect the most important
implication of the .Net technology will be the degree to which XML
documents and interfaces which rely on related standardization become

XML has become a raging fashion in data manipulation applications of
all sorts.  I have an essay I could tack on, if you are interested, in
Microsoft's proposed use of XML in data mining tools, and of course
the SQL Server 2000 support for XML is substantial even if not yet
built down to the DTS level.

But it is within the Microsoft Office suite that the most rapid
incorporation of XML standards have taken place.  Beyond viewing an
XML document with your IE browser, you can now open such documents in
Excel or Word.  For an example of using Access 2002 to import and
export XML documents, see here:

[XML in Office XP: Part II]

Since Microsoft was one of the key contibutors to the development of
the XSD (XML Schema document) approach to XML validation, they have
naturally been quick to support the "Schema" approach in Office tools
(as well as in the underlying DOM parser engine, MSXML).

Here's a more updated article on the use of XML in Access, to simplify
dynamic linking of tables:

[Put XML to Use in Access XP By Danny Lesandrini]


Although XML itself has achieved widespread adoption quite
independently of the .Net technology, Microsoft is both lowering the
bar to using SOAP and other XML related protocols with their VS.Net
tools _and_ making an intentioned effort to promote the use of XML
within such tools for documentation of interfaces.

If you've enjoyed the (increasingly reliable) use of Intellisense
technology (to pick out the correct syntax for object declarations and
method calls), the kicker with .Net tools is that your own interfaces
(and not just Microsoft's system interfaces) can now become
incorporated in the Intellisense "help" through the magic of XML
documentation that you are prompted to supply as you develop your own
.Net classes and methods.

For explanations of how this works, see here:

[XML Documentation Tool]

[XSLT Transformations and XSLT Intellisense within the .NET IDE]

regards, mathtalk-ga

Request for Answer Clarification by jim2003-ga on 06 Jun 2003 19:11 PDT
I cannot tell who is answering what. I'd like to withdraw the question.

Clarification of Answer by mathtalk-ga on 06 Jun 2003 20:40 PDT
Hi, Jim:

I see in your "request for clarification" that you are uncertain "who
is answering what" and that you'd "like to withdraw the question".

First, note that this second answer was submitted by me, subsequent to
the Clarification of Question you posted up top for me to do so. 
Recall that, after reading my comment, you asked that I give one or
two "for instances" about how a layman might use .Net.

I response I have discussed:

1) How .Net benefits a "simple" end-user, who benefits passively from
.Net technology (because of how it works behind the scenes).  For
instance, you might upgrade your computer from 32-bits to 64-bits, and
the .Net applications would continue working, taking advantage of the
new processing instructions, without any vendor-supplied upgrades.

2) How .Net benefits a "power" user like yourself, who may work with
Access data pages and other MS Office suite products (including
limited amounts of VB programming to support those activities).  For
instance you might work with XML documents directly in your Access
databases or Excel workbooks.

Your request to "withdraw" the question thus has me a bit confused.  I
feel I've taken a very conservative approach to answering your
question.  If there is something about my answer that you would like
to have clarified, I would be happy to do this.

The procedure for requesting a refund for a question to which you did
not receive a satisfactory reply is described here, near the bottom of
the page:

The directions there explain what information will be required to
process a refund request.

I sincerely hope that there is something which I can clarify for you
to make my answer acceptable.  If not, I hope that the Google Answers
experience has been beneficial for you in spite of the unsatisfactory
nature of the two answers posted (first by jbf777-ga and then by

best wishes, mathtalk-ga
jim2003-ga rated this answer:5 out of 5 stars

Subject: Re: Microsoft .NET technology
From: jbf777-ga on 28 May 2003 19:01 PDT
NOTE: My original answer to this question will be removed.  Because
the customer's clarification will also be removed, I'm posting it as a
comment.  The customer is not looking for links to information.  He
wants a summary from someone directly knowledgeable of the topic that
is "not in layman's terms and not in ultra-tech terms."
Subject: Re: Microsoft .NET technology
From: mathtalk-ga on 29 May 2003 13:38 PDT
Hi, jim2003-ga:

While I've worked with .Net on the programming side (and have abundant
documentation, source files, MSDN stuff etc.), I think the first
answer I'd give would be "a marketing term".

In fact Microsoft recently removed the .Net appellation from their
newest line of server operating systems (instead of Windows .Net
Server, it will be something more prosaic like Windows Server 2003)
because the conflicting uses as a marketing term were generating major

Even if you try to subtract out "marketing" abuse of the term, there
are a number of coordinated but essentially distinct technical
"campaigns" which are marching forth under the .Net banner.  I will
describe five of these "movements":

 - Position for rapid development of multi-tier "cooperative
processing" applications that use "Web services" via the SOAP protocol
and related standards.  [This probably comes closest to justifying the
.Net moniker, but its also something of a "whole cloth" activity given
the limited availability of Web service aggregators like Biztalk. 
Still, it's a stake in the ground.]

 - Ubiquitous use of XML.  [XML is central to SOAP, but Microsoft is
going much further than this in incorporating XML into the various
product lines.  The Office suite, including Access and Word, has
native XML support starting with the XP rollout and expanding through
Office 2002.  On the code development side the Visual Studio .Net
environment tries to automate the collection of documentation using
XML as a medium.  Naturally XML is making waves on the database side,
and is central to Microsofts data analysis tools.  More examples could
be given...]

 - Moving AWAY from COM.  [Microsoft's core development strategy over
the past several releases of Visual Studio, Office VBA, and MDAC has
been heavily invested in COM (formerly tagged as OLE and ActiveX). 
Now the lessons learned from "experimentation" with DCOM (Distributed
COM) have convinced the brain trust at Microsoft that there's
something of a deadend there, though for marketing reasons it will not
likely be stated quite this way.  COM works fine on the local
platform, but it depends heavily on the registry and on programmer
diligence even there, so Microsoft is taking a new tack.]

 - XCOPY deployment (of applications).  [If you are an old DOS
aficianado, then you may recognize XCOPY as a command for copy
directory structures faithfully (as opposed to copying single files
and fixing up the directory structures as you go).  The .Net
architecture is design, at least for applications making use of
"privately" purposed libraries, to allow these to be implemented by
doing a directory copy, i.e. without requiring the intervention of
registry lookups (which are part and parcel of the COM architecture,
with GUIDs for every interface and object class).  To do this .Net
introduces a new concept (assemblies, not directly related to
assembler language) and a new mechanism (the assembly cache), which
bring in their train some additional advantages (such as Just In Time
Compilation, don't ask; or ask, but I'll need to post a real answer to
get into it).]

 - A new common runtime library to unite all languages in a
programmer's heaven of interoperability.  [The premise is that .Net
programming languages can be implemented to share a common runtime AND
to be able to call code from one language's library to another with
few restrictions.  Also the .Net runtime is able to ensure a high
degree of code safety at modest performance cost, esp. tight
management of heap memory.  This comes at the expense of some powerful
language features (like pointers in C/C++), but seems to address real
issues with difficult to find memory leaks, esp. in connection with
COM objects.]

In short any confusion you have about the "meaning" of .Net technology
is quite understandable.  As a marketing term it is designed to mean
almost anything the potential customer believes is good.  But in
fairness Microsoft spent a very long period of time (the VS6 era, I
like to call it) rethinking the desktop platform and its emergence
into the Web world, and their labors have produced some pretty
compelling innovations.

If you are interested in knowing more about some or all of these
threads, please advise me and I'll be happy to post an answer in

regards, mathtalk-ga

Important Disclaimer: Answers and comments provided on Google Answers are general information, and are not intended to substitute for informed professional medical, psychiatric, psychological, tax, legal, investment, accounting, or other professional advice. Google does not endorse, and expressly disclaims liability for any product, manufacturer, distributor, service or service provider mentioned or any opinion expressed in answers or comments. Please read carefully the Google Answers Terms of Service.

If you feel that you have found inappropriate content, please let us know by emailing us at with the question ID listed above. Thank you.
Search Google Answers for
Google Answers  

Google Home - Answers FAQ - Terms of Service - Privacy Policy