I was developing a large wrapper library for some classes from System.IO. I wanted to use the original documentation from mscorlib for my wrapper classes because the methods and properties only wrap the underlying components from System.IO. This is easily possible with the document include tag.
public interface IExample
{
/// <include file='relativepathtodocument.xml'
path='/doc/members/member[@name="ShowExample"]/*' />
void ShowExample();
}
But there is a bug in the latest msbuild version which can drive you nuts if you don’t know what to look for.
My first idea was to copy over the whole mscorlib.xml and then to provide xpath expressions for each wrapped method of the underlying System.IO component. The original mscorlib.xml from the .NET framework 4 is roughly about 9 MB in size. Now let’s see what happens when I build the library in release mode:
Visula Studio and devenv.exe memory usage shortly before compiling a release build
Start compilation
 |
 |
 |
 |
 |
 |
As we can see, the memory usage increases from 240 MB to almost 3000 MB! My quad core build machine with 4 GB RAM has huge problems keeping the other process running and my system is lagging accordingly.
When I reduce the size of the mscorlib.xml by removing all the xml documentation I don’t need in my wrapper library (remaining size about 700 KB) the memory consumptions looks like the following:
As we can see, the memory usage increases from 240 MB to about 550 MB. Let’s do some math (assumption 1 MB = 1000 KB, I know 😉 but it makes it easier to calculate 😉 )
First run
mscorlib.xml Size: ~9 MB
Memory devenv.exe before: ~240 MB
Memory devenv.exe after: ~3000 MB
Total memory increase: ~2760 MB
Relative memory increase: ~300 times the size of mscorlib.xml
Second run
mscorlib.xml Size: ~700 KB
Memory devenv.exe before: ~240 MB
Memory devenv.exe after: ~550 MB
Total memory increase: ~310 MB
Relative memory increase: ~440 times the size of mscorlib.xml
It seems that msbuild is loading the xml in the include tag for every include tag into memory before applying xpath to the xml! I cannot scientifically prove this statement but when I executed the first and the second run multiple times it behaved every time similarly.
