2. Depends which version of the framework you are using. Compact Framework is more like programming raw Win32 because of limited framework features. Using the full .NET -- you can do tremendous amount of work without having to resort to interops. Basic SOAP services work in either version of the framework very well. Compact framework doesn't have crypto (but the underlying bits are in the raw OS).

3. Language neutrality: Absolutely. I have a variety of wrapper assemblies (in C# because of the ease of creating interops to either Win32 or other COM). I then derive classes from these in VB.NET and vice-versa. Lack of python/perl -- ask the python and perl guys. What it would require is porting these languages compilers and runtime to use .NET. Microsoft never said that it would be doing this. Besides, I'm guessing that most work is being done either to deploy richer ASP.NET sites and/or SOAP/XML. The ASP.NET stuff is very solid and I feel significantly "safer" than old school ASP pages.

4. urhh ... right. Guess we gotta wait for longhorn ;-(

5. The angle brackets are specific to your implementation language. I think they've done an incredible job with WSDL generation, parsing, proxy generation, etc.

6. Agree (jury's still out). Office 2003 requires MSHTML 5 which is not redistributable (as of yet). The universal canvas only works if you completely upgrade to 2003-based products (client and server). InfoPath = LotusNotes 4.x in terms of infrastructure required.

7. Interesting ... there isn't any silver bullet here. Why one would think you could have write-once deploy in radically different infrastructure is beyond my comprehension.

8. I'd some this up as "non-trivial uses of .NET". The framework and infrastructure are in place to provide the building blocks. In many regards this no different than OLE Controls (OCX/ActiveX of 10 -- yes, 10 -- years ago). That said, it's a lead by example approach and as soon as you have non-trivial combinations of components (for your private applications use), it's a non-trivial task to make these components live in the designer (which is what you need to have building blocks). Then, of course, is the entire obfuscation issue. It should not cost additional money & time to produce a version that can't be trivially reverse engineered.

9. I've built assemblies that work as is on Intel and StrongARM. Very cool. Checkout OpenNETCF for interesting examples, discussions, forums. The fact that OpenNETCF even exists shows that MS has been in many respects playing a marketing game. If they were serious they'd have done this themselves and would provide consistent, timely guidelines as to how to produce code that runs across various framework instances.

1) Yes (and a little no). The problem of "DLL Hell" as we knew it in the VB6/COM technology has been fixed with .NET assemblies - that is the "Yes" part. However, we have new problems in that the IDE does not provide seamless support for the more "advanced" versioning scenarios. I mean, there is a disconnect between the IDE, Global Assembly Cache, and installer technologies at this time.

ClickOnce deployment is not about "DLL Hell". ClickOnce deployment is an effort to make rich client application deployment and maintenance (auto updating, etc.) easier. "DLL Hell" was about the way the operating system and COM plumbing handled versioning, etc. of COM dlls. For example, with "DLL Hell" we would have a problem where by Windows/IIS would lock a .dll that is used in our ASP application. As a result, you would have to stop the web server, replace the file, and then start the web server.

2) Generally speaking, they've made great progress. My only complaint is that there are far too many parts of ADSI/LDAP that are not wrapped into System.DirectoryServices.

3) My experience has been that most people are not working under the scenario proposed by Jeff. Generally, there are more people picking a single language for dev work but there are also a substantial contingent that are doing presentation layer development with VB.NET and middleware development with C#.

I don't even understand what you are asking about Perl and/or Python. I mean, there are .NET compilers from ActiveState for both of those lanugages. Granted, ActiveState did a less than stellar job of implementing the compiler/technology but that is not on Microsoft.

4) Come on Jon, it is ridiculous to think that everything is written in managed code. I don't think the broad development community understand evidence based security and even many of those that understand it are not using it to its fullest potential (i.e. security, at the code level, is still a ball that is dropped in most corporate applications). That said, I'd say we are much better off because we are at least now working within a sandbox (the CLR) as opposed to working with only the permissions of the user.

I don't buy the machine.config being an additional complexity. In most cases, developers do not have to touch the machine.config file. Those who do are usually greatful that they have been given such granular control over the environment. I guess you have to understand the purpose of the machine.config - machine.config exists so that developers, admins, etc. have granular control over the .NET runtime. The machine.config does NOT exist to control Active Directory, NTFS, etc. I do NOT want Microsoft to put more in the machine.config file. The only request that I would make is that the machine.config also be configurable using a Microsoft Management Console (MMC) similar to IIS. I don't want the XML file to go away but a GUI on the front would be handy. There are 3rd party tools that provide a GUI frontend today but it would nice if Microsoft had one out of the box. =)

5) XML Web Services are not Services Oriented Archiecture. XML Web Services provide a very easy way for organizations to implement a Services Oriented Architecture from a technology perspective. Your comments seem to confuse that distinction. The goal posts have indeed moved and Microsoft (and other folks like IBM, etc.) have moved with them. The web services centric companies have created the Web Services Enhancements (WSE) and they have made very good progress on the capabilities of XML Web Services. Microsoft has certainly done its part in offering up brains, time, and then turning the support into very usable WSE APIs.

From what I saw at the PDC, Indigo will make take Microsoft's current messaging stack (XML Web Services, Remoting, and DCOM) and unite it into a single powerful and intuitive messaging API.

6) Well, as soon as you go to Office stuff I'm not sure you are doing a reality check on .NET. I guess this is something you will have to reconcile in your article - what are you calling .NET versus what your readers consider to be .NET. I personally see .NET as the development tools (VS.NET), the .NET Framework (and all it contains - CLR, etc.), XML Web Services, and the .NET Enterprise Servers. I'm a developer/architect so maybe that is just my role specific viewpoint.

7) I never believed nor was I told that it would be write once but it is worth noting the differences I suppose. I believe that a write once scenario can only be achieved if Microsoft has 100% control over the desktop (I know it is close but it is not 100%). In addition to my reluctance of a Microsoft monopoly, there are a variety of other scenario specific reasons that I DO NOT want a write once scenario (assuming that means there is no longer two seperate strategies like we have now).

8) Microsoft's perception as seen by many in the IT industry is the LARGEST block with software as a service. While I don't share the paranoia, many people in the IT industry are afraid of software as a service from Microsoft for a variety of reasons - security and percieved vendor lockin (this is a joke as all vendors want vendor lockin) generally top the list.

9) I can write an application that targets a PC browser, Mobile device browser, Pocket PC device, or Tablet PC with a *single* IDE in Visual Studio .NET. I'd say that is a massive improvement for developers who need to develop for many devices. Not only that, the ASP.NET pages, mobile ASP.NET pages, Comapact Framework WinForms, and Tablet PC WinForms can all use the same .NET business logic on the server - another vast improvement.

Does the Compact Framework encompass all of the functionality that is found in the .NET Framework? No. I'd argue that this is a valid trade off in the face of speed and memory management.

10) The .NET Alerts SDK is out there but it is not in wide use at this point. The Notification Services in SQL Server 2000 are a great piece of technology but are again not in wide use at this point. I think a lot of work is being done with the various .NET enterprise servers to make the PIM stuff much easier to develop - the functionality is not there today. Microsoft has a ways to go on this front but the problem will remain to be one of a business nature as they can definitely deliver from a technical perspective.

I guess in a way what I'm saying is that I disagree with much of my plea now that time has passed and I've learned more. However, I'm very pleased and excited at the responses I've gotten from you guys at Microsoft. I'm also excited at the dialog this has started. I have seen some very negative comment that has been spun off from my original post, but I neither agree with or support the stuff. I truly believe that this is evolutionary stuff, but when we don't yet have the vocabulary for understanding these upcoming advanced features, it's hard to understand it with what we have today.

Feedback? I'd say "keep up the awesome work!" I was excited about Microsoft development technologies back in 1996 when you had the "Activate the Internet" campaign. I haven't lost faith in you since then. If it weren't for the incredible work that Microsoft employees have done since then, I wouldn't have such a wonderfulo job and a great life. Kudos to you all.

I do like the one environment, whether or not my libraries are in the same solution or not. And I love the framework. I spent a year or so working with Java and at the time I wished that MS would do something like that. Don't forget, alot of what is in .Net came from working with customers and seeing what they were trying to do. Personally, if I had a client that wanted work done with the old ASP I would turn it down unless I couldn't put food on the table. But to each his own.

By the way, I think this is a great thread.

Regards, Paul Speranza

To your question, can you write a Windows NT service with VB6? How easy is that? Can you write mobile web applications that detect and render properly on over 500 devices using ASP? Can you write VB6 applications that don't require you to release the memory of your objects? Can you write fully object oriented VB6 applications? Can you turn page level caching on in your ASP pages? Can you deploy your VB6 applications by simply XCopying the files? Could you seamlessly debug across VB6 and C++6 projects and then into SQL Server?

I could come up with many more but I think you get the point. There are many things that you can do with .NET v1.x that you could not do (even if you could it would make no sense financially because of the difficulty) with ASP or VB6.

I am all for innovation and think that .Net has done a lot in this area, however, unless we focus more attention on customer(not software engineer) usability, productivity,etc we will be forever mired in this endless loop off incremental(at best) improvements.

Now this is not to say that .Net doesn't need improvement it does. And I agree right now after all the PDC hype it seems as if everyone has gone to Avalon this and Whidbey that. I would like to see more focus on .Net here and now not how templates will change my life. I'm already hating that I don't have them now, why does everybody with a blog at MS have to rub it in. I don't think it's Microsoft as a company that has moved on to "the next thing" it's just the fact that all the 'important' (or self-important <grin>) bloggers have moved on.

I think there are thousands of ISV developers out there building great applications on both the COM and .NET technologies now. I expect that we will see lots of innovative applications on the .NET platform in the next year or two (I mean we all know that there is a lag in the industry before the masses start using a technology).

I agree that the barrier to entry may be a bit higher and that might be a bad thing (I could argue this to not be a bad thing but I won't). I would say that the Office example is not a great one because the Office toolkit actually just wraps the Excel/Word COM dlls. I mean, you are simply calling .NET equivalent methods/objects for Excel and they look almost identical to the VB6 equivalent. I know what you are saying though and the barrier of entry has increased.

I agree that customer applications should be more innovative. I don't think this is on Microsoft however. Microsoft should be creating libraries and tools so WE (the developers) can make those great customer applications.

Before I piss off any more software engineering types, let me just say that if I put on my software engineer's hat(which, BTW is my day job), .Net is really cool and has made some things much easier (like the things in your example). The point (that I am obviously not making very well), is that the real benefit to end users and customers of all this new "stuff" is marginal at best and will continue to provide only incremental benefits, not dramatic breakthroughs in either customer/end user usefulness and or productivity.

Now, I think you would probably say that this is true in general but maybe the .NET tools, etc. have not gone far enough to make a major impact on end users. I suppose that is possible but I think there are definitely cases in which end users have benefited greatly from some new features, an application that could be written because time was saved elsewhere, improved uptime or performance on a slow system.

Regards, Paul Speranza

Second, many of the great applications are not applications that are applicable and/or used by every consumer on earth. I work in the midwest and I know of some great .NET applications that have been written for the manufacturing industry (plant floor applications, etc.).

Third, I didn't say there were any "radical breakthroughs for the end user/customer". My point was that the better the tools/technology gets the quicker to market, better performance, and more useable the applications will be for end users. I think that there are definitely pieces of .NET v1.x that make development faster (think unified IDE for multi-device development, think Mobile Internet Toolkit that enables web application development capable of targeting hundreds of different devices with little effort, think about the various other IDE enhancements that make the developer's life easier) and better performance (think output caching for ASP.NET, think threaded programming for VB development - the application may not be faster but it can appear that way to the user, think compiled ASP.NET applications, etc.).

Yes, the benefits are incremental to the end user. I do think there have been pretty significant productivity gains but I think it will take a year or two for most development shops to realize the gains. Of course, if you read anything about .NET and did even cursory proofing then you knew that .NET was an incremental improvement when it was in beta.

I know how this goes, most people want to focus on what is not there. The improvements over the previous technology are rarely touted as major improvements. Of course, no one takes into consideration the fact that maybe the technology wasn't all that bad to begin with. In the end, major improvements have required a rewrite of the underlying engines and that proved to be a bigger task than Microsoft originally thought (think Longhorn).

One thing you should add in your article Jon is the effect that .NET has had on the concept of community and open source for Microsoft developers. I think that Microsoft developers are going to benefit from the many great open source projects that have cropped up as a result of the more reusable and framework oriented .NET. The entire nXXX line of tools (nant, nunit, nperf, ndoc, etc.) should be in all .NET developers toolbox. I don't believe any of these great tools would exist for Microsoft developers today had .NET not been released.

My last thoughts on the subject, I agree that .NET is not a super major innovation that has had ripples throughout the entire computing environment. I believe that .NET is a nice improvement over existing technologies and that it is a first version product. The difference between first version and later versions of most software is pretty significant so I'm looking forward to the future.

Issues exist in JScript.NET (see http://www.csharp-station.com/Chapters/JScript.NETProgramming.htm on Strong Typing JScript) and have hampered ActiveState's work on Perl.NET and Python.NET. ActiveState have their whitepaper on Python.NET here: http://www.activestate.com/Initiatives/NET/Python_for_.NET_whitepaper.pdf which talks the problems they had.

The Iron Python implementation has turned some heads (http://primates.ximian.com/~miguel/ironpython) but not everyone is so sure (http://www.edwardbear.org/serendipity/index.php?serendipity%5Bpage%5D=2).

As to why languages like Perl and Python are important: http://www.tallent.us/PermaLink.aspx?guid=26305528-70eb-42c2-822d-c11c1a24185a

Today it's a choice between language "X".NET and language "Almost-Like-X".NET (C# and VB.NET) to which you have to wonder what was the point, other than as an appeal to Microsofts existing VB crowd to give .NET a try?

Neither C# or VB.NET has convincing "edge" over the other and can be equally applied to most problems. Can imagine having to make a choice is a deterant to using .NET and implies additional costs / effort training developers in both. Better would be a single workhorse language (C#) and a range of special purpose languages designed to make specific problems easier to solve (as with JSTL-EL for example) or allow alternative design paradigms (e.g. Python).

At the end of the day, my point is this ... if we(Microsoft and other Software Vendors) spent even a fraction of the time and effort rethinking the way software is designed and developed instead of re-implementing the same old ideas, we WOULD see dramatic breakthroughs at the end-user/customer level.

3. Well, I think it works because I'm not concerned about which language the .net library is written in and I use it in both vb.net and C#. I've also been able to reuse my .net framework experience/knowledge on multiple projects, letting the client CHOOSE the language. But mixed languages - very rare (excluding using 3rd party components)

4. Seems up to par to java.

5. I think .net has kept up here. The questions is, have developers?

6. IMO, this is more of a MS company-wide goal, then a .net one (big difference).

7. Was this ever a goal? I'm not sure if these could be implemented in a write-once scenario. Each has completely different issues and considerations involved. Even if it was done, the results would be a watered-down compromise between the two, leveraging none of the benefits of either one.

8. Again, this is more of a MS company-wide goal. But I like what I see coming out of MapPoint, Google, amazon, etc.

9. Not familiar.

10. Sounds like a marketing speech gone awry. At one point, every marketing exec used the .net label, so that didn't help.

So if one-click deployement in Whidbey works reasonably well, then I think Java client will really be on the decline. Perhaps even Flash will face a real threat. I don't expect one-click to be perfect but it just has to be better than the alternatives & frankly, that just won't be that hard - Java Webstart still has too many quirks & Flash lacks complete native application integration.

And yes, the C# support of Web Services & XML, frankly rocks. It's not that hard to do either in Java, but C# makes it alot easier by default (in particular writing XML & making asynchronous client web services).

In terms of an overall software as services strategy - well, the world has to want to move to that model. I think this will always remain a niche but it could be a profitable & exciting niche - ala Amazon's Web Services. MS could do more here in particular by making some of their existing services like the Map and Notification services cheaper. But that expense maybe a way to help limit the utilization. This could be an area open-source could tackle - distributed services that were useful - for example a global notification service (the MS notification service allows you to register for 'events' that are published by service providers & then those events are sent to you via a number of different types of media -- of course MS drivern like Messenger & MSN mail) competitor that used nodes of systems out there to distribute the load instead of concentrating in a single point (but hopefully without going through the mind-bending stress of the business orchestration protocols that most mortals will never read about or even use).

Finally in terms of configuration complexity - it's there. I'm not sure how or if it will ever be solved. Ideally all of the general property based stuff would end up in Active Directory (but I have a natural bias to LDAP :)). But developers hate writing configuration code in the first place so I can't see it moving short of a directive from Bill backed up with armed enforcers :).

We are still awaiting good support for an efficent dynamic language with a complete set of interactive development tools.