0

Document!X .NET build performance

kendallmiller

02 January 2009 14:42

None

Follow

We noticed recently that the build time of our Document!X help went through the roof. Looking into it we found that it coincided with us adding several dependent libraries through ILMerge. Even though these libraries are treated as Internal (and even after we unchecked them from the Document!X build process manually) the build is much slower than it used to be. Is this an expected behavior?

Secondarily, is there a way to tell Document!X to never include internals? I was surprised when they showed up in our help file and I had to go in and manually hunt them all down and uncheck them. This concerns me because we're always managing our surface area, so we often move classes from public->internal as part of regular cleanup and I'm worried about having another place to check (particularly since Document!X is only on our build system)

• Facebook
• Twitter
• LinkedIn

2 comments

• 0
  
  Permanently deleted user 19 January 2009 05:13

  One of the larger chunks of Document! X activity is in resolving types and gathering information for inherited members. For very large assemblies this can slow down the build process even if the additional types are not documented.

  You can exclude protected / friend members on the Filters page in the Document! X Project Editor.

  Let me know if you need any more information at all.

• 0
  
  kendallmiller 27 January 2009 09:42

  We already had friends unchecked (but we include protected because of our types that people can inherit from). We have also unchecked in the "Included Modules" filter area each type that wasn't public (e.g. each internal and private type), but our observation is that generation time seems directly proportional to the total # of types regardless of visibility or inclusion. I'll send in our project under a support ticket.