- This topic has 2 replies, 1 voice, and was last updated 8 years, 4 months ago by
.
-
Posts
-
-
Hi all,
Our biztalk dev team has come across an issue here within our new dev environment that is becoming quite time consuming.
Let me try and explain the problem as best as I can.All of our source code (VS solutions) is stored on a Team Foundation Server (TFS). We compile the solutions (run a build) on the server when required, which can be onece or multiple times a day. The build is done via MSBuild.
Basically the problem is – after running a build on the TFS server, the MSBuild updates version numbers on assemblies, but the version numbers embedded in BizTalk artifacts (i.e. pipelines, maps, binding files) don't get updated.
After a build on the TFS server the versions of assemblies change (i.e. in our case a new number is given every day based on current date or if an assembly is built multiple times during the day only the revision number is incremented).
But in BizTalk artifacts (such as pipelines, maps, and binding files) the VERSION NUMBERS of artifacts referenced within them don't get updated…without manually editing the artifact via a text editor and changing it.
E.g. A schema is referenced from within a pipeline (i.e. added to a dis-assembler for example), or an externally referenced assembly is used from within a map. Also has this issue with BizTalk project files (the version of the assembly the project is for is hard coded in the proj file).So after the build the BizTalk artifacts that reference other artifacts within them stop working because they look for assemblies that no longer exist (i.e. old assemblies that now have a new version number).
Specific Example:
– For example we have an assembly called Bryn.BizTalk.Schemas.dll (Version: 1.0.070102.0) and it is used within another assembly Bryn.MessagingEngine.BizTalk.Pipelines.dll (Version: 1.0.070102.0)
– After a build on the TFS server the version of Bryn.BizTalk.Schemas.dll changes to 1.0.070102.1 but Bryn.MessagingEngine.BizTalk.Pipelines.dll (Version: 1.0.070102.1) is still looking for Bryn.BizTalk.Schemas.dll (Version: 1.0.070102.0) which no longer exists.
– Therefore when it comes to deploying these artifacts to BizTalk it fails because we end up with missing assemblies.Would anyone know anything about this problem in a similar dev environment??
Please let me know if there's any questions.Any help appreciated.
Thanks for your time!
Regards,
Sergiy -
Sergiy,
why do you allow the build to bump the version number all the time? (It's just an attribute of the assembly, so you choose its behaviour). I usually only change version numbers when something significant has changed. For small projects you can do this manually, for larger ones you could have a script.
Or perhaps I misunderstood your issue?
John D.
-
As JohnD said… I’ll second it.
BizTalk does not fit into a standard .net build model. You will have endless problems doing anything that changes the .net version numbers on a continuous basis.
I have seen this requirement before and it’s possible to do using find and replace scripts on the raw text file of the maps and pipelines referencing .net assemblies. I just question the value of this since I think a cleaner approach is to version the MSI’s you use for deployment. (you lose side by side version ability but that’s usually ok since BizTalk doesn’t play will with that either without additional effort)
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.