Binding a Receive Port with a Service Window

Summary:  Forget about it.

Detail:  I had a need to set up a service window on a receive port (FTP, if that matters to anyone)…fine.  Went into my dev box and set it up through BizTalk Explorer.  Exported the binding file so I could script the production change and rebind the production environment using the new service window.  Well, the binding export utility doesn’t inlcude service window info on a receive location.  Why?  I don’t know.

I tried manually scripting the info in the binding file, but the import just ignores it.

I did some standard google and blog searching.  Google came up with about five posts where users were asking how to do this, but no one replied.  The blog search came up with a possible option, but not using standard scripting/binding files.  The option had to do with utilizing a custom tool this guy (Brian Loesgen) wrote which basically taps into the BTS Explorer Object Model and imports an XML file.  To use this (if it would even work) I would have to modify my deployment to call this component and manage the config file.  Not a big deal, no. 

But it’s less of a deal to just not worry about it and do it manually using my trusty BizTalk Management Tool (which I see has an update…I’ll have to grab that!)

(Edit:  I meant to point to this post by Leonid Ganeline where she was having the same problem and question, but no solution.)

.NET, BizTalk, Technical

Visual Studio Team System Deep Dive

I just finished a two day Deep Dive workshop on Visual Studio Team System (VSTS).  Summary:  Cool stuff.  I can’t tell you how many times I wished my current client would adopt this technology.

Even without the freebies (software, book, wireless mouse) this was well worth my time.  The instructor was Richard Hundhausen (blog found here) from Accentient.  Honestly, I haven’t heard of him or his company but I have nothing but good things to say about the experience.  He was a very good instructor with a very good knowledge of the subject.

The biggest wow factor for me came when we started looking at the testing capabilities included out of the box.  Yeah, I was impressed with the source control (maybe just because it isn’t VSS), and I was impressed with the build capabilities, and I was impressed with the integration with WSS, but the testing is what caught my eye.  They’ve really focused on providing some essential tools with the product that before you would have to look elsewhere and get another budget approved in order to purchase and implement.  These tools are included (with the proper version of VSTS, of course (which I won’t go into)) and very intuitive and powerful.  Granted, I’m no tester, but from what I’ve seen from other testing tools I was impressed.

Two downsides I learned:

First, licensing sucks.  Ashwin, the Microsoft Technology Specialist for the Western Region who said he would blog more going forward, explained licensing basically as such:  If you access data in Team System you need a CAL.  This means if you write, or expose an existing, Reporting Services report that hits the Team System DB, everyone who views that report technically needs a CAL.  Of course, they have no way of inforcing this, but that’s the licensing model.  I really hope they change that.

Second, typical first version gaps.  The integration with MS Project is limited, integration with Project Server non-existent (although apparently it is through a plug-in), nothing with Windows Workflow, SQL Server, BizTalk, Sharepoint Portal Server…those were the glaring gaps.  I’m sure they’ll be addressed in the future but they’re missing for now.  Oh well.

Oh, before I forget…Rich mentioned quite a few VSTS tools that are available.  He lists them on his Gadget page.

Now if I can only get on a project where I can use this technology before I forget it (or move into a less technical role!)