Microsoft Dot Net

While describing DotNet to InformationWeek? in Feb2002, Bill Gates said these of MicrosoftDotNet

see all this in http://www.informationweek.com/shared/printableArticle.jhtml?articleID=6500999

MicrosoftDotNet is the flagship platform from MicrosoftCorporation. MicrosoftIndigo and related projects are being marketed as MicrosoftDotNet version 3 in MicrosoftWindowsVista?.

Note exceptions to afore stated views in a subsequent section, or maybe in a new page?

The Intel based proprietary operating system has captured over 90% of all desktop computing market. The computing giant, MicrosoftCorporation, crafted MicrosoftDotNet platform over this installed base and has directed its efforts to enabling technologies (e.g. IPV6), products (e.g. mobile devices), processes (e.g. ServiceOrientedArchitecture), legacy application integration (e.g. to BigBlue). See PatentedDotNet

The .NET framework is comprised of the following:

DotNet recent developments

Aug 04 news of WindowsXp SP2 problems & workarounds for DotNet listed by MS

In June 04 MicrosoftExpress, a set of lightweight entry point products, was announced and betas made available

In March 2004 saw this Microsoft roadmap

Source at http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx

Not for Windows Only?

See DotNetForLinux and MonoProject.

See http://www.go-mono.com for an opensource and portable implementation, or http://download.microsoft.com/download/.netframesdk/CLI3/1.0/WXP/EN-US/sscli_20021101.tgz and http://download.microsoft.com/download/.netframesdk/CLI3/1.0/WXP/EN-US/sscli_ref_20021101.tgz for a shared-source implementation (from Microsoft!) that runs on Windows and FreeBSD. (updated the link on 17 October 2003)

A different perspective on the topic

Here in Austria we have a saying that "someone is believing in hot ice-cream" when someone believes in things that just don't go together technically. Please note the careful wording of the speech, which avoids to tell anything about the server side. .NET is a heavyweight technology that will not "just run" everywhere. There is a large gray zone between a simple HTML-like access of a protocol from the client side to a fully supported .NET on the server side. -- HelmutLeitner

The CLR (VM) is like a virtual processor executing its machine (byte, word) codes. Talking about its portability is of no significance at all. Everything important is in the libraries. They can't be independent, because someone has to do all the system related stuff. Some months ago there was no support for Win98, now I read (following your links) that there are restrictions with respect to web development and server components. I really don't know what this means. I think that C# is an important improvement (has learned a lot from Java problems) and I will try it as soon as I have a chance to, but I won't if Win9x systems aren't fully supported. The question of lightweight vs heavyweight depends on how MS handles .NET: it may force customers on upgrade paths and it may offer portability with hidden traps and obstacles. This is what I meant by 'heavyweight'. -- HelmutLeitner

I think what you guys were talking about was... Did Ballmer say .NET would be running on Linux or not? And clearly he did not. Look, if MS was announcing .NET on Linux, it would have to be more clear than that, eh? From my angle, it sounds as if he is saying that WebServices developed using .NET would be consumable from Linux. But it's just CEO-speak, there's no detail, so we don't know. HL is right. It doesn't mean .NET won't be available on Linux, it only means Ballmer didn't commit to anything. -- DinoChiesa, 8 May 2001

MicrosoftDotNet and the SUN

The key moment when Microsoft and Sun fell out over Java and the very valuable possibility of decent Java COM integration was lost is well worth mulling over on Wiki, in my view. -- RichardDrake; feelings shared by StephanHouben

I work at Sun. It is specifically my job to integrate Java and COM (see http://developer.java.sun.com/developer/earlyAccess/j2eecas/ for some first steps in that direction). The full name of the thing is JavaTwoEnterpriseEditionClientAccessServicesComBridge or JcasComBridge for short. -- PhilGoodwin

There's a (now unsupported) list of .NET resources of various sorts on the DevX website: http://archive.devx.com/dotnet/resources/.

Many introductory books on MicrosoftDotNet exist.

DotNet is serious Business

What I don't understand about DotNet is how MS is going to make money. If it's all open and cross platform, doesn't that take revenue away from Windows sales and open the door to serious competition in the tools arena? Why are they doing this and what do they expect to gain? I have to admit that I'm still looking for the snag or the lock-in. -- some guy

People also asked how Sun could make money from Java when they gave it away for free. I think the basic answer is that if you provide some way to make it easier for people to develop software for your systems, you sell more systems. Your competitors may sell more systems too, but so what? Microsoft's well-tuned .NET implementation on Windows servers with SqlServer, BackOffice?, and all that other MS stuff, along with support for legacy Windows apps as well, will always be more attractive to some than a free mostly-compatible version for some other operating system, so they will sell more Windows licenses. They can get more revenue for development tools and training materials. They may grab some mindshare from Java developers who are using Java on Windows systems just to avoid the Win32 API, MFC, and Visual Basic. I don't think .NET brings any snag or lock-in, but it strengthens the lock-in they already have. -- KrisJohnson

Microsoft currently has over 95% of OS market that is not DotNet. It cannot grow much anymore. However if the 95% current OS market is obsolete (think of it like DOS before days of Windows) then Microsoft has huge room to grow, to get people to move from prehistoric architecture to the TrustworthyComputing ServiceOrientedArchitecture that is branded as MicrosoftDotNet. --dl

Microsoft.NET history

MicrosoftDotNet was announced in alpha form at the MicroSoft PDC, in July 2000. MicrosoftDotNet replaces the terms NextGenerationWindowsServices and the COM+ 2 runtime. Basically, Microsoft's announcement is quite large. They propose to replace COM and proprietary Windows calls with a cross-platform way of creating WebServices using Internet standards like XML, SOAP, and HTML. The CommonLanguageRuntime can run on any OS or machine.

CuttingEdge? DotNet

CsharpLanguage will someday become CeeOmega [based on 83.146.13.12 information]

InformationSecurity concerns for MicrosoftDotNet

A 2001 article, Building a Secure .NET infrastructure, is a good starting point. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kmag01/html/securenet.asp

Security Through the Lifetime of a Managed Process: Fitting It All Together excerpt from book ".NET framework Security" at http://searchwebservices.techtarget.com/content/0,290959,sid26_gci856076,00.html

Security Enhancements in the .NET Framework 2.0 at http://msdn.microsoft.com/msdnmag/issues/05/01/SecurityBriefs/default.aspx

A one page summary available as KB 330246 Full guide/roadmap at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp

====

What about MicrosoftSecurity for DotNet and its implications? I'm really concerned by the complexity (one might say Byzantine complexity) of the system: you have ActiveX style certificates, Java-style code validators, and a whole spectrum of rights an applet can possess. Even if it's technically feasible, it's going to be much harder for end-users and developers to understand how all the interlocking rights interact, and the consequences of privilege boosting are pretty dire. -- PeterdaSilva

DotNet and Xml

An introduction to the more important Xml classes in DotNet is located at http://www.informit.com/articles/printerfriendly.asp?p=170916

IsDotNetInnovative? WhyAnotherComponentTechnology???

See also: CommonLanguageRuntime, DotNetEcmaProcess, NetworkPublishing, WebServices, DotNetAsDistributedObjectSystem

Exceptions to views expressed regarding the importance of WindowsLonghorn and MicrosoftIndigo to defining what is MicrosoftDotNet moved here (last discussed in 2004)

[[This is inaccurate. WindowsLonghorn will not "take over" MicrosoftDotNet, the language platform. WindowsLonghorn will be based on MicrosoftDotNet. The statement above makes it seem as though MicrosoftDotNet was intended to have a brief lifespan, which is inaccurate.

This confusion arises from the extremely poorly-conceived name ".Net", which means different things in different contexts. The other meaning of MicrosoftDotNet - a distributed service platform - is a different story. -- arlied]]

When I wrote the first paragraph in this section I meant MicrosoftIndigo will be the next version of DotNet, if the company still choose to call it that. MicrosoftIndigo will be far different from DotNet of today, which relies on the now legacy ComponentObjectModel, through ComInterOp, for transaction processing and the like. -- dl

Indigo is just a communications infrastructure. The core of DotNet is the CommonLanguageRuntime and the DotNetBaseClassLibraries, which have nothing to do with Indigo whatsoever. The things Indigo will obsolete are DotNetRemoting and the current WebServices classes. -- 212.158.251.129

As an application developer, I would have to be prepared to rewrite any WebServices application using MicrosoftDotNet provisions of 2004, once MicrosoftIndigo is sufficiently defined. So whatever way we call it (changed or enhanced), there is going to be significant work in re-implementation. Also bear in mind MicrosoftCorporation is still learning what it takes to implement TrustworthyComputing to the point customers become confident about conducting transactions and business services across organisation boundaries.

Not exactly. The old WebServices architecture will still be there (if you can credit MicroSoft for anything, you have to admit they do an incredible job of preserving backwards-compatibility), and your old apps using it will continue to work perfectly well. And DotNet is about significantly more than just WebServices (although given the muddled marketing a few years ago, it's easy to see how misconceptions can arise), and in the WindowsLonghorn timeframe, even more focus is going to be put on client-side development. The DotNet platform (which I would define as the runtime and base class libraries) isn't going anywhere, any more than Java went away when Swing replaced AWT. Having said that, if you're focussed on WebServices, then yes, it is a fairly major upheaval, but if you look at the system as a whole, though, it's just another new API. -- MikeRoome

See MicrosoftIndigo and WindowsLonghorn for non WebServices related changes.

API or not, it will wag the DotNet dog in many ways as the argument is for customers to move to implementing ServiceOrientedArchitecture using MicrosoftIndigo and other WindowsLonghorn features (todays DotNet would not do it). -- dl

Also refer MicrosoftDotNetDiscussions

DotNet Information Sharing

One of the most basic questions about HailStorm relates to access: who will be able to access HailStorm services? (And more pointedly: will a Microsoft runtime be required?)

HailStorm can be accessed from any device, service or application with an Internet connection, the ability to identify a user, and the ability to send and receive SOAP messages. All interactions are text-based SOAP messages regardless of underlying platform, operating system, object model, programming language, application or network provider. HailStorm is accessible from both clients and servers, and no Microsoft runtime is required on either the client or the server. Microsoft has already demonstrated HailStorm services being accessed from a Linux machine, a Macintosh, and a Palm Pilot.

What if I don't need to write a web service? What if I just need to write an application? Does .NET help or hinder me? (or neither?)

Helps, in my view. A decent class library, automatic memory management, less Win32 warts and a large choice of languages

Agree. Using C# to develop GUIs and console apps lets one do the kinds of things that are easy with VisualBasic, but without the horrible language. Every once in a while, I find something missing, but it is easy to call Win32 APIs or COM objects to fill in those voids. If you like Java, but need better integration with the Windows world, then you'll probably like C# and .NET.

I hear someone from Microsoft is recommending new developers to use this http://www.4guysfromrolla.com/. What do people here think of this particular site, compared to the hundreds of others around (e.g. codeproject, gotdotnet, etc.)? -- dl

More than one person noted in 2005 that MicrosoftUnix is having a high profile presence in "Linux Today". Hopefully WindowsServerTwoThousandThree and its descendants will not run on high powered Unix boxes (BigBlue has a few) too quickly, to leave room for innovation.

Language Integrated Queries (LINQ) is something I am having trouble getting my head around. EmbeddedSql was something I remember as not having worked out so well in the 70s but now it seems to be a very important part of the new version of MicrosoftDotNet. There are some clever extensions to the language involving anonymous delegates and type inference associated with LINQ, but I don't understand what has changed in the programming landscape to make it a good idea to once more introduce EmbeddedSql into a mainstream language. What am I missing? -- SkipSailors

Well, there is a difference, first, LINQ is not SQL, SQL should be standard, but the fact is that you can not be 100% sure that a particular SQL sentence will work in all databases, but with LINQ, custom mappers can be built, and thanks to them the exact same LINQ sentence can be used for any of the supported databases (and support can be added by third party developers for particular databases, or even for OSQL languages (like HiberNate HSQL). Another difference is that LINQ can be extended to be used as a query language for XML files, CSV files, or even in memory structures (Arrays, LinkedLists?, HashMaps?) and therefore gives you the ability to "query" semi-declaratively memory structures that normaly can only be processed with procedural code... what is the advantage? well, with traditional control structures, if you are looking for a Person object in an array of Persons, you have to loop from start to finish, object by object, wasting the potential optimizations that current multi-core computers could offer, but with LINQ you can specify that you want all the Person object that match with a particular condition and LINQ will be able to use the best possible strategy to do the search (parallel processing, indexing, etc, etc) that effectively brings the advantages of optimized query processing in to in memory operations (finally we have a language that transparently takes advantage of the benefits of NimbleDatabases?, and it doest it even for simple collection structures)

I suspect its partly due to holdout fans (like me) of "data-oriented languages" (such as ExBase, Paradox, and FoxPro) where DB-like collection-orientation was built right into the language. Going through an OOP API for such is a pain compared to having it built in and us data fans miss the more direct "older" way. MS has a habit of dumping just about every paradigm/flavor into a tool in order to capture a wide audience; and perhaps to stay ahead of the open-source clones by out-featuring them. But it creates a monster. They will do to the new VB what they did to the old one: clutter it up over time by extending onto an outdated language platform. (And Windows too for that matter. It's the MS way.) --top

CategoryDotNet CategoryMicrosoft CategoryEnterpriseComputingConcerns

EditText of this page (last edited April 10, 2012) or FindPage with title or text search