I’ve been asked quite often of late what the best way to keep track of BizTalk WCF Services is, and I have found myself changing my mind quite a few times on this one (the previous incumbent involved creating WCF Service projects in my BizTalk solutions but I’ve since gone sour on this idea) before I settled on an answer that I am reasonably comfortable with.   In this blog post I will share a practice that I have been following of late, and I hope it helps you or at the very least helps you think about how you will keep track of important artifacts related to BizTalk WCF Services that you publish.

To start with, let’s assume that you have already published a BizTalk WCF Service.  Add a new solution folder to the root of your solution or in your solution items folder and call it WCF Service Descriptions, then make a subfolder within it with the name of your service, and a subfolder within that with the version number of your service.  Make corresponding file system folders for these solution folders within the solution’s file system folder.  Now copy all the files from your published WCF service’s folder (the default directory for applications contained within the default website is c:\inetpub\wwwroot) into the solution folder corresponding to the version of the WCF Service and all these artifacts to your Visual Studio solution.

What we’ve got now is a means of tracking the changes made to a WCF service assuming the solution is checked into a source control.  Anytime you are updating the WCF Service and not incrementing the version, you can copy the files from the published WCF service’s folder into the corresponding location within your solution.  If you are incrementing the version of your WCF service then you can add a new folder corresponding to that version, and of course if your solution contains multiple WCF services then you can create separate folders for each service.

Not really rocket science at all, we’re just creating a structure within our solution to aid us to keep track of our WCF services.

Now for some value add.  One task I find myself undertaking very often is regenerating WCF Services to incorporate changes made to schemas or contained web methods.  Just like everything else I opt to be lazy and make life easier for myself by making use of a batch file.   I add a batch file called RegenerateWCFService.Bat to the solution folder that contains each version of my service.  The contents of the batch file are as below (the batch file should not need to be manipulated even for different services).

In order to use this batch file you must first ensure that the latest versions of your schemas have been deployed to the GAC on your development machine (this is very important as the WCF Service publishing wizard will generate schemas from the corresponding assembly in the GAC if it is available even though you manually point it at a dll anywhere on the file system).  Next run the batch file (either double-click it from the file system folder or run it from the command prompt) which will trigger the BizTalk WCF Service publishing wizard.  The wizard will initialize the web service’s metadata based on the WCFServiceDescription file in your solution folder, thus it will pick which methods are contained in your service and which schemas will be used.  If all you’re doing is regenerating your WCF Service based on new schemas then you don’t need to worry about overriding the default schema choices made by the wizard.

If however you want to change the schema used by a specific method or add a new method then of course you will need to do that.  Also note that even though the batch file points the WCF Service Publishing wizard at the WCFServiceDescription file, you will have to manually enter the target namespace of your service.

Another value add batch file that I keep in my solution folders is one that adds the web directory as a resource to my BizTalk application so that I can include it in exported MSI files to be included in deployments.  So once again I add a batch file called AddWebDirectory.Bat to the solution folder that contains each version of my service.  The contents of the batch file are as below (the BizTalk application name and source URL will need to be manipulated for each version of each service that you’re tracking).

Once you’ve published a new version of your WCF Service on your development machine then all you need to do is setup the batch file with the correct BizTalk application name and source URL and then run it and the WebDirectory will have been added as a resource to your BizTalk application ready for deployment.  If it is the first time that the service is being deployed to an environment then make sure you have a plan to setup the application pools and bind it to your virtual application in IIS (either include a post processing script that runs post install or plan for a manual step in your deployment).

If you’ve followed my instructions then your solution should look somewhat like the below.  I’ve also uploaded a copy of the solution that I used as a basis for this blog here so feel free to download it and inspect.

Please do let me know if any of you have better ideas or want to share any of your practices.