Watch the Video – BizTalk Automated Migration Tool Demo –
Microsoft has recently released BizTalk 2020 with lots of new features and enhancements.
There are many reasons to Migrate and can be broadly summarized as below –
- Avail Microsoft Support
- BizTalk 2016 Mainstream Support Ends – 1st November 2022
- All other previous versions like 2013R2, 2013 or 2010 etc. are long out of mainstream support
- Upgrade to latest software version of OS, VS, SQL & BizTalk
- Enhance BizTalk Environment
- For better infrastructure, performance, topology – HA/DR
- Avail New features
- BizTalk 2020 is loaded with new features of Hybrid Integration, Improvised Security (TLS1.2, GDPR compliance), Better Monitoring etc.
- Feature packs – Get new features faster, without waiting for new versions
- New Features for Developers and Administrators
- Move to Cloud
- Ability to run on Azure VM as IaaS
Microsoft has always attempted to make migrations as seamless and easy as possible by providing various options like –
- In-Place Upgrade – Only possible for N-1 version
- BizTalk Server Migration Tool – Which performs as-is migration by exporting artifacts from previous environment to new environment.
In-Place Upgrade is more like installing Cumulative Updates or Feature Pack. It requires minimum efforts and is mostly very seamless but has many limitations like only possible for N-1 version, rollback is tough.
BizTalk Server Migration Tool is provided by MSIT and is extremely helpful for as-is migration. On high level it exports MSI, Binding Files etc. from old environment and imports in the new environment. So all the dlls still point to previous version and nothing is changed.
For as-is migration, it definitely saves lots of time and efforts but has limitations like we can’t use new features or enhancements.
Therefore, many organisations prefer to use traditional method of code migration, which allows code upgrade, enhancement and possibility of modernization. But, this process is definitely very lengthy, time taking and resource intensive.
As a BizTalk Developer, Migration operations can be broadly categorized as below –
- Migrate to Latest Visual Studio – Open each solution in Visual Studio, by default it will upgrade solution to VS. It will also change the dotnet framework for all BizTalk projects.
- DotNet Framework Change – You may have to change DotNet Framework for Class Library Projects like Pipeline Components, Helper/Components, Custom Functoids, Custom Adapters etc. as they aren’t changed with VS Upgrade.
- Add BTDF or other Deployment Project (Optional)
- Rebuild Solution – Review failures and fix them.
- E2E Testing – End to end testing with all the parties involved in integration.
Performing all these operations for hundreds and thousands of applications is extremely tedious, time taking and resource intensive work. Every year companies spend thousands of man-hours just to perform these migration activities.
We attempted to reduce the efforts for developers by automating most of the routine tasks and only focus on things which really require human intervention.
We created a tool which solves top 4 problems and performs them as One-Click Operation.
Operations which can be Automated By Tool –
- Upgrade Solutions to Latest Visual Studio
- Change .Net Framework for all Projects
- Add BTDF Project to solution, with proper changes to Deployment.btdfproj file
- Rebuild Solution
- Detailed Logging of each operation for quick access to successful and failed solutions
Proposed Steps –
- “Browse for Folder with all applications”
- Get List of all the Solutions in that folder.
- Choose from Migration Operations –
- Upgrade – This will upgrade to latest visual studio version.
- Add BTDF Project – Adds BTDF Template project will all the files
- Build – Performs Rebuild of all the solutions/projects
- Change .Net Framework to Target Version – Select target Dotnet framework from the dropdown. All the projects will be migrated to this version, especially helpful for helper libraries like pipeline component, custom functoids, adapters and other helper components
- Detailed logging can be performed for each operation.
- You can also create folders and generate/move outputs to different folders like – “UpgradeSuccessful”, “UpgradeFailed”, “BuildSuccessful” and “BuildFailed”
This will allow developers to only focus on applications for which Build Operation failed.
Detailed Description of each operation –
Migrate Operation –
This operation is similar to manually Opening each solution in Visual Studio which performs –
a) Upgrade to latest VS and
b) Change of .Net framework (to default version) for BizTalk projects (only BizTalk Projects(.btproj) not class library projects(.csproj)).
It also creates Backup folder with migrated projects and log file – “UpgradeLog.htm” next to the solution file. You can also choose to delete the backup file, to save space if you already have another backup.
To perform this operation from tool you can use visual studio command line arguments –
devenv {SolutionFile|ProjectFile} /Upgrade [/Out OutputFilename]
Refer –
https://docs.microsoft.com/en-us/visualstudio/ide/reference/upgrade-devenv-exe?view=vs-2019
Build Operation –
Similarly, Build operation can also be performed by VS command line arguments –
devenv SolutionName /Rebuild [SolnConfigName [/Project ProjName [/ProjectConfig ProjConfigName]] [/Out OutputFilename]]
Refer –
https://docs.microsoft.com/en-us/visualstudio/ide/reference/rebuild-devenv-exe?view=vs-2019
Most of the errors in this step is related to missing reference of common libraries or helper projects/dlls.
Change DotNet Framework –
You can allow users to choose target framework from a dropdown and later upgrade all projects in solution to this version. These values can be fetched from App.config file.
Your tool can get the list of all the projects referred/present in Solution (Solution file) and later change their .Net framework for each of them.
Regular VS Upgrade option performs .Net framework changes only to BizTalk projects and that too only to default version.
Note – For BizTalk 2020 we found a bug with .Net Framework 4.7.2, so we decided to migrate all the projects to 4.8 version. This tool was extremely helpful in mass framework change.
It’s also extremely helpful for helper class libraries like pipeline components, custom functoids, custom adapters or C# Helper/Component projects which are not upgraded in Upgrade process.
Dotnet Framework can be upgraded just by updating the project files.
- In the project file, locate the entry for the target Framework version. Ex -if your project is designed to use the .NET Framework 4.5, locate <TargetFrameworkVersion> v4.5 </ TargetFrameworkVersion > in the <PropertyGroup Label = “Globals” > element of the < Project > element.
If the<TargetFrameworkVersion> element isn’t present, your project doesn’t use the.NET Framework and no change is required.
2. Change the value to the Framework version you want, such as v4.7.2 or v4.8.
You can also use Regex pattern replace –
string regexPattern = “<TargetFrameworkVersion>*.*</TargetFrameworkVersion>”;
3. Save the changes and close the editor.
Add BTDF Project –
In this step you can add a template of BTDF project with Deployment folder and all other files –
- Deployment.btdfproj
- InstallWizard.xml
- License.rtf
- PortBindingsMaster.xml
- SettingsFileGenerator.xml
- UnInstallWizard.xml
You can also update the Deployment.btdfproj file with many routine information like –
- ProjectName – Solution File
- Include Options for
- Schemas
- Maps/Transforms
- Orchestrations
- PipelineComponents
- Helpers – Components
- And many other options
These options can be read and populated by fetching project names or file’s extension from solution file.
For ex – If Solution contains projects with name as “Schemas” or files with extension “.xsd” then make IncludeSchemas as True.
Similarly, for Maps, Orchestrations, PipelineComponents etc. can be deduced either from name( if naming convention is followed for BizTalk projects) or file extensions like .btm for maps, .odx for orchestrations, .btp for pipelines etc.
Sample BTDF Template -
<!-- Deploy schemas -->
<IncludeSchemas>True</IncludeSchemas>
<!-- Deploy orchestrations -->
<IncludeOrchestrations>True</IncludeOrchestrations>
<!-- Deploy maps -->
<IncludeTransforms>True</IncludeTransforms>
Many sections like below which are mostly constant can be updated from App.Config file.
<!-- Deploy custom functoids -->
<IncludeCustomFunctoids>False</IncludeCustomFunctoids>
<!-- Deploy BRE -->
<IncludeVocabAndRules>False</IncludeVocabAndRules>
<!-- Deploy IIS virtual directories -->
<IncludeVirtualDirectories>False</IncludeVirtualDirectories>
<!-- Deploy NUnit tests -->
<IncludeDeploymentTest>False</IncludeDeploymentTest>
<!-- Deploy Log4Net configuration file named $(ProjectName).log4net -->
<Includelog4net>False</Includelog4net>
This tool has helped us in saving thousands of hours monotonous, repetitive and boring work.
Hope it helps you as well.
Feel free to get in touch in case of any query. Thanks.
Contact Me:-
@Gmail, @Facebook , @Twitter, @LinkedIn , @MSDNTechnet, @My Personal Blog
Related Article –
PLANNING MIGRATION TO BIZTALK 2020 – WHY AND HOW?
Contact Me –
Check out my other blogs –
Logic Apps Secure SQL Connection String in Azure Key Vault
While using SQL Connector in Logic Apps we don’t get a straightforward way to fetch/store connection string in Key Vault or in config. By default, the connection string we provide goes and sits in the Configurations as shown in the pics below and is in plaintext format. The regular process to use SQL Connector -…
Save Full File in SQL table Column (varbinary) and read the contents back in t
What if you needed to save full file as-is to a SQL Server table column. I ran into a similar scenario and had to save CSV Files in a table. For this we created a table with a column of type “varbinary” CREATE TABLE [dbo].[TableWithCompleteFiles]([SNo] [int] IDENTITY(1,1) NOT NULL,[FileName] varchar NULL,[FileContent] varbinary NULL) ON [PRIMARY]…
Export SQL Table content as CSV File to a File Location
Recently, I got a request to save the contents of the table to a File. Wroking Command – Above commands will fail with below error – Msg 15281, Level 16, State 1, Procedure xp_cmdshell, Line 1 [Batch Start Line 43]SQL Server blocked access to procedure ‘sys.xp_cmdshell’ of component ‘xp_cmdshell’ because this component is turned off…
Prashant BizTalk And Azure Integration Blogs 