Blogs

I neglected to post about this at the time, but back in June 2008 I had an article published in .NET Developer’s Journal titled “A Walk Through the Process: Creating Services with Contract-First Design Using BizTalk Server 2006 R2 and Windows Communication Foundation.”  The article is available on the .NET Developer’s Journal website and the sample code is attached to this post.

BizTalk makes a great platform for true contract-first service development because it is designed around messaging.  One of the first things one usually does on a BizTalk project is to load or create XML schemas.  With BizTalk Server 2006 R2’s support for Windows Communication Foundation, it’s a natural platform upon which to build services using contract-first design.

The article assumes that you have worked with BizTalk before, but otherwise it is a step-by-step walkthrough of the process to create schemas, create sample orchestrations to carry out the work behind the service interfaces and to publish the schemas as WCF services.

One of the things I've been doing over the last six months is enhancing two well-known BizTalk Server tools: Scott Colestock's Deployment Framework for BizTalk and Darren Jefford's GenerateTypedBAMAPI tool.  I also created a CodePlex project of my own, Environment Settings Manager, which was incorporated into the Deployment Framework and is very useful in its own right.

I never took the time to stop and mention all of the changes and new features, so here's a summary:

Deployment Framework for BizTalk:

• Contributed the Environment Settings Manager project, which includes an environment settings spreadsheet that looks like the original one from Loren Halvorson, but does not use any macros and supports saving as either binary XLS or XML (SpreadsheetML).  The companion command-line utility can take in either type of file and export the environment-specific XML settings files that the Deployment Framework uses to create environment-specific configuration files on the fly.
• Added initial support for side-by-side deployment (multiple BizTalk app versions installed at once): added a "project" version property, added the version to the installer title and default install folder path, added version number to the BizTalk application name and SSO affiliate app name
• Added initial support for deployment of BAM activity definitions
• Updated WiX (for MSI generation) to 3.0.x, in the process drastically simplifying GenericBizTalkMSI.wxs and improving the MSI user interface
• Modified the installer to completely clean up on uninstall, removing all dynamically generated files
• Modified SetEnvUI.exe (the wizard) to open the file browse dialog in the current directory vs. C:\ and replaced a P/Invoke call with a Framework call
• Modified the installer to install "for all users" vs. only for the current user
• Simplified and improved the clarity of the checkbox captions in the server deploy/undeploy wizard
• Added an attribute to the UpdateSSOConfigItem Nant task for the BizTalk Application name
• Made minor documentation updates and replaced the HTML version of the help with a PDF version
• Updated to NAnt 0.85 release from RC1
• Included the Visual Studio Tools menu install scripts in the Sample ZIP file
• Cleaned up the project a bit, removing unused files, etc.

GenerateTypedBamAPI:

• Checked in the source code for the first time
• Added support for a relative path to the Excel workbook vs. explicit path only
• Added the partial keyword to the generated API class
• Added a method to the activity classes to enable continuation and return a continuation ID
• Added a command-line parameter to specify the .NET namespace of the generated code
• Changed "ESApi" to EsApi to conform to .NET capitalization conventions
• Added "Activity" to the end of the activity class names
• Explicitly passed "en-us" culture info to the Excel methods to avoid a globalization bug reported by users
• Made other minor code improvements, removed XSLT resource class in favor of Visual Studio's built-in resource support

While I was at it, I added to the GenerateTypedBamApi project a completely new command-line utility program called ExportBamDefinitionXml that can extract the BAM definition XML from an XLS file and write it out to a file.  This utility can be used to automatically keep a BAM XML in sync with a BAM XLS file during local or automated builds.  The code reuses some of Darren's code that was already present in GenerateTypedBamApi.

The majority of the changes listed above are not yet built into official "releases" on CodePlex, but hopefully that will happen soon -- I just need to coordinate with the project owners.  In the meantime, hop over to the Source Code tabs and grab the latest from there.  Please feel free to enter new Issues and Discussions topics in the projects with your ideas and bug reports.

Enjoy!

In my current project I'm using Enterprise Library 3.1's Caching block to cache data retrieved from web services.  The caching code is implemented in a regular C# class library, and I have NUnit 2.4 tests to test it.  In order to configure Enterprise Library at runtime I'm using Enterprise Library's FileConfigurationSource to point to a separate configuration file.  Works great.

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.

Reader Ravindranath posed several questions today in a comment, and I think that they deserve a post of their own.  Here they are again:

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.

As you may or may not know, Windows Presentation Foundation (WPF) does not ship with a data grid control.  [I'll pause while I wait for the cursing to die down...]  First, I need to make an important distinction: there is a Grid control in WPF, but it is a layout control, not a data grid like Windows Forms' DataGridView/DataGrid.  The good news is that the usual array of third-party component vendors has jumped in to fill the gap.  The bad news is that most are still at various stages of beta or 1.0 releases. 

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!

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:\Users\tabraham\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\tabraham\Documents.  In this example, I pointed the Download Manager to C:\Users\tabraham\Documents 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!

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!

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.