Version 2.6 of the Deployment Framework is now available (see the download links - the full download, core, and tools have all been updated.)  Future work in this area will be about augmenting the already-great deployment story in BizTalk 2006! 

The release notes below will (likely) only be interesting for folks that are using the framework extensively.

Interesting Features:

• If you populate the bizTalkHosts property with the name of the Hosts that you are using, the 'servicecontroller' nant task is used for the stop/start of BizTalk services, with a configurable timeout stored in the 'biztalkHostResetTime' nant property. This requires recopying the BizTalk.nant.tasks.dll to your \program files\nant\bin directory. This alleviates the problem some users were having with timeouts in service restarts.
• IISReset now uses configurable reset time from nant property iisResetTime.
• Modified the sample application to demonstrate how you can maintain adapter configuration in binding files (i.e. the TransportTypeData sections) in its "unescaped" form -- rather than having to maintain it as escaped xml-within-xml. This relies on a new tool - ElementTunnel.exe, which is also in the Tools download. This is a huge help with adapters such as MQSeries that have many configuration elements.  More on this in another post.

Administrivia:

• SSOSettingsFileImport.exe opens files with read access only, eliminating some file locking issues.
• Permissions on the physical directories associated with virtual directories are now granted to the account specified as the application pool account (instead of just aspnet account.)
• Now using NAnt .85 RC3
• Now using log4net 1.2.9 (thanks Campbell McNeill for work on this!)
• Now using the July 2005 release of WiX (thanks to Loren Halvorsen for work on compatibility with this.)
• Now using XmlPreProcess 1.0 RC3 (and the associated SettingsFileGenerator.xls.) One new feature here is the ability to use URLs that contain query strings in the spreadsheet. The name/value pair XML files that are generated will wrap as CDATA where appropriate. Thanks Loren!
• Modified the sample application to demonstrate how file receive and drop locations can be made relative to the a) project directory on a developer workstation or b) installation directory on a server. This has actually be in the sample application before - but it relied on the xmlpoke nant task, whereas now it uses the XmlPreProcess mechanism we use for all other binding file modifications.
• Modified the deployment verification unit test in the sample application to rely on a NUnitUtility helper class that you can pull into your own projects. One included method allows you to examine the event log (on multiple machines) looking for errors that BizTalk might have raised during the test - very handy, and a potentially important component of your test.
• Support for a local_settings file used with XmlPreProcess. It can be handy to have an "environment specific" set of macro values that are particular to a local workstation, and the sample application shows how this is done now.
• Added transforms and schemas to the list of what is re-gac'd for the updateOrchestrations target. See here for more detail. In a recent release, I made changes that allowed for the use of a single binding file, so that binding files as emitted by the deployment wizard could be used (rather than splitting them by hand, which was required early on with the Deployment Framework.) This was a good change…but the implementation broke the "messaging only" scenario (where you have no orchestrations.) I don't have a good fix for this yet. The workaround is as follows: In your project's nant file, set includeOrchestrations to "true" (even though you don't have any), and define the orchestration assembly list to be an empty string, as shown here:
  <property name="includeOrchestrations" value="true" />
<property name="orchestrations" value="" />

How do you upgrade?  Extract the "core" zip file on "top" of your existing project, and then fix up the WiX directory manually (since it will be named BizTalkSample.WiXSetup after the unzip.)  All tools and scripts will be updated as a result.  Then test...Leave a comment with any issues you encounter.  Good luck!

Will this be the last place on the web that trumpets the BizTalk 2006 beta?  Likely not, but I did see it in quite a few places today.

Head to http://beta.microsoft.com with your passport and 'BizTalkBetaTeam' for a guest ID, and then wait patiently.  (While you're waiting, consider building out a VPC image with VS2005 beta 2 and, presumably, the latest SQL 2005 bits.  SQL 2000 would be fine as well, as BizTalk 2006 will not require SQL 2005.)

This...is going to be a great release.  Nothing so revolutionary that you can't leverage all the skills that you (or your staff) have already learned.  Yet, there are many, many important feature additions and "rough edges" removed.

Rattling off a few of the new items:

• In-order delivery for any adapter that supports it (i.e. MSMQ, MQSeries, etc.)  In 2004, only MSMQ/T supported this.  (Of course, a faulty orchestration can break first-in-first-out - more on that in a later post.)
• The introduction of an "Application" concept for grouping BizTalk assets - which extends to orchestrations, role links, send port groups, send ports, receive ports, receive locations, policies, schemas, maps, pipelines, other resources (e.g. soap proxies),  you name it!  Just as importantly, the management infrastructure understands applications - so health/management views can be narrowed down appropriately.
• The management infrastructure has been completely encapsulated in an MMC - HAT is largely hidden.  More interesting is that the MMC can manage multiple BizTalk groups - and can do so remotely (by definition...)
• A packaging/deployment solution that looks good - we'll have more to say about that in the coming weeks!  The developer experience in particular looks to be quite good.  Likely still some value-add to be done on the server side.
• Ability to route failed messages - and subscribe in your orchestrations.
• Calling pipelines from within orchestrations (no more loopback adapter or similar solutions needed...)
• Zoom and expand/collapse-state-preservation within orchestrations.  (So when you collapse that big group or scope shape, it will stay collapsed across close/re-open.)
• BAM integration with SQL Notification Services.
• "Operator Role" has been defined to make allocating administration tasks a bit easier from a security perspective.
• Pipelines can have per-instance configuration - saving you from recreating what were essentially a lot of duplicate pipelines!  (This was possible in 2004, I believe - but not exposed cleanly.)

This will be fun...I look forward to exploring the beta bits (man, the CTP was pretty short-lived...!)

As has been noted before in the lore of BizTalk, it sure would be useful to use a real debugger with orchestrations - at least occasionally.

There are times when an expression shape winds up getting a bit sticky (not that I would know...) and a debugger would be just the ticket.  Other times, the exception you are getting from the orchestration engine isn't at all clear.

Still other times, seeing the actual contents of messages or context as you step through would be interesting.

Jon has posted on debugging orchestrations (in IL) with an ILDASM/ILASM loop, and had also discussed building your orchestration assemblies manually (using xsharpp.exe).  (He correctly noted these approaches wouldn't generate anything supportable, but they work for spelunking.) 

I wanted to suggest something a bit different - I wanted to go back instead to the venerable BTS File Dump utility that Charles released in May of 2004 (before the GenerateCSFiles registry key was discovered...) and propose a different technique for symbolic debugging.

First, install Charles' BizTalk File Dump utility - you can download it from here.  Fire it up, and change the output path in the utility to something easy, like c:\temp\BTSFileDump.

Here is the Edit/Debug cycle...(Start by making sure the file dump utility is running, and click the "Start dumping files" button.)

1. Build your orchestration project (or whole solution if need be.)
2. Do a Ctrl-Shift-F (Find in Files) in Visual Studio, and change the "Look in:" folder to c:\temp\BTSFileDump
3. Search for something in one of your expression shapes, say, "MyClass.Execute".  The correct generated file (that the file dump utility grabbed) will appear in your Find Results - open it up, and set a breakpoint.  (Not on the xml designer portion - on the actual code!)
4. From the Debug menu, choose Processes and attach to BTSNTSvc.exe.  (Have more than one?)  Choose CLR debugging only - not native.  The symbols should be loaded automatically - no need to copy PDBs to the GAC.
5. Trigger your orchestration however you normally would.  Bask in a picture like this:  (Puts a Petzold-style WindowProc to shame...) 
   
   
   
6. Use QuickWatch to examine message contents/context, if you like - you'll be interested in expansions like this one (where sampleRequest is a message in the orchestration.)
7. Find your problem, Debug-Detach All, and fix the problem in the orchestration.
8. Click "Delete all files in output path" in the file dump utility (to avoid duplicates) and rebuild.  Repeat the process if you need to.  (To save time, consider an external tool that just re-GACs the orchestration assembly and resets the host process.  See here.)

Note that this technique will work in a production setting.  You could copy the PDBs and sources to the production server, and use DbgClr.exe (in the Framework SDK) or cordbg.exe to attach to the appropriate host process.

Happy debugging...

Andy Morrison wrote about a technique for identifying the correct host instance to attach to when debugging components associated with orchestrations.

A potentially easier solution is to keep perfmon running with the counter shown below (BizTalk:Messaging/ID Process - all instances.)  The counter values will update every time a host instance recycles.  The Debug-Processes dialog in Visual Studio will show you (and allow you to sort by) process IDs to make this easy. 

Then put PerfMon in "report view" to easily see process IDs by host instance:

There have been several folks who have discussed how to create messages "from scratch" within an Orchestration context - you can read Matt's thoughts and check out a BizTalk documentation excerpt. This is a common question, and I had an additional technique I thought I would share... 

Background: When you have a schema that has many promoted properties (or distinguished fields), or many elements that can be set via xpath expressions easily, it can be useful to simply start with a "template" document instance and populate the element content that you are interested in. 

In this situation, you will often have a "Message Assignment" shape that looks something like this:

xmlDoc.LoadXml("<ns0:BizTalkSampleS3 
      xmlns:ns0="http://BizTalkSample.Schemas.BizTalkSampleS3">
      <SomeElement></SomeElement></ns0:BizTalkSampleS3>");
someMsg = xmlDoc;
someMsg.SomeElement = "some content";
// (or xpath(someMsg,someElementXPath) = "some content" if we don't have a 
// distinguished field.)
   

One disadvantage of loading up "template" xml documents from either expression shapes or code (via XmlDocument.LoadXml) is that those xml fragments can get easily "lost", and are hard to update early in the development cycle when schemas may still be in flux.  Loading the template files from the file system is problematic because the question arises "where should I store these files, so that I can find them in any environment I deploy to?" (Solvable, but a hassle.)

Instead, why not embed the template xml documents as assembly resources?  For those unfamiliar with that process, I have a short tutorial here (& a helper class.) 

1. You will need a C# project as part of your overall BizTalk solution.  Place your template xml file(s) in the directory corresponding to this project, and add them as an "existing item" to the project. 
2. Select this file within the Solution Explorer, and within the Properties window, select "Embedded Resource" as the "Build Action" as shown here:

    

3. Place this class (text here) within the same C# project that houses the resources you have added.
4. To construct a message, drag out a "Message Assignment" shape, and within the associated expression write some code like the following.  Simply pass the file name of the template document as an argument to GetXmlDocResource (or GetStringResource.)
   

   sampleUsingTemplate = 
      BizTalkSample.Components.EmbeddedResourceCache.
         GetXmlDocResource("BizTalkSampleS3_output.xml");
      // Populate the "rest" of the message with distinguished fields, promoted 
      // properties, xpath expressions, etc.
      sampleUsingTemplate.SomeElement = "foo";
               

The class I have supplied will cache the loaded resources in a hashtable for performance sake, and allow you to load resources as both strings and XmlDocuments.

A last thought: Many people ask, "Why can't I just create a message using a new operator or a default constructor of some sort?" Well, because few XSD schemas sufficiently constrain the set of valid instance documents enough for that to be useful - what form would a "default message" take? (Would it have the optional elements you need? Some elements that you don't want?)

Enjoy - feedback appreciated!

Just a few notes on what I'll be up to in the next month or two...

Do you use the Deployment Framework for BizTalk?  Or just have general questions on automating BizTalk deployments?  You can attend my session at TechEd 2005 - Friday June 10^th, 10:45am to 12:00pm in the BPI Cabana, where I'll be doing a talk on those topics...

I'll also be speaking at the Microsoft DevCon event on my "other favorite" topic, Windows Mobile.  The focus will be on what is new for Visual Studio 2005 in the mobile arena...The conference will also be covering the new Team System offerings, ASP.NET 2.0, and quite a few other VS2005 topics.  Check it out...