As I previously wrote, we are using BizTalk Deployment Framework to deploy webservices for our BizTalk applications.
Now I wanted to make sure that the application pool on which these webservices are running is set up correctly, even though we don’t manage these ourselves.
Since the BTDF is built using MSBuild, we can use MSBuild command to execute custom applications and commands, and I decided to use this functionality for my purposes.
Here is the code I use for this, place this after the last ItemGroup in your .btdfproj file.
This particular piece of code sets the runtime version and pipeline mode of our application pool, but you can pretty much use this with any command.
<!-- Set AppPool .NET version -->
<Exec Command=""C:\Windows\System32\inetsrv\appcmd.exe" set APPPOOL /apppool.name:"BizTalkBasicHttp" /managedRuntimeVersion:v4.0 /managedPipelineMode:Integrated" />
For our current customer, we have both WCF and SOAP webservices we want to expose, however IIS does not allow these 2 different types to live under the same website.
Therefore, I would have to create one of the webservices in a non-default website.
I wanted to use the BizTalk Deployment Framework for this, to make deployment easy, and to make sure the webservices would always be deployed to the correct website.
After some research, I found out this can be done by adding the following line to the first property group in your .btdfproj file:
Here you only have to change the 2 to the ID of the website under which you want the webservice to run, which can be found by opening the advanced properties of the website in IIS Manager.
Today I ran into a small problem with my PortBindingsMaster file.
We use the BizTalk Deployment Framework to deploy our applications.
On one of our WCF-HTTP ports we want to set the password from the SettingsFileGenerator.
I exported the PortBindings from the BizTalk administration console, prepared this for the BTDF, created a placeholder for the password, and set the password in the SettingsFileGenerator file.
However, after deploying the application, the password was not set on the port.
After some research, I found out that the PortBindingsMaster had this for the password:
The cause was the following, which means the password is hidden:
To solve this, we have to tell the PortBindingsMaster file that this is a plain-text password, by changing it into this: