Have you been getting an intermittent error similar to the following during a TFS Team Build execution (within the CoreGet target) ?:

Access to the path 'C:\Documents and Settings\tfsbuild\Local Settings\Temp\TFSTemp\4580{#$@;._}808' is denied.

If you look around, you will find a few folks who point at antivirus software as the culprit, but in our case it turned out to be the disk defragmentation service…

 

I sat down with Jeff Brand from Microsoft to discuss “BizTalk for .NET developers”.  We touched on how BizTalk fits in with a typical SOA effort, dealing with the learning curve, typical usage scenarios, and several other topics.  Great fun.  You can grab the MP3 here if you like.

I still can’t quite believe we dared to wade into this topic – but Jeff Brand (Microsoft) hosted myself, Rocky Lhotka, Matt Milner, and Jason Bock for a podcast that hit on REST, web services, tooling, and a few other loosely connected topics.  It was fun to do.  I must have been sitting closer to the microphone – I’m the loud voice, for better or for worse.

Find it here.

This bit of documentation explains that when you want to send a message out over the MQSeries adapter and receive a correlated response, the typical pattern is to:

1. Generate a value for the MQMD_MsgID property on the outbound message
2. Set the MQMD_CorrelID property on the outbound message to that same generated value, so that your “Send” shape can initialize a correlation that refers to the same property that will be present on the message you receive.
3. Send the message (initialize correlation with MQMD_CorrelID)
4. Receive the response (follow correlation with MQMD_CorrelID)

This assume that the destination system is following the usual pattern of setting the correlation identifier on the reply message equal to the message identifier on the request message.

Great.  Except when you don’t have the luxury of specifying the MQMD_CorrelID message on the outbound message to a value of your liking.  This occurs when you’re using a CICS bridge, or anything else that requires you to set the MQMD_CorrelID property to IBM.WMQ.MQC.MQCI_NEW_SESSION (signifying a new session interaction…)

In this case…you might be attempted to use the other pattern suggested here.  In this case, you engage in a solicit-response interaction with the adapter – where you send your request message and receive an immediate reply that contains a message with BizTalk_CorrelationID populated as a context property.  The message ID has also been generated for you.  You are then supposed to do a “dummy send” to initialize a correlation based on the BizTalk_CorrelationID property (sigh), and then follow that correlation with another receive shape that is the actual transaction response. 

To see this in action, see SDK\Samples\AdaptersUsage\MQSeriesAdapter\MQSCorrelationSetOrchestration under your BizTalk installation, or see the orchestration here.

Unfortunately, this design lends itself to a race condition.  The response coming back can occur prior to your correlation being initialized by the “dummy send”, resulting in a routing failure.  (This isn’t hypothetical – I just spent some time helping someone debug this issue.)

To work around this, you could try to do content-level correlation instead (i.e. use a promoted property in your request and response content.)

Wayyyy back in November of 2006, I wrote about a bug in BizTalk 2006:

This bug is encountered when you attempt to start a BizTalk 2006 application definition with orchestrations that have been bound to different hosts.  (Say, OrchA in HostA, and OrchB in HostB.)  After the application has been deployed, the first time the application is started (and 'orchestration start/enlist' is included in the start options) you will receive an error that looks something like this:

Microsoft.BizTalk.ExplorerOM.BtsException: Could not enlist orchestration 'BizTalkSample.Orchestrations.Echo,BizTalkSample.Orchestrations, Version=1.0.0.0, Culture=neutral, PublicKeyToken=05a4a8d4071035d9'. Could not enlist orchestration 'BizTalkSample.Orchestrations.Echo,BizTalkSample.Orchestrations, Version=1.0.0.0, Culture=neutral, PublicKeyToken=05a4a8d4071035d9'. Value does not fall within the expected range.

There was a fix for this bug  back at that time, but somehow it crept back in (even in R2.)  The KB number for the problem is the same, however (KB927052) and a fix is available.

Minor update to the BizTalk naming conventions here.  The big thing is that for a long while now I’ve thought physical send/receive ports should be named with just a plainly-worded phrase that will be as transparent as possible to operations staff.  (Whereas, back in the days of BizTalk 2004, you wanted something brief enough to fit in a HAT column…)

Team Foundation Server 2008 provides the ability to specify a “remote” Sql Server Analysis server as well as a remote Sql Server Reporting server.  Normally, your Analysis Server is located with the data tier, and the Reporting Server is located on the application tier.  (Of course, everything can be collapsed on a single physical tier as well.)

However, by editing the “msiproperty.ini” file within the “AT” directory of your installation media, you can customize this.  The relevant keys are VSTF_RS_SERVER (reporting) and VSTF_AS_INSTANCE (analysis).  See the Team Foundation 2008 installation guide for details.

What you should know, however, is that apparently Reporting Server instances are not really supported.  If you attempt to specify an instance name in the VSTF_RS_SERVER property, the installation will fail.  This property needs to refer to a server name only.  TFS 2008 apparently expects the instance name to match the data tier instance name (a strange assumption.)  If that doesn’t work, it tries the default instance.  (After that, it will try the first instance it finds…so you might see “WARNING: Selecting the first instance name of…” in the installation log.)

According to this, you won’t see a change in this behavior with TFS 2008 SP1…

I have a few clients that would like to see TFS make use of an enterprise Reporting Services infrastructure (rather than spinning up a new reporting server…)  If you do as well, this is something to keep in mind.

Update: Slides from the talk we gave are available here.

I’ll be doing a talk with Geof Lory about Team Foundation Server and Application Lifecycle Management (ALM) at TechFuse this coming Tuesday (February 26^th, 2008)…

Looks like a great event all in all for those in the Twin Cities!

So, I should have moved the BizTalk Deployment Framework to CodePlex long ago, but better late than never.  Find it here.

A few small items:

• Better support for 64 bit platforms in scripting operations
• Support for using the 64 bit isapi extension for http adapter
• A "startApplicationOnDeploy" property you can use to control whether your application immediately starts after deploying
• Bug fixes for the lightweight "Update Orchs/Comps" tool menu item
• Automatic creation of "ProjectPath" sso config item – that lets you know where your developer workspace or server installation directory resides.
• Better support for pre-processing bindings on developer workstations

But the cool item is integration of Tom Abraham’s improved “SettingsFileGenerator” – see here.  It moves the process of generating individual environment setting files from a VB macro inside of the SettingsFileGenerator.xls spreadsheet to an external command-line tool.

It also allows you to use the Excel XML format for the SettingsFileGenerator spreadsheet.  The Excel XML format allows for the ability to do standard diff/merge activities, a big improvement…

The way we’ve intergated this tool into the deployment framework allows you to treat the individual settings files as "transient" - they will get auto-generated by the deployment process now on the fly, and do not need to be version controlled or manually generated after spreadsheet edits. 

Enjoy!