February 2004 - Posts
This item is now out of date and no longer maintained.
Whidbey is the codename for Visual Studio 2005 and the next release of the .NET Framework (2.0). Yukon is the codename for the next release of SQL Server - SQL Server 2005.
Longhorn is the codename for the next major Windows release.
Changes since the last update are indicated in red
- Whidbey/Visual Studio 2005
- Whidbey/VS 2005 Beta 2 with "Go Live" license - Late March/Early April 2005 [2, 4]
- Whidbey/VS 2005
RTM Release Candidate first half mid 2005 September 2005 [2, 4]
- Longhorn - now without WinFS, Avalon, Indigo 
- First Longhorn Beta -
February 16 June 2005 
- Longhorn (Desktop) -
May 22, 2006 2nd-half 2006 - w/o WinFS, Avalon, Indigo 
- Longhorn Server - 2007 
If you use Visio for UML, Pavel Hruby has a useful collection of
interpretation free Visio UML stencils.
Using them, you can concentrate on a pure diagram and not semantics or
Roy Osherove has written an interesting article on scripting in .NET, but it should be mentioned that there are issues that prevent you implementing a modern .NET integrated scripting solution within your application ...
Directions on Microsoft have some useful articles and resources available online e.g. ...
Microsoft Business Solutions Roadmap 2004 (Article)
Windows OS Roadmap Stretched (Article)
See here for additional sample content.
Update: MBS readmap? see also this ZDNet article
It's an all too common response to the question of using .NET code.
I can't guarantee clients will have .NET installed (actually I can pretty much guarantee they won't)
Exactly why the .NET Redistributable and it's prerequisites couldn't have been released in a service pack for the various MS platforms is beyond me. How successful will ClickOnce be if code can't run on most clients? No-touch deployment has to-date largely failed NOT JUST because you have to touch it first (change the security policy to do anything of consequence), but also because most clients don't have .NET installed anyway.
Update: dare we hope that it might be included in XP Reloaded?
Update: September 2004 - 6 months later - no luck.Microsoft just don't seem to even see it as a real problem - check out this post by Brad Abrams of Microsoft
Can Sun Java Studio Creator (formerly Project Rave) tempt Windows platform developers?
When Project Rave was announced, it was perceived as a challenger for both the WebMatrix marketplace - and potentially for the millions of VB6 users questioning the cost and merits of .NET as a technology and development platform. Sun promised an easy to use visual development environment based on the Java language - a Delphi/Visual Basic type RAD experience.
Particularly at stake are non-professional/casual/education users - a market sector many times larger than professional users. Professional users tend to have either informed or religious views as to the platform and tools they use, others tend to be more flexible and transient. But those flexible, transient users often become tomorrow's professional, and an influence on technology decisions.
If Sun could bring a complete, easy to use and deploy product to market it would surely achieve considerable market share, and bring more than a few sleepless nights to many at Microsoft.
Aiding Sun's bid has been Microsoft's fumbling of .NET's market positioning statement. Ask most people what Java is and they can normally give you an answer - more than likely you'll eventually hear "runtime". But the same isn't the case for .NET. In Microsoft's haste to convey that .NET is "all things to all people", they manage to convey confusion.
Also aiding Sun is the issue of deployment. .NET is mature and is heading towards its third public release this year (2004), yet few systems in the field have ANY version installed. That issue makes it much less attractive for desktop application developers (especially former VB developers) to produce .NET applications and components.
And recently Microsoftseems more anxious with the developer community, to discuss future technologies thanaggressively address all segments (e.g. desktop, web, enterprise, mobile) of the fragmented .NET developer space.
But can Sun do it? In my opinion, the initial product will have little impact.
It already appears that Sun Java Studio Creator will not provide for the production of desktop and mobile applications (at least in the initial version) - so there goes most of it's prospective market. Furthermore, Sun doesn't possess the retail and channel experience/networks that Microsoft have established.
Future versions? Microsoft are generally tenacious. Theywork at releases and learn from their failuresuntil they get it right.But can Sun?
Update:additional perspective in this Infoworld Article
A recent developer mailing list discussion questioned the efficiency of shared code, suggested the GAC should never be used, and suggested that (enterprise) applications should never be installed on the client.
For posterity, I thought I would include my response here.
> "Efficient (shared code) ? ... Saving disk space is no longer an issue. Keep a thousand copies of the assembly on the drive.
Yes sharing code is efficient - it is a core feature of most operating system architectures. Why share code? Fundamentally, because all computer systems are limited in resources. Can you load a thousand copies of a code module into memory? What about copies of all those module's dependencies? What about on a CE device, a PDA or an intelligent watch?
If we raise the level of abstraction to .NET, the same architectural limitations exist. In .NET, does the CLR load a new instance of a versioned (GAC) assembly a thousand times, or does it use one already loaded in memory? What about a non-versioned (privately deployed) version? What are the performance and working set implications of the CLR being able to resolve a single set of (JITed) stubbed code, rather than a thousand different (but the same) sets?
The reality is that the majority of code running right now on YOUR system IS shared. From the operating system to installed services, server products and of course .NET. What they have in common are large code bases, shared functionality and the need to maximise the efficient use of limited resources. Why use the GAC? To implement .NET applications which meet the same criteria.
> If MS recommends placing assemblies in the GAC, they are dead wrong. You shouldnt use the GAC for *anything* - it just repeats the errors of \system32 (maybe slightly better).
Many in the .NET community do argue that shared .NET code in the GAC should be limited to "system" type code. If you had stated that, I might have gone some way towards agreeing with you. But to say that NOTHING should be installed in the GAC suggests that you are coming from a particular architectural context - that you have a particular architectural scenario in mind. To disregard all others, and the GAC along with them, is at best limiting.
However, that doesn't mean that sharing code is without issues. Most notably that of versioning. I suspect your issue isn't really the GAC, but rather the question ... "How do I update shared code without breaking existing code?"
While not perfect, the introduction of side-by-side deployment of versioned assemblies together with application/publisher/machine configuration file policy, go a long way towards ensuring that each .NET application IS running against the same assemblies that they were built against - or against specific assemblies explicitly determined by the publisher or administrator.
> "I dont think that you should be installing (enterprise) applications on client machines anyway ... run them from servers ..."
The last time I heard someone say that was Larry Ellison of Oracle, when talking about his thin client (network computer). He cited many of the same advantages you do. About the only person who got really excited by that was Oprah ;-)
I never bought Scott McNealy's - "the network is the computer" - line either. Proposing that the answer to the "rich" vs. "reach" dilemma is to surrender solely to the "reach" camp, risks repeating Ellison's mistake.
There has been some discussion recently in the Australian .NET community about creating an Australian community weblog server, so one could have an aggregated feed for Australian weblogs.
However, to create a weblog and feed which combines Australian weblogs, one simply needs to create a "synthetic" feed - one which combines or filters each individual Australian feed. Why create a new server, when there are hundreds of free services ready to host a weblog?
One service that one can use to create a synthetic feed is Feedster (www.feedster.com). While not perfect, it can produce an amalgamated feed based on a list of weblogs in OPML (XML) format. An example OPML document that contains a list of Australian weblogs (known to me):-
OPML (XML) List of Australian Weblogs
To make it more user friendly, I have created a stylesheet (XSLT) that converts it to html for display. I have a simple transformation web service that one can use to combine the two:-
Web Page Listing of Australian Weblogs
Then given the OPML document, one can use Feedster to generate an RSS feed that combines all the Australian weblogs:-
RSS 2.0 Feed - Combined Australian Authors (last 30 entries)
Simply add that URL to your favourite aggregator (I like SharpReader and intraVnews for Outlook).
One could use the same technique to create a quick amalgamated feed of your choice.
Update: the OPML file is now being maintained by Frank Arrigo.