Thomas F. Abraham – On Technology

A while back Microsoft copied some of the biggest and most in-demand software downloads for MSDN Subscribers to the Akamai content distribution network.  If you haven’t heard of Akamai, it operates a worldwide network of content distribution servers with the goal of offloading download activity from web servers and moving the content as close to your physical location as possible.  It’s all about getting data to you faster.

There are now two ways to get some popular software from MSDN Subscriber Downloads.  The first, and familiar, way is to log into the Subscriber Downloads website as usual, and use the Microsoft Download Manager ActiveX control to download the software.  The newer, Akamai way is (I believe) only available from one web page here.  You will still need to log in as usual.

In order to use the Akamai downloads:

1. Allow pop-ups from http://msdn2.microsoft.com.
2. Visit the downloads link, log in, and when the page comes up, look down to the “Top Subscriber Downloads” area.  These are the Akamai download links.
3. Determine if the software you want is in the list.  If not, you’ll have to go through the normal Subscriber Downloads site.
4. If the software you want, like VS 2008, is in the list, click the link to begin the download.  A pop-up will appear, and you will have to allow the Akamai Download Manager ActiveX control to install.  You may need to re-click the link after the control installs.
5. The Download Manager will ask for a folder to store the file in.  You’ll have to keep its window open while the download takes place.
6. If you are on Vista with default configuration, there is one little catch: the Download Manager will not be allowed to download to most directories on your hard disk, and it will be forced into a Vista virtualized folder system.  That’s where Vista points an application to a folder in a temporary location (not the folder the application thinks it is pointing to) for security with Internet applications.  Once you have downloaded a multi-GB file and it is not in the folder that you selected at the start of the download, you are probably not going to be a happy camper.  It’s there, just not where you expect.  Look for a folder like this: C:UserstabrahamAppDataLocalMicrosoftWindowsTemporary Internet FilesVirtualizedCUserstabrahamDocuments.  In this example, I pointed the Download Manager to C:UserstabrahamDocuments and that is where it ended up.

I hope that helps.  Some of the downloads are a lot faster from Akamai — if they happen to be popular enough to be on the Top Subscriber Downloads list.  Visual Studio 2008 RTM is up there as I write this, and my download just finished.  Time to install!

The next major release of Visual Studio 2008 and the .NET Framework 3.5 have quietly been released to manufacturing over the weekend, along with .NET Framework 2.0 SP1 and .NET 3.0 SP1.  This is an important release of Visual Studio because it fully integrates the tooling for the technologies released in .NET 3.0 (Windows Communication Foundation, Windows Presentation Foundation, Windows Workflow Foundation and CardSpace) and, for the first time, can target multiple versions of the .NET Framework.

Our team has been building experience in the .NET 3.0 technologies for most of this year and playing with the betas, and we’re looking forward to working with the improved tooling in the RTM release.

Download .NET Framework 3.5 here.  The .NET 3.5 installer will install the 2.0/3.0 Framework and 2.0 SP1 and 3.0 SP1 automatically.  The service packs are also available separately for 2.0 and 3.0.  As for Visual Studio 2008, I think the MSDN subscriber downloads site is having issues already, probably due to high demand.

I just finished installing .NET Framework 3.5 RTM on my laptop running Vista Enterprise.  The install took a long time, about 30 minutes, but succeeded.  Along with 2.0 SP1 and 3.0 SP1, it also installed two Vista hotfixes, KB929300 and KB110806.  This release, like 3.0, is more of an additive release that requires and builds upon 2.0 and 3.0, unlike the 1.1 to 2.0 transition.

There is also a big new training kit (120 MB) that includes presentations, demos and labs.  You can get that here.  There are also 3.5 whitepapers by David Chappell and a 3.0 common namespaces and types poster.

I’ve been working with 3.0 and the 2008 betas for about 10 months now, so I’ve been a bit negligent with my blogging!  It has just ended up to be another really busy year.  I hope to get some new posts out about 3.0/3.5 soon.

From Microsoft:

.NET Framework 3.5 builds incrementally on the new features added in .NET Framework 3.0. For example, feature sets in Windows Workflow Foundation (WF), Windows Communication Foundation (WCF), Windows Presentation Foundation (WPF) and Windows CardSpace. In addition, .NET Framework 3.5 contains a number of new features in several technology areas which have been added as new assemblies to avoid breaking changes. They include the following:

• Deep integration of Language Integrated Query (LINQ) and data awareness. This new feature will let you write code written in LINQ-enabled languages to filter, enumerate, and create projections of several types of SQL data, collections, XML, and DataSets by using the same syntax.
• ASP.NET AJAX lets you create more efficient, more interactive, and highly-personalized Web experiences that work across all the most popular browsers.
• New Web protocol support for building WCF services including AJAX, JSON, REST, POX, RSS, ATOM, and several new WS-* standards.
• Full tooling support in Visual Studio 2008 for WF, WCF, and WPF, including the new workflow-enabled services technology.
• New classes in .NET Framework 3.5 base class library (BCL) that address many common customer requests.

This has turned out to be a very busy year, thanks in part to Microsoft’s ever-accelerating stream of product releases.  Even five years ago I never thought that I’d hope Microsoft would slow down!

One of those exciting new products is Microsoft BizTalk Server 2006 R2, which features Microsoft’s new RFID platform, extensive support for EDI and all-new native WCF adapters (my favorite!).  I had the pleasure of presenting at the Minneapolis/St. Paul-area BizTalk Server 2006 R2 Launch event on October 9th.  My session was entitled “BizTalk Server 2006 R2: A Core Component of a Service-Oriented Architecture” and was very well-attended.  Thank you to everyone who listened in!  We even had Jon Flanders from Pluralsight and Michael Woods from the BizTalk product group on hand, and Michael introduced my sessions with an overview of Microsoft’s vision of SOA.

Tonight, November 15th, I’m presenting a session with my co-worker Randall entitled “Message Queuing with BizTalk 2006 R2: MSMQ, IBM WebSphere MQ and Ordered Delivery” for the Twin Cities BizTalk User Group.  I’m going to talk about queuing and the pros and cons, go through some MQ configuration issues and demo the MSMQ and WebSphere MQ adapters for BizTalk.  Randall is going to show some code as part of a solution for ordered delivery using MSMQ.  We hope to see you there!

Most developers tend to think in the context of the language they are currently writing.  If you’re writing C#, you are accustomed to having the core .NET Framework class library at your disposal.  If you’re writing VB.NET, you’re used to having many more classes above and beyond the core class library, and in J# (assuming anyone actually uses J#) you have yet another pool of classes to choose from.  This language-specific focus can lead to an unfortunate bit of tunnel vision.

To make a stunningly obvious point (once you think about it for a minute): your C# application is free to use any class available in the VB.NET or J# class libraries (or any others).  Your VB.NET application is free to use any class available in the J# class library, and so on.  Whatever language you are using, you can, and should, take advantage of all of the class libraries available to you!  Less work and less custom coding is always a great thing.

In the context of a C# application, this means adding a reference to Microsoft.VisualBasic.dll.  (What? Is he nuts?!?)  Sure, it might seem odd at first, but all high-level language code for .NET is reduced to one intermediate language in a managed code assembly — IL.  It makes no difference if it originated in COBOL.NET, C#, VB.NET, J#, etc., and there is absolutely nothing wrong with having “using Microsoft.VisualBasic” in your C# code.  The core .NET Framework already includes the extra VB class libraries, but to get the J# class libraries you need to have the J# Runtime installed.

There is a lot of great code just waiting to be used.  For example: need to work with ZIP files (unlike System.Compression)?  Check out the java.util.zip namespace in the J# runtime.  Yeah, that’s .NET managed code, despite the “java” in the namespace.  Remember that the J# runtime and J# itself was designed to be compatible with Java, so the runtime attempts to recreate as much of the (older) Java class libraries as possible.  Another example: the Microsoft.VisualBasic.Financial class.  How cool is this?  Asset depreciation calculation, present value of an annuity and more.  If you’re coding in C#, you may well have gone off and coded all of this yourself, or looked to open source for a solution — all while it was right under your nose.

I found an old article from MSDN magazine that demonstrates writing a ZIP utility in C# using the J# runtime, which is a great example for this topic.

Some of you will be saying “Duh!” by this time, but the reactions from years of saying this to developers has told me that it is not immediately obvious to everyone.  Hopefully this will save you some time!

I happened to be building an ASP.NET 2.0 website earlier this year when the ASP.NET 2.0 AJAX Extensions RTM’d, so I decided to try it out.  Someone recently asked me my impressions of the Extensions and Control Toolkit and how best to get started, so I thought I’d pass on my comments.

Thinking of existing ASP.NET developers picking up AJAX for the first time with this framework, it is an extremely well designed and natural development model.  It integrates almost seamlessly into the existing development environment and “<asp:xyz>” tag model.

The AJAX Extensions support static page class methods and web services, mainly using JSON serialization, to access and even data bind controls.  Some of the controls use this capability to populate data, such as the CascadingDropDown.  If you want to use that capability outside of the provided controls, you get to start writing some JavaScript against the client-side API (Microsoft created a new object model written in JavaScript, all client-side, namespaces and all).  However, all of the source code to all of the controls, and the entire Toolkit itself, is available for download, so you can dig as deep as you want for usage or implementation examples.

The barrier to entry for JavaScript and all of the cross-brower drama that comes with it can be significantly lowered by learning and programming to the new client-side API, so that is something worth learning.  Developers should make an effort to truly understand what is going on when they use AJAX on a page.  There is a lot of code happening behind the scenes to produce the end user effect of partial updates or fancy animated controls.

There are several good tutorials to get you off the ground.  The AJAX Framework is truly a framework — when you install it you don’t have any fancy AJAX controls to drop on your pages.  Instead, you’ve got the basis for building your own, and for writing cross-browser JavaScript code on top of the client-side API.  That may be a surprise to someone installing it for the first time.  Instead, all the fancy controls are housed in a Microsoft-sponsored open-source project on CodePlex.  Naturally, they are documented about as well as most open-source projects.  However, they do come with a sample website that you can play with.

One thing that should be high on everyone’s to-do list as a web developer is mastering CSS.  If you are not very strong with CSS, it is going to become tougher to use the new tools, including AJAX and WPF/E.  For many of the fancy controls noted above, you need to create a number of CSS styles just to get them to work.  I recommend one site for CSS that may open your eyes to the possibilities.  Check out all the layouts you can do with no nested tables involved, and cross-browser too.

I believe that the AJAX toolkit documentation is lacking, in some areas significantly.  You will probably find yourself with questions that are not answered at all, or poorly.  However, that has not proven to be a major issue.  For the most part things work as expected, but there are certainly subtleties to learn.

I have had some issues with the collapsible controls not sizing correctly in a stacked configuration, but that is in an absolute positioning-based CSS website that may have another CSS issue that I’m missing.  On the same site, we have an issue with the stacking and with calendar controls not appearing in IE6 only, but again, that could be related to the other CSS.

Another downside seems to be page speed during development.  If debugging is enabled you get a non-compressed debug version of the large JavaScript client-side code, and starting a page in the debugger may take an extra five seconds before it is usable vs. no AJAX.  I believe one of the recent Control Toolkit updates is beginning to address this issue.

A not-to-miss blog for a wide range of ASP.NET topics, not just AJAX, is Scott Guthrie’s.  Here are some more ASP.NET AJAX labs.  And training videos.  The good news is that you can start using the Extensions for very small bits of functionality on your site and expand from there.  For instance, I put an existing checkbox that simply turns a flag on and off in a database inside an UpdatePanel to avoid a complete postback.  I’m sure you can think of areas like this on your websites where a simple operation could be easily optimized with AJAX Extensions for a much bigger benefit in user experience.

I’ve been forgetting to write about this one for the better part of a year…  Many of you have probably seen the exception dialog box in the SQL Server 2005 GUI’s.  It lets you copy the exception text to the clipboard and so on.  It’s pretty nice, certainly an improvement over past dialogs that just printed the error and made you take a screenshot or copy down the error message.

Microsoft quietly released that very exception dialog as a standalone, supported managed assembly that you can use in your own applications.  This is a great thing to take advantage of if you are working on any WinForms 2.0 apps.  (I haven’t checked, but it is probably .NET 2.0 since it is part of SQL 2005.)

From the source:
Microsoft Exception Message Box
“The exception message box is a programmatic interface that you can use in your applications for any tasks for which MessageBox may be used. The exception message box is a supported managed assembly designed to elegantly handle managed code exceptions. It provides significantly more control over the messaging experience and gives your users the options to save error message content for later reference and to get help on messages.”

http://download.microsoft.com/download/f/7/4/f74cbdb1-87e2-4794-9186-e3ad6bd54b41/SQLServer2005_EMB.msi

I’ve written before about installing .NET Framework 1.1 and 2.0 side by side (SxS) on the same box.  Microsoft recently added to the mix .NET Framework 3.0, so it’s about time to clear up any confusion on the newest release.

Above all, you should understand that the version designation of 3.0 was strictly marketing-driven.  At the most basic level, .NET Framework 3.0 equals .NET Framework 2.0 plus a bunch of new DLLs.  If you install .NET Framework 3.0 on a box that does not already have .NET Framework 2.0, the installer installs Framework 2.0.  Therefore, if you already have .NET Framework 2.0 installed on a box, you should not be too concerned that installing 3.0 will break existing applications.  In fact, you will find that in the ASP.NET tab in IIS Admin, .NET 3.0 is not even a choice.

It is worth noting that .NET Framework 3.0 is pre-installed on Windows Vista and will be pre-installed on “Longhorn” Server.  However, .NET 3.0 may be installed on any Windows XP SP2 or Windows Server 2003 SP1 box.

If you’re working with a mission-critical server then you should, of course, be cautious and do some planning and testing anyway.  Just be aware that the 1.1 to 2.0 story is identical to the 1.1 to 3.0 story, because 3.0 is in effect 2.0 with more files.

By now you may be asking what .NET Framework 3.0 is good for if it is essentially Framework 2.0.  .NET 3.0 delivers a number of long-anticipated and important features, though mostly of interest to application developers rather than server administrators.  The list includes Windows Communication Foundation, Windows Workflow Foundation, Windows Presentation Foundation and Windows CardSpace.  You can read more about them on the official .NET Framework 3.0 site.

In summary:

• .NET 3.0 is not a major change to the core .NET Framework as was 1.0/1.1 to 2.0
• If you currently have only .NET Framework 1.0 or 1.1 and you are looking to install 2.0 or 3.0, see my side-by-side post
• If you currently have .NET Framework 2.0, installing .NET Framework 3.0 is not a major change as the version numbers would suggest
• If you currently run .NET 2.0 applications, they will not know or care that you have installed .NET 3.0

Please feel free to contact me with questions and your own experiences with the upgrade.  Thanks for reading!

You’re already familiar with the Microsoft Management Console (MMC) if you’ve ever opened Computer Management, IIS Administration or any of the other Windows management tools.  The most common version today is 2.0, found on Windows Server 2003 and Windows XP.  Back in March 2006, Microsoft released MMC 3.0 without much fanfare.  The big changes in 3.0 are a new programming model for .NET-based snap-ins and reliability improvements.  MMC 3.0 can isolate snap-ins from each other, at least if they are .NET-based, and do a bit better job of error handling and logging in general.

If you have not already installed MMC 3.0, you’ll need it before too long.  BizTalk Server 2006′s Enterprise Single Sign On Admin tool requires MMC 3.0, and there will be many more in the future.

There are freely available versions of MMC 3.0 for the various editions of Windows, but you need to get the right one for your OS.  Search Microsoft Downloads for ‘MMC 3.0′ to find the one you need.  You’ll need Windows XP SP2 or later, or Windows Server 2003 SP1 or later.  If you’re running Vista, you can stop reading now, because you already have MMC 3.0 and it is pre-optimized!

Once you have MMC 3.0 installed, you may find that snap-ins that rely on it (and you generally won’t know which ones do) start up slowly.  You may find yourself staring at the screen for a long time each and every time you start up one of those snap-ins.  The reason is that a bunch of code in MMC 3.0 is written in .NET.  No, that in itself does not make it slow!  For some unknown reason, Microsoft does not optimize the MMC 3.0 .NET code upon installation as it does with the .NET Framework itself.  (For you developers, the DLLs aren’t automatically GAC’d, nor are native images generated.)

There’s a very easy fix for this.  Speed up your MMC 3.0 snap-in startup times by opening a Command Prompt and running ‘mmcperf.exe’.  It’s in your Windows\System32 directory.  This will create ready-to-run versions of the MMC .NET code (native images).  You’ll notice a big difference in startup time — and we may never know why Microsoft didn’t just do this out of the box!  Note that this does not speed up the snap-ins once they are actually running.  This is related only to the startup time when you run MMC and load a .NET-based snap-in.

I frequently hear comments that Web services are inappropriate for carrying large data messages, say greater than 1 MB.  In the past there was some truth to that, but no longer.  There is really no reason to avoid a Web service simply because you have to send or receive a bunch of data.

By default, transferring non-ASCII data over a SOAP call means using Base64 encoding.  You have to go back to the early days of the Internet to find the Base64 definition in IETF RFC 1521, which was adapted from an even earlier RFC.  Base64 typically increases the size of the encoded data by 33%, not to mention the CPU and memory required to encode and decode.  Imagine sending a 3 MB PDF over a SOAP call with Base64 encoding.  That PDF gets translated into a 4 MB ASCII string, transmitted to the other endpoint, and then converted back to the original 3 MB PDF.  Clearly this is not an efficient scheme.

Years ago, Microsoft first addressed this issue in the Web Services Enhancements (WSE) add-on to .NET with their proprietary DIME extension to SOAP.  Like MIME, DIME is designed to define message attachments of varying data types, but in this case to a SOAP message.  According to Microsoft, DIME was a more efficient format than MIME for message parsers.  It was not widely adopted.

Why attachments?  Just like sending an email, you might want to send a SOAP message that carries alongside it one or more other chunks of data, whether that’s a ZIP file, another XML file, a PDF, etc.  An attachment scheme like MIME defines in the message header the list of attachments, and for each attachment an encoding method.  We would prefer to use a binary encoding method that does not increase the size of our data.

The W3C standards organization got involved with the advent of the Message Transmission Optimization Mechanism (MTOM), which today is a W3C Recommendation.  MTOM uses concepts from MIME/Multipart to add attachments to a SOAP message, and it can optimize elements of type base64Binary.  If you put data into a base64Binary element with MTOM disabled, you will literally see a Base64-encoded version of your data (and much bigger than the original).  If you look at the same element with MTOM enabled, you will find a pointer to a MIME part that contains your actual data in binary format.

MTOM is available today for .NET 2.0 Web services in Web Services Enhancements (WSE) 3.0 and Windows Communication Foundation.  Both of these are freely available and fairly easy to use.  WSE 3.0 is perfect for your existing ASMX Web services because there is usually no code to change to take advantage of MTOM.  Keep in mind that clients of an MTOM Web service also need to be MTOM-aware.  The only requirement is that the data element you wish to optimize is of type base64Binary in the XML, and a byte array in your .NET code.  Once you enable WSE3 on your Web service project, you can simply enable MTOM in the WSE configuration.  Remember to enable it on the client side too.

Attached to this post you will find a sample .NET 2.0 solution that demonstrates a single Web service implemented in plain ASMX, ASMX with WSE3 and WCF.  You’ll notice that there is no special code at all for MTOM, just configuration.  If you use an HTTP monitor like Fiddler to examine the SOAP messages, you will see the differences with and without MTOM.

It is worth pointing out that BizTalk 2006 Web services CAN take advantage of MTOM!  When you publish a schema or orchestration as a Web service, what comes out is a regular old .NET 2.0 ASMX Web service.  Again, as long as the large data elements are defined as type base64Binary and as a byte array in code, MTOM can be enabled with no code changes.  Just update the BizTalk Web service project to enable WSE3 and MTOM.

Please contact me if you have questions, and please take advantage of these free and easy tools to make your Web services faster.

webservicesmtomdemo.zip

BizTalk Server has long been one of the most powerful — and unwieldy — tools in Microsoft’s server arsenal. Sadly, BizTalk 2006 is what BizTalk 2004 should have been, and one wonders why it took so long to arrive. Frankly, I’m not sure that Microsoft really knows what to do with BizTalk. I believe that the product is misunderstood even within Microsoft itself, and I do not think the marketing and sales teams really know how to market and sell it. When you consider the number of years that BizTalk has existed (six), it has a very small number of customers.

Developers naturally want to write custom code, so it’s not easy to convince them of BizTalk’s benefits. It certainly doesn’t help when Windows Workflow (WF) comes along with a big marketing bang and further distracts the developer community. Now you’ve got developers looking at the WF design surface and thinking that it looks just like BizTalk’s, so it must be the same, and it must be better because it’s newer. True or not, this is the kind of problem that Microsoft has created for itself.

I believe that Microsoft needs a different approach to selling BizTalk. First of all, the product group needs to get a grip on the product’s future direction, and then educate — repeatedly! — Microsoft’s sales teams until they finally understand the product and how to sell it. Second, pushing feature lists is a lost cause. Your average CIO/CTO doesn’t care. Microsoft should be selling BizTalk with specific business scenarios. They could build example solutions that are written in both C# and in BizTalk, and show explicitly how BizTalk reduces code, brings in management and monitoring features, etc. Reducing the barrier to entry is critical. Providing extensive samples and prescriptive guidance for developers would help adoption from the technical side.

Here’s my list of the top three issues in BizTalk 2006 that the product group should address in v.Next:

Inadequate support for medium to large sized messages. In an ideal world all messages would be 0-150KB, but realistically people need to send around metadata plus documents like PDFs, etc. The larger the message size the quicker problems are encountered, from hosts running out of memory and crashing to high CPU utilization to extreme SQL Server stress.
BAM is extremely valuable but still too hard to configure, so it is not used as often as it should be, and that is really a shame. The tools need to be brought together into the Visual Studio IDE or into the Admin Console.
Debugging tools are not even CLOSE to Microsoft standards. Visual Studio is known for an outstanding debugging experience, and BizTalk has a horrible debugging experience. We should be able to open a BizTalk project and directly debug pipelines and orchestrations in the IDE.
What else should the product team improve upon? How could Microsoft better position BizTalk in the market? I’d love to hear your opinions.