There are many situations where we need to deploy WCF Services that we can use to interact with BizTalk, but if you’re constantly deploying to new systems, the process of manually creating and configuring them can become very time consuming and tedious. Leveraging the abilities of the BizTalk Deployment Framework (BTDF) we can automate this process along with your typical BTDF deployment.
In this guide we’ll step through how to configure BTDF to build the deployment of our existing WCF Services into the installer which BTDF creates for deployments.
In order to follow this guide it’s assumed that you have the following prerequisites:
- A BizTalk solution and environment with BTDF installed
- Already deployed WCF Services which you wish to replicate via deployment on the same machine
- A basic knowledge of BizTalk, WCF, and IIS
First up we need to move our services into our solution folder. Simply copy the folder for the service (likely located at wwwroot) into the main folder for your BizTalk solution (whichever is one level below the deployment folder is typical, but you can define specific locations if necessary for your deployment). Once the folders for your services are copied we can move on to configuring BTDF to know what to do with our services.
Open up the Deployment.btdfproj file located in the Deployment folder, in here we’ll make some changes to existing sections as well as add some new ones.
First off we need to update the first <PropertyGroup> section, at the bottom of the section add the following:
<SkipIISReset> might already be there, if it is, just make sure that it’s set to false, we want our deployment to automatically restart IIS so that our services are ready to go once the deployment process is finished running. <IncludeVirtualDirectories> enables us to deploy our service folders that we added to the solution. Next we’ll define for BTDF what folders to deploy and how to deploy them as services.
Somewhere below the first <PropertyGroup> node, create a new <ItemGroup> section. In here we’ll define which virtual directory to pull from and how it’ll be defined, path wise. The <ItemGroup> will contain a <VDirList> section with in it, containing the following nodes:
- <VDir> – Defines the relative path for the service to deploy to (i.e. http://localhost/VDirValue/Service1.svc)
- <Physdir> – The relative path from the deployment folder that points to the physical folder to deploy (containing the service files)
- <AppPool> – The name of the Application Pool to use upon deployment
- <AppPoolNetVersion> – The version which the application pool is running under (generally v4.0)
Finally we’ll need to add configuration for the application pool’s username and password. Look for the node <PropsFromEnvSettings> contained within an <ItemGroup>, if it doesn’t already exist simply create it, it will look something like this (note, if you’re not configuring SSOUsergroups here, simple remove them, we’re concerned with VDIR_UserName and VDIR_UserPass):
As mentioned before, VDIR_UserName and VDIR_UserPass are important to us. They correspond to the login info for the Application Pool User, allowing the services to run under that app pool. We can define these values using the SettingsFileGenerator.xml located in the Deployment folder. This can also allow us to define specific user/password combinations based on which environment we would like to deploy to:
And that’s it! Upon deployment the services will be included in the deployment process. You can now find the physical folders within the install folder for the application located within the system’s Program Files.