While trying to generate .chm/.HxS, using the recent September 2006 CTP release of Sandcastle, for one of the dlls, I got this error message.

Generating reflection information...
[W:\LVFW\Docs\HelpBuild\LavaDatasourcesCore\Sandcastle\Working\GenerateRefInfo.bat]
MRefBuilderStatic (v2.0.2459.30849)
Copyright Microsoft Corp. 2005
Error: Unresolved assembly reference: System.Configuration (System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a) required by Lava.Core

The help generation worked fine when I added System.Configuration.dll to the dependencies list.

System.Configuration is a .NET Framework assembly and is present in GAC. Ideally, it should have been loaded directly instead of adding it explicitly into the dependecies. Lava.Core has references to other System assemblies too, viz. System.dll, System.Data.dll, System.XML.dll, etc., but only System.Configuration.dll is required to be specified explicitly in the dependencies.

Please let me know if this is an issue with the recent release or I am missing something...

Please reply asap. Thanks.

hmmm, I remember this being a problem with the first CTP, not being able to resolve references to items that exist in the GAC. Double check to make sure that sandcastle has been updated???
Rick.

Rick is correct and Sandcastle does not resolve references to GAC. We do plan to address this in future. Sandcastle GUI written by Eic available at

Thanks for the reply.

But does that mean that the resolution issue is only with certain assemblies and not all? As I had mentioned, Lava.Core has references to other System assemblies too, viz. System.dll, System.Data.dll, System.XML.dll, etc., but only System.Configuration.dll is required to be specified explicitly in the dependencies.

Sanchit.

It's true that there are a handfull of assemblies (mscorlib.dll, System.dll, et al.) that are treated specially by MRefBuilder. They are always loaded from the location specified in MRefBuilder.config, and are therefore neither required nor used when specified by the /dep option.

We didn't choose this odd split in the way dependencies are handled, and were confused by it ourselves at first. It's an artifiact of the reflection library that MRefBuilder uses the parse assemblies, and the developer of that library assures us that it is necessary in order for his library to do something which was very important to us: be able to load and parse assemblies from of "foreign" .NET Framework version (i.e. a version different from the one MRefBuilder was compiled under).