I personally only have the actual BizTalk items (schemas, pipelines, maps, orchestrations). And of course, the solution might also have other projects like custom external DLLs, custom pipeline components, test projects, .NET 3.X projects, all the stuff that will eventually end up in a DLLs or running in IIS.
But my question is, do you also include the binding files, strong name key files, documentation, etc. in your project? An email from a friend has prompted me to write this. I personally think that while these files definitely have to be kept in source control together with the solution files, they shouldn’t be added to the projects.
I also include the strong name key file in the project.
I do not store the binding files or other resources in the project. I create an msi package for each application ( I am only thinking BTS06 here) that includes all the resources e.g. binding files for each environment, assemblies, web directories, preprocessing scripts to add hosts, host instances and handlers and finally a post processing script to clean up. I then store the msi.
Thanks Mark, I also agree that adding all the extra files to the MSI and then storing the MSI is better.
I only include the strong name key in the project if the key isn’t a shared one, otherwise I would keep it in a central location in source control.
Well, I also never included all the project artifacts in my BTS projects but it is so easy to manage. From within VS I can go to the solution explorer and see all the binding files listed. I can double-click to open – then edit and save – all from one interface.I can have many docs open in different tabs and that makes it very easy to work with a project.
So I personally like the idea of having them all there – as long as it isn’t a hinderance – like bloating the DLL or something – which I am led to believe it won’t do.
With regards to Strong Key files and Binding file, I keep these located in the solution, not the project.
I also maintain (local) dev, smoke, uat and production bindings in the solution (so under source control) for ease of maintenance.
In contrast to the comments above, I do not store the MSI as this is generated from the build process as and when required (however production MSI deployments are archived).
We keep the MSIs in a release folder on a shared location that gets backed up overnight, but not in source control.