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.



posted on Monday, December 18, 2006 2:30 PM | Print


# re: I discovered something interesting today...
Posted by Mitch Denny on 12/22/2006 5:31 PM
Hi Mark, the non MSBuild project system for BizTalk really frustraites me. What is more concerning is that the team doesn't seem interested in fixing it.
# re: I discovered something interesting today...
Posted by Mark on 1/4/2007 12:15 PM
I dont see it as a problem. Its just a pragmatic limitation of software engineering. The BizTalk product group could build a compile system for BizTalk, but that would be thousands of hours of engineering time, and the reality is that the current system is entirely adequate for the vast majority of users.
# re: I discovered something interesting today...
Posted by Mitch Denny on 1/4/2007 2:32 PM
Except for people who want to use their enterprise class messaging and orchestration product with their enterprise class version control and configuration management tool.

You can't get BizTalk 2006 projects building under Team Build in TFS without intervention and any class libraries included in the same solution end up being built outside of Team Build. The net effect is that BizTalk is not a good citizen when it comes to the _standard_ build system from .NET 2.0 onwards.
# re: I discovered something interesting today...
Posted by Felicity on 5/25/2007 8:30 PM
boring, this is not interesting at all. You tricked me.
Post Comment
Title *  
Name *  
Comment *  
Please add 8 and 1 and type the answer here: