Thomas F. Abraham – On Technology

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.