Pre-Prep
**Migration from BTS2006 (not R2) straight to BTS2010 is not officially supported **
Need to consider making another machine (maybe virtual) available to developers requiring BTS, if pre-upgrade code is to be supported, this way pre upgrade code can be maintained and post upgrade development continue in parallel. Two sets of staging environment may also be required
BTS2010 requires SQL2008R2.
It is a good idea to script the setup and configuration of BTS for the new machines including hosts and host instance.
Consider existing source code and what fits with your branching strategy.
It’s helpful with a large set of BTS solutions, if build and deploy are fully scripted via MSBUILD or other.
Upgrade notes
1. We elected to upgrade one VS solution file at a time, starting with the “core” solutions and working up the dependency tree.
2. The upgrade is started by opening the VS solution in VS2010 on a development machine with BTS2010 installed
3. The wizard will prompt about source control bindings we elected to always “use solution” – this makes sense as the TFS bindings in the existing solution (were for us) quite correct.
4. We chose to read first then click over any project file errors and warnings RE change of framework to .net
5. Once the BTS projects are upgraded, the project files become proper MSBUILD files (as per regular Visual studio projects) however a BTS assembly is required to run in the .net 4 runtime so the project target needs to be .net v4 – which will happen as part of the upgrade, but note that other referenced .net projects that are part of the solution will not necessarily be automatically upgraded to framework v4, however if these satellite project(s) – for example .net helper assemblies - have a direct reference to any BTS artefact (XLangs for example) then they too need to be moved to v4 - you should get a compile error otherwise.
6. We decided not to move other shared projects, those without BTS artefacts to the new framework version (at least for now), partly to contain scope and partly to ascertain any impact to legacy systems. In the future we may upgrade where there’s justification.
7. Once the wizard completes review the report, do not be surprised if some projects are “skipped” this will be projects previously “upgraded” or projects the wizard considered should be skipped – i.e. don’t require any change.
8. Important note: The upgraded BTS projects will have an assembly-info file generated in the usual place for a c# project (“properties” folder), this has an additional line “[assembly: Microsoft.XLANGs.BaseTypes.BizTalkAssembly(typeof(Microsoft.BizTalk.XLANGs.BTXEngine.BTXService))]” which is very important for deployment. However we found this line will not be added if the assembly info is subsequently generated (by editing project properties) …
9. The important thing to remember is to add assembly-info file into TFS, it won’t be automatically we were not previously able to do this for BTS projects as the assembly info would get re-generated for BTS2006 project. We’ve found the quickest way to get a new file into TFS is
a. Show all files on the project
b. Right click “exclude file” – it’ll now show ghosted
c. Right click “include file” back into project, which will force it to be added into TFS
10. We have had some problems with web references, specifically un-typed services – by this I mean services with message payload which equates to “any” or “xmldocument. In BTS 2006 such messages might have been shown in the proxy as “xlang.basetypes.any”, in the past we’ve used this message type directly in map “btm” file input/output definitions (note that we use custom xml – so we’re not really using the mapper at all, which is why this works. The problem is that if you allow this “any” type post upgrade then the project and map will build fine, but once deployed your BTS install will be corrupted, the Management console will break and you won’t be able to view deployed applications and artefacts. There are two options
a. Re configure your BTS install (which will scrub out the databases etc)
b. Find the map definition in the relevant BTS database and table then delete it, this will allow you back into the management console and you can uninstall the affected BTS application
11. You can update an existing project web reference (you know the thing we used in 2006 before service refs were inventedJ) and you can re-add an existing web reference via the “service reference” dialog, advanced options.
12. Check the build option for each file in a BTS project web reference post upgrade, some files will not need to be compiled and some will, the upgrade can lose this compile flag on these assembly files.
13. The upgrade will change some web reference namespaces, this means an edit is required anywhere a web ref artefact was previously defined. To identify this compare the namespace before and after upgrade, it’s a bit of effort and how much may depend on how deep into you’re code the proxy is used.
14. If you get some issue which just doesn’t seem to have a logical explanation, please repeat on another machine before spending too much time, we’ve found issues like this that are really non-issues and a result of a single machine.
15. File locking in VS seems to be a big issue when you build more than once, all project references should have “copy local” set to “true” but even here it still happens, closing and re-opening works the best, but there may be other options (can close file handle in procexp for example or utilise an un-locker tool).
16. Thanks to my colleague Jeremy: If the odx file (say ” myorchestration.odx”) opens as text and not in the designer post upgrade check for this in the owning project file
<XLang Include="BookProvider.odx">
<SubType>Designer</SubType>
</XLang>
</ItemGroup>
**Remove the line : <SubType>Designer</SubType>
Deployment
As part of the upgrade the BTS projects will become MSBUILD type, any new BTS project will have the build config options of Debug|Release, however the wizard does not change existing projects; we had made the decision to be consistent and change the existing upgraded projects build config options now. We found the most efficient way to do this in the open solution (post upgrade) – was to multi select all affected BTS projects in the solution explorer tree (those upgraded) and “unload” them, you can then right click and open each as xml, once all are open do a find and replace for “development” to “debug” and “deployment” to “release” this will change everything required in a single step, save files, close them and then multi-select those unloaded projects and reload back into the solution. Then check all projects in the solution “config” manager window should now show “debug”.
