How did this happen?  I’ve been using the same XP workstation for BizTalk and some .NET development for one year, using Visual Studio 2005 SP1, BizTalk Server 2006 R2 and the Visual SourceSafe 2005 provider.  My BizTalk solutions include a C# web application project alongside numerous BizTalk projects.  After deleting everything in the WebsiteCache folder, I discovered that my BizTalk solutions opened noticeably faster.  Upon opening and closing the solution a few times, it turns out that Visual Studio was creating one empty subdirectory in WebsiteCache for most or all of my project files and items in Solution Items.  Each time I opened a solution around 15 new subdirectories were created, but never deleted.  Over the course of a year, I accumulated 25,000+.  Another developer found 33,000+ subdirectories in his WebsiteCache folder!

Opening the solutions was taking longer and longer as time went on.  By clearing out the WebsiteCache folder, the solutions (with VSS integration, and which contain around 12-15 projects) now open 10-15 seconds faster.

Other people have reported this issue to Microsoft Connect, but the issue was closed as “not reproducible.”

However, I discovered while running my unit tests that when I ran a test and then tried to close NUnit GUI or re-run a test, there was a 5-10 second delay before the IDE closed.  An AppDomainUnloadException was being thrown at the end of the delay.  When I commented out the code that created the Enterprise Library CacheManager object the delay disappeared, so clearly Enterprise Library was doing something to block the AppDomain from unloading.

After some digging I found the issue.  FileConfigurationSource creates a worker thread that monitors the associated configuration file for changes.  The factory objects, in this case CacheManagerFactory, hold a reference to the FileConfigurationSource object.  There is no way to explicitly dispose or clean up the FileConfigurationSource object itself.  NUnit loads the assembly to be tested into a new AppDomain, and when it shuts down or runs another test, it tries to unload the test AppDomain.  What ends up happening is that NUnit asks the AppDomain to unload, but the FileConfigurationSource’s file monitoring thread does not shut down.  As a result, the AppDomain cannot be unloaded and we see the delay and the AppDomainUnloadException.  Needless to say, this is REALLY annoying.

One partial solution that I found is the Enterprise Library 3.0+ method FileConfigurationSource.ResetImplementation().  If you create a FileConfigurationSource object and then immediately call the static FileConfigurationSource.ResetImplementation() method with the same file path, but pass false to the ‘refreshing’ parameter, the configuration file will not be monitored for changes.  This will have the effect of shutting down the monitoring thread and allowing the AppDomain to unload… but you lose auto-refresh of configuration.

I still haven’t found a real solution to this.  The ‘patterns & practices’ guys need to make FileConfigurationSource implement IDisposable or something.  In the meantime, I’m forcefully killing NUnit all the time or waiting out the delay, both of which are really a pain.

1. As a part of migrating from .Net 1.x to .Net 3.x, is it advisable to re-architect for the newer .Net 3.x features (WWF, WCF, WPF, etc)?
2. When is it a MUST to re-architect and when is it optional?
3. Are there any approach papers towards this?

There are two primary areas of benefit for those considering an upgrade from .NET 1.0/1.1 on Visual Studio 2002/2003 to .NET 2.0, 3.0 or 3.5: benefits resulting from IDE enhancements, and benefits resulting from .NET Framework enhancements.

First, let’s talk about IDE enhancements.  Today, your IDE of choice should be Visual Studio 2008, whether you are using .NET 2.0, 3.0, 3.5 or are considering an upgrade from .NET 1.0/1.1.  VS2008 is the first Visual Studio IDE for .NET that can target multiple versions of the .NET Framework, so if you are using .NET 2.0 today, you have nothing to lose and everything to gain by moving from VS2005 to VS2008.

Just a few of the benefits of Visual Studio 2008 include:

• Completely new CSS-oriented ASP.NET designer, shared with Expression Web (formerly FrontPage)
• Robust IntelliSense for JavaScript
• Improved code analysis (FxCop) tools
• Improved performance analysis tools
• Team Explorer 2008 client for Team Foundation Server 2005/2008, with an improved Source Control Explorer

Since Visual Studio 2008 is still a new release, there are some Visual Studio IDE extensions that haven’t been upgraded yet.  Depending on how important those are to you, it’s possible that you could be forced to wait for updates.  Two notable examples are BizTalk Server 2006 R2, which requires VS2005 and has no announced timetable for a VS2008 update, and Microsoft’s Enterprise Library, which includes a configuration editor plug-in that is not VS2008-ready.  Enterprise Library has an easy workaround since you can either use the standalone editor or hop over to VS2005 for configuration tweaks, but BizTalk’ers are out of luck.

Now to move on to the main focus of Ravindranath’s questions: upgrade benefits resulting from .NET Framework enhancements.

The .NET Frameworks 1.0, 1.1 and 2.0 were completely isolated from each other, but that changed with .NET 3.0 and 3.5.  The .NET 3.0 and 3.5 Frameworks can be thought of as layers on top of each other.  In fact, as I’ve written about previously, .NET Framework 3.5 requires both .NET 2.0 SP1 and .NET 3.0 SP1.  ASP.NET has, in fact, remained at version 2.0.

Projects upgrading from .NET 1.0/1.1 to 2.0/3.0/3.5 will gain their major benefits not from features in 3.0 or 3.5, but from the CLR enhancements introduced back in Framework 2.0.  In most cases you will find immediate performance and memory usage benefits with a straight conversion to 2.0, making no code changes except in the rare cases where you might have used a method or class that had a breaking change in 2.0.

My answer to question #1 is generally No, and my answer to question #2 is that redesign is never required.  Now, of course, I have to qualify that with a couple of caveats, and put some logic behind my answers.

First, it really depends what kind of application is involved and what is important to the business behind it.  My primary example here is Windows Presentation Foundation (WPF).  If your application is a consumer-focused application where graphics and fancy look-and-feel are very important, then yes, it makes sense to take a very hard look at moving to WPF.  You will never reproduce what WPF can do in Windows Forms — although even that requires the caveat that WPF controls can be hosted inside a Windows Forms application!

If you really need the full power of WPF and your app is currently Windows Forms-based, you’re really looking at a rewrite, not an upgrade.  WPF carries with it a significant learning curve, immature tools and third-party libraries and a major time investment.  I do not discourage its use, but you do need to have good reasons and a real need for it, and know what you are getting into.  In another year or two, there will be no reason not to build all smart client apps with WPF, but we’re not there yet.

Second, there is often no good reason to rewrite your ASMX-based Web services with Windows Communication Foundation (WCF).  ASMX is still supported, and it will remain in the Framework into the future.

There are two main reasons to rewrite existing ASMX services with WCF:

1. You have an explicit need for the WS-* features introduced in WCF and cannot get by with the WS-* subset in the Web Services Enhancements add-ons.
2. You need the ultimate in performance from your service.

I recommend without qualification that all NEW services (which can be anything from an MSMQ listener to a web service to a self-hosted TCP endpoint) and service clients be written with WCF.  Once again, you will experience a fairly significant learning curve, but WCF is the communication framework of the future, so you’ll have to learn it eventually.  Of the major new subsystems in .NET 3.0/3.5, WCF is the one that most developers will use most often, and it is the first one to learn.

That leaves Windows Workflow Foundation (WF) and CardSpace, and these are the least common.  As with most security-related programming tools, CardSpace will never excite much developer interest.  I think it will remain a niche tool.  On the other hand, WF has a lot of potential, but it also takes the most time for developers and architects alike to fully comprehend how to put it to use.  One sample that is out demonstrates the automation of a Windows Forms form using nothing but the WF rules engine to drive validation and enabling/disabling controls as values and control focus changes.  Normally this would involve dozens of event handlers and many lines of code in even a relatively simple form, but this sample has almost no code behind the form.  That’s a pretty slick example of just the WF rules engine, which doesn’t even address the actual workflow engine.

So, to recap, in most upgrade scenarios from 1.1 to 3.0/3.5, I think you will be best served by a direct upgrade, not a rewrite.  Then evaluate, in order, where you might be able to put to use WCF, WF, WPF and CardSpace, but don’t rush to use any of them just because they’re there!  You will gain huge benefits just from the improvements in the 2.0 CLR and Framework and in the newer Visual Studio IDEs, so enjoy those improvements without too much worry about the 3.0 alphabet soup.  You’ll find a use for them when the time is right.

Finally, I am not aware of any specific papers including guidelines for when to re-design or not in these areas.  Generally, I would look to MSDN and primarily the patterns & practices team for this type of analysis, but I haven’t seen anything yet.  If any readers know of related papers, please feel free to post links in the comments.

Update: For the sake of completeness, I should mention that Windows Forms controls can be hosted in WPF, and that’s another option to consider.  Here, I’m talking about “pure” WPF controls.

The WPF data grid controls that I have discovered include:

• Syncfusion Essential Grid (supposedly arriving in March 2008)
• Infragistics xamDataGrid (currently in 1.x release)
• Xceed DataGrid for WPF (currently in 1.3 release)

For the last three months I’ve been working on a .NET 3.5 WPF-based business application (a rare animal these days, since most WPF samples and real-world apps are highly consumer-oriented).  I’ve been using Visual Studio 2008 Beta2, and jumped over to the RTM the day it was available.  The main purpose of this application is data editing, so I needed a solid data grid control.  I started by checking out the options listed above.

My first approach was Infragistics xamDataGrid.  They offer a free Express edition, so I started with that (and later purchased the product to obtain support).  It went in pretty easily and visually looked nice.  My data source is a collection of objects that implements IBindingList.  If your collection class does not implement IBindingList, you will not be able to add new rows to the grid (this is also true with Xceed).  I quickly discovered that xamDataGrid did not provide the out-of-box behaviors that one would expect when adding and canceling a new row.  For instance, if you start a new row, enter some values, then hit Escape twice, my expectation is that the new row is canceled and removed (see Access, SQL Management Studio, etc.).  I also had trouble getting the grid to bind to a column using a ComboBox instead of a string value.  I had a collection of objects that represented all possible values of a field (CountriesCollection, for example), and was binding the ComboBox to a property of that same object type (binding CurrentCountry property, of type Country, for example).

The Infragistics support forum for xamDataGrid consisted of many people posting questions and rarely receiving answers.  There were many threads ending with “Hello, is anyone from Infragistics listening?”  Thinking that premier support would be great, we purchased the product.  Quite frankly, I was disappointed with the “premier” support.  I got responses that did not address my specific scenario (as explicitly described in the support request), and those that said “it’ll be fixed in a future hotfix.”  Suffice it to say, I dumped xamDataGrid.

I highly recommend Xceed DataGrid for WPF.  This is a solid product with good support.  It has been out in real release, not beta, for a long time already, and it just works.  It took a half day or so to drop it in and hook it up, figure out a few subtleties, and it was ready to go.  I still had some questions, so we purchased this product too, and their support staff turned the questions around quickly with definitive answers.  Xceed also offers a free, highly-capable version of DataGrid for WPF, so check it out.  One thing to note if you are used to Windows Forms data grids: Xceed DataGrid for WPF does not support the IDataErrorInfo interface for bound object validation and automatic error display.  They have that in their suggestions list but with no timeline.

Save yourself some time and hassle and go straight to Xceed DataGrid for WPF.

NOTE: I have no connection to Xceed whatsoever; I just hope this saves you some time since I learned the hard way!

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.

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!

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.

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

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!

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