The BizTalk Server Documentation Team is looking for customer input on the documentation of the operations topics.

Specifically they said they "want to know what is missing, incorrect, unclear, or just needs work in any of the Operations topics".

Go here for the survey:

http://www.surveymonkey.com/s.asp?u=32373055498

Be as explicit and clear as you possibly can.

Don't miss this opportunity to help improve the documentation.

Mark

and as you well know, when people use the word "interesting" in a sentence like that its usually a euphemism.

Let me start off with some background. The Visual Studio BizTalk project system is different from the native Visual Studio project systems like C# and VB. Ok, so thats not a startling revelation, but bare with me. The BizTalk project system uses Visual Studio as a shell. Visual Studio gives the GUI front end plus build and compile functionality and thats about it. If you worked on BizTalk Server 2002 you will recall that the Mapper and Schema editor were stand alone tools at that time.

So as such, the BizTalk developer tools components are dependant on the functionality as supplied by the Visual Studio product. So now that i have you nodding along with me lets cut to the chase. There is a limitation in the CSharp compiler that goes like this: the total size of all strings in a module must be under 0x00ffffff characters. Yeah, I can't read hex either but my windows calculator tells me that its 16777215. Henceforth we'll call this limitation the "16mb limitation". Great, you say, none of the file sizes of my maps are 16mb so i don't have a problem. Wrong! you jumped to the conclusion too fast. Lets slow down while i link up the dots. The BizTalk project system during the compilation process serialises the mapper XSLT and schema XSD code to .cs files. These .cs files then get passed to the Visual Studio compiler for the creation of the .dll assemblies.  

In the example I was playing with, the Mapper project had 4 rather large maps which referenced 5 rather large schemas from a separate project. On the file system the total size of the 4 .btm files was only about 3MB's. Each of the schemas was between 500Kb and 1MB. And of by now you should be seeing where i'm going with this. During the compilation process these 4 maps were serialised out to a total of greater than 16MBs. To use a concrete example: one of the .btm files was 1.2MB on disk, but during compilation it was serialised to 6.2mb. You have four maps like that and bingo!

So lets change gears here for a second and talk about why.

If you and I were on a .Net project together where i was doing my developer thing and you discovered there were more than 16MBs of STRINGS in my C# project would you

a. whack me with a baseball cricket bat.
b. ask for an immediate transfer to a different project team
c. quit the company immediately because any company who hires such incompetance is going down the gurgler.

Of course this was a trick question. All of those answers are a valid course of action.

So you can see why the Visual Studio team has a limit of 16MBs of strings in a project. A .cs file is not where you do your word processing.

Ok, great, so heres the crux of the issue:

• In a plain Visual Studio project a 16MB limitation on strings is very valid.
• The BizTalk project system uses the Visual Studio compiler for creating the assemblies.
• BizTalk mapper projects can have large auto generated strings made up of .xsd and .xslt code.
• If your maps and schemas are big enough or you have enough of them in a single project the Visual Studio compiler can't compile them because of the 16MB limitation.

You'll know you've hit this issue when during compilation you get errors like this:
error CS0583: Internal Compiler Error (0xc0000005 at address 53624FD6): likely culprit is 'CODEGEN'

The resolution is to break out the maps and or schemas into separate projects. Theres really no other way of engineering around this limitation.

Thanks for reading.

THIS BLOG DOES NOT CONDONE WORKPLACE VIOLENCE.

There are certain myths that float around the IT industry that defy rational thought. I was recently exposed to one of these myths in a conversation and so I thought I would blog about it in the hopes that I could dispell it somewhat.

Risk adverse organisations will often say that they want the latest version minus one (n-1). The idea is that by going with the latest they are somehow exposing themselves to some sort of increased risk of newly introduced bugs. The implied assumption is that older versions are more "stable" and therefore less risky.

This is completely wrong. The code base of BizTalk 2006 is built directly on top of the BizTalk 2004 code base. So BizTalk 2006 = BizTalk 2004 + All BizTalk 2004 Hotfixes + 2 years worth of design improvements.

So by going with BizTalk 2004, you are depriving yourself of both the design enhancements of the newer version but you are also getting a inferior code base. Now someone somewhere will take that last sentence to mean "BizTalk 2004 is a inferior product". Thats not what I said. I said, BTS2004 is an inferior CODE BASE in COMPARISON to BTS2006.

I've also encountered customers who apply the same thinking to Service Packs. They don't want to apply the latest for some perceived added risk. My response to this is that you are far more likely to hit bugs in the down level version than you are to hit a problem CAUSED by the application of a service pack. Maybe this perception comes from the bad old days when the engineering that went into service packs was less robust. I don't know. But what i do know is that, service packs should be applied asap to lessen the risk of hitting bugs. To put that in other words, Service packs lessen risk.

While we're on that topic...BTS2004 SP2 is highly recommended but be aware that the install modifies the database schema for the message box and tracking databases. If you have large amounts of data in the tracking database, the application of the service pack could take a looong time. One of my customers reported 12+ hours. So this is something you will want to test before trying to apply during a weekend maintenance window. And when you do test this, make sure the test system you are using actually will reflect what you have in production. That is, if you production tracking database is 5 GB, then your test system should have 5 GB in the tracking database also. Or alternatively, archive tracking first before the upgrade and not have the problem.

I'm a big fan of having an identical UAT environment which you can install independantly for production and then do a promote / demote switcheroo and thereby cut over to the new version with the flick of a switch. No risk of borking production during a maintenance window if the UAT (the new production) was prepared and tested earlier.  I'll try to make a comprehensive post on this at a later date.