tfabraham
commented
6 years ago [bstottt@6/13/2014] I figured this out.
I put a line in my SettingsFileGenerator.xml that included my environment name. I then created a powershell script that took the ENV_SETTINGS variable as the input parameter and parsed it and grabbed the EnvironmentName and updated the ActivityName and ViewName of the Activity.xml and TrackingProfile.btt. This ran as a CustomPostExportSettings target in the deployment project. This way if multiple environment share the same SQL Server instance they won't "bump" into each other on install with the same name.
I have a somewhat complicated Biztalk deployment. I have several environments that share a sql server instance. In my case there are 7 environments on the one sql server instance. The only issue I am running into with this is with BAM deployments. I can run the deployment framework on one environment and it is fine. On the subsequent environments it fails because there is already the DTS packages associated with that activity in SSIS. I tried to separate out my BAM activities on a per environment basis and put something like the following in my .btdfproj:
The issue I am having is that if I try and build a server .msi from the Visual Studio tools menu it doesn't process the settings before it exports the MyActivity.xml. I get errors saying the MyActivity.xlsx doesn't exist. Which makes sense but doesn't help me much.
If I list out all of the activities with multiple tags can I select at deployment time which BAMAcitvity.xml file I want to deploy?
This work item was migrated from CodePlex
CodePlex work item ID: '10648' Vote count: '1'