Unable to resolve System.Xml (V2.0.50) reference

Topics: Developer Forum, User Forum
May 16, 2009 at 1:14 AM

When building the documentation for a Silverlight class library project, SHFB complains (Error BE0043) about the following unresolved reference:

MREFBUILDER : error : Unresolved assembly reference: System.Xml (System.Xml, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e) required by System.Xml.Linq.

despite the fact that I've added a reference to the correct DLL (i.e. the Silverlight one, V 2.0.5.0) located at "C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies\System.Xml.dll".  I've verified that the public key token of this assembly is in fact 7cec85d7bea7798e.  My GAC contains the version of System.Xml.dll for .NET 2 (v 2.0.0.0) only.

Can anyone shed some light on this?

-- Ravi B

Coordinator
May 18, 2009 at 7:21 PM

I'm not familiar with Silverlight so this is just a guess.  The assembly requiring System.Xml is System.Xml.Linq which is part of the base framework, not Silverlight (I didn't see an assembly by that name in the SilverLight folder).  As such, I would think that the System.Xml in quesion is the one from the base framework and not a copy from Silverlight.  You might try adding the .NET 2.0 System.Xml assembly as a dependency to see if that resolves the issue.

Eric

 

May 18, 2009 at 9:49 PM

Actually it's a Silverlight class lib, so there are no vanilla .NET 2.0 refs used.  The System.Xml.Linq namespace lives in the System.Xml.dll assembly (which is included).  It's weird, because the apparently offending assembly is in fact included.

-- Ravi B

May 19, 2009 at 3:30 PM

Eric, the problem was @ my end.  The SL project in question had "Specific Version" == true for the service reference to System.Xml.  Reverting it back to false fixed the problem.  Thanks.

-- Ravi B

Oct 27, 2010 at 2:55 PM

 

Ravi or Ed or Anyone --

Please help.

I am still getting the dreaded error "MREFBUILDER : error : Unresolved assembly reference: System.Xml.Linq (System.Xml.Linq, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)".

I tried setting SpecificVersion=False, as you note above Ravi, but I still get the error.

I am wondering if I can just set a switch in Shfb to "hide this sort of thing" because it is an assembly that I am not interested to document?

Is there any way to fix this?

The contents of my "LastBuild.log Begin" is below, FYI.

Any help is appreciated.

 

LastBuild.log Begin

 

<?xml version="1.0" encoding="utf-8"?>
<shfbBuild product="Sandcastle Help File Builder Utilities" version="1.9.1.0" projectFile="C:\Code\Team\Tapi\Tapi02.shfbproj" started="10/27/2010 10:22:00 AM">
<buildStep step="Initializing">
</buildStep>
<buildStep step="ClearWorkFolder">
Clearing working folder...
</buildStep>
<buildStep step="FindingTools">
Finding tools...
Found Sandcastle tools in 'C:\Program Files\Sandcastle\'
</buildStep>
<buildStep step="ValidatingDocumentationSources">
Validating and copying documentation source information
Source: C:\Code\DocProjectTargets\*.*
    Found assembly 'C:\Code\DocProjectTargets\Team.Framework.CommonSilver.dll'

Copying XML comments files
    C:\Code\DocProjectTargets\Team.Framework.CommonSilver.XML -&gt; C:\Code\Team\Tapi\Help\Working\Team.Framework.CommonSilver.XML
</buildStep>
<buildStep step="GenerateSharedContent">
Generating shared content files (en-US, English (United States))...
    Last step completed in 00:00:00.2500
</buildStep>
<buildStep step="GenerateApiFilter">
Generating API filter for MRefBuilder...
    Last step completed in 00:00:00.0781
</buildStep>
<buildStep step="GenerateReflectionInfo">
Generating reflection information...
[C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe]
GenerateRefInfo:
  MrefBuilder (v2.6.10621.1)
  Copyright c Microsoft 2006
  Info: Loaded 1 assemblies for reflection and 0 dependency assemblies.
MREFBUILDER : error : Unresolved assembly reference: System.Xml.Linq (System.Xml.Linq, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35) required by Team.Framework.CommonSilver
    Last step completed in 00:00:06.0000
</buildStep>
<buildStep step="Failed">

SHFB: Error BE0043: Unexpected error detected in last build step.  See output above for details.

</buildStep>
</shfbBuild>

 

LastBuild.log Begin

 

Thank you.

-- Mark Kamoski

Oct 27, 2010 at 2:57 PM
EWoodruff wrote:

...You might try adding the .NET 2.0 System.Xml assembly as a dependency to see if that resolves the issue.

 

Eric --

Please help.

I am still getting this error, as I note in my post above.

I want to try "dding the .NET 2.0 System.Xml assembly as a dependency" but I do not know how to do that.

Can you help?

Please advise.

Thank you.

-- Mark Kamoski

 

Coordinator
Oct 27, 2010 at 3:00 PM

This has come up before for the Compact Framework.  You may not be documenting it but it's a reference assembly that MRefBuilder needs in order to generate reflection information for one of the assemblies.  Silverlight is most likely similar to the Compact Framework.  While Sandcastle can produce documentation for Compact Framework assemblies, you have to take some extra steps to get it to find the references correctly.  The same is probably true of Silverlight projects.  I haven't used the Compact Framework or Silverlight so I'm going on info supplied by other users.  Here's the info for the Compact Framework.  Perhaps you can use it to get the Silverlight references working:

In order to document Compact Framework applications you also need to add a reference item for the Compact Framework assemblies.  These are usually located under the Visual Studio 20xx installation folder.  The easiest way to reference them is to add a reference item with a path similar to the following:

$(VS80COMNTOOLS)\..\..\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\*.dll

So, for Silverlight, you'd add a reference item the same way and then modify the path to point to the Silverlight assemblies.  If somebody can send me sample Silverlight project that they can't document, I'll see if I can get it working.  My e-mail address is in the About Box in the GUI and in the footer of the pages in the help file.  If you do manage to get it working on your own, please send me the necessary info and I'll include it in the SHFB documentation for the next release.  Thanks.

Eric

 

Oct 27, 2010 at 3:27 PM
EWoodruff wrote:

 

...If somebody can send me sample Silverlight project that they can't document, I'll see if I can get it working.  My e-mail address is in the About Box in the GUI and in the footer of the pages in the help file....

 

Eric --

As suggested, I have sent a sample Silverlight project for SHFB testing.

I used your email address listed in the >Help, >About, in Sandcastle Help File Builder GUI, version 1.9.1.0.

Any help that you can be is appreciated.

I am going to try your recommendation -- "for Silverlight, you'd add a reference item the same way and then modify the path to point to the Silverlight assemblies" -- but I am wondering if I add that in the target VisualStudio project being documented OR do I add it somewhere in the SHFB GUI when opening the file "MyDocumentation.shfbproj" there?

Thank you.

-- Mark Kamoski

 

Oct 27, 2010 at 7:30 PM
EWoodruff wrote:

 

...If you do manage to get it working on your own, please send me the necessary info and I'll include it in the SHFB documentation for the next release.  Thanks.

Eric

 

Eric --

FYI, I did get it working, at least for my case.

All I had to do was the following.

 

1. Open the Sandcastle Help File Builder (SHFB) GUI.

2. Open the project file, "MyDocumentation.shfbproj".

3. Go to > Project Explorer, > References, > Right-Click, > Add File/Project Reference, and add the following.

C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Libraries\Client\System.Xml.Linq.dll

C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\System.Xml.dll

C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\System.Core.dll

C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\System.Windows.dll

4. Done.

 

I am not sure why (and kind of sad that) the SDK install and the Framework installs (and other installs) do not just put everything in one location, or in the GAC, but I trust (and hope) there is good reason.

Another odd thing, IMHO, is that it appears that some DLL names (and some namespaces) are shared and identical across the "Full-Framework-Codebase of X" and the "Sillverlight-Codebase of X"-- for example, "System.Xml.Linq.dll" exists both in the Full-Framework-Codebase and in the Silverlight-Codebase, which stinks for trying to get the compiler to understand that. What I do not get is why they reused the namespace name? Why not just pick a new name? But, as it is, sometimes the collide and the compiler (and other tools like SHFB perhaps?) get confused.

I could not find a way to use a wildcard such as...

C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\*.*

...which might be nice to offer a hint to the SHFB saying "if you cannot find something then try looking here" but I do not really care because I have full control over the build, etc.

This works for my setup and that is GEFN for now.

HTH.

Thank you.

-- Mark Kamoski

Feb 9, 2011 at 3:30 AM

@Mark Kamoski

I got it working as well.  I used Mark's post as a kickoff.  In my case my project is a Silverlight4 so I went to the "Reference Assemblies" down to the 4.0 folder.  Instead of trying to figure out which were missing I referenced them all.  It worked.  Then I started removing likely unneeded ones until it failed. I put that one back in and removed the next one.  I continued that process until I had only the ones required.

The old trial and error method.

At least it does work still.

Larry

Coordinator
Feb 9, 2011 at 3:00 PM

I've fixed this as part of an update to support Silverlight projects in general.  It will now be possible to select a Silverlight Framework version in the FrameworkVersion project property. When one is selected, SHFB alters how the references are resolved so that the correct assemblies are picked up and passed to MRefBuilder.exe.  I'm hoping to have the next release out in a few weeks.

Eric

 

 

Feb 10, 2011 at 3:46 PM

That's great news Eric. Any idea when that update will be posted?

 

Jeff

Feb 28, 2011 at 12:52 PM
EWoodruff wrote:

I've fixed this as part of an update to support Silverlight projects in general.  It will now be possible to select a Silverlight Framework version in the FrameworkVersion project property. When one is selected, SHFB alters how the references are resolved so that the correct assemblies are picked up and passed to MRefBuilder.exe.  I'm hoping to have the next release out in a few weeks.

Eric

 

 

 

Hi Eric,

Is Silverlight supported in the current release (Feb 25 2011)? My version of Sandcastle Help File Builder is 1.9.1.0 and under FrameworkVersion I don't see an option to select Silverlight.

By the way I managed to build a .chm file for my silverlight class library, but not all links in the file are correct. Actually, they just link to the .NET 4 version instead of the Silverlight one, so if there is no .NET 4 equivalent of a particular silverlight class, property or whatever, no link is generated. Is there a way to fix this with the current release?

Thanks a lot,

Georgi

Coordinator
Feb 28, 2011 at 8:40 PM

Silverlight support is in v1.9.2.0 which I may release later today if I get time.  If not, it'll be this coming weekend.  Regarding the links, Sandcastle doesn't distinguish between the regular framework and other frameworks such as Silverlight or the Compact Framework.  Links to online content are generated by the ResolveReferenceLinksComponent2 build component which is part of Sandcastle.  You'd have to rework it to point to a different set of topcis as it resolves them using the MSDN web service.  I believe someone had a go at this for Silverlight but I don't know if they ever got it working (http://sandcastle.codeplex.com/Thread/View.aspx?ThreadId=76593).

Eric

 

Mar 1, 2011 at 10:47 AM

Hi,

I've just installed the 1.9.2.0 release and I now have the Silverlight option as you said - thanks for the quick response.

I'm a little behind schedule right now, so I probably won't have time to set about changing the Sandcastle code, but I'll certainly give it a try when I've got time and I will let you know, if I get it to work this way. Thanks again for the info.

Georgi

Mar 3, 2011 at 9:59 AM

Unfortunately, I still can't get it to work - now I have to both specify SL 4 as target framework and to explicitely reference the SL reference assemblies :-/

This is a 64 bit build machine - perhaps some paths are messed up - the SL reference assemblies are located in C:\Program Files (x86)\Microsoft SDKs\Silverlight.

Build output follows:

-------------------------------
[Sandcastle Help File Builder Utilities, version 1.9.2.0]
Creating output and working folders...
-------------------------------
Clearing working folder...
-------------------------------
Finding tools...
Found Sandcastle tools in 'C:\Program Files (x86)\Sandcastle\'
-------------------------------
Validating and copying documentation source information
Source: C:\Daten\compile-remote-silverlight\lib\yWorks.yFilesSilverlight.Viewer.dll
    Found assembly 'C:\Daten\compile-remote-silverlight\lib\yWorks.yFilesSilverlight.Viewer.dll'
Source: R:\build\tmp\doc-rebuild-mshc\comments\yWorks.yFilesSilverlight.Viewer.xml
Source: R:\build\tmp\doc-rebuild-mshc\summaries\summary-canvas-core.xml
Source: R:\build\tmp\doc-rebuild-mshc\summaries\summary-graph.xml

Copying XML comments files
    R:\build\tmp\doc-rebuild-mshc\comments\yWorks.yFilesSilverlight.Viewer.xml -> R:\build\tmp\doc-rebuild-mshc\Help\Working\yWorks.yFilesSilverlight.Viewer.xml
    R:\build\tmp\doc-rebuild-mshc\summaries\summary-canvas-core.xml -> R:\build\tmp\doc-rebuild-mshc\Help\Working\summary-canvas-core.xml
    R:\build\tmp\doc-rebuild-mshc\summaries\summary-graph.xml -> R:\build\tmp\doc-rebuild-mshc\Help\Working\summary-graph.xml
-------------------------------
Generating shared content files (en-US, English (United States))...
    Last step completed in 00:00:00.0040
-------------------------------
Generating API filter for MRefBuilder...
    Last step completed in 00:00:00.1360
-------------------------------
Generating reflection information...
[c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe]
  MrefBuilder (v2.6.10621.1)
  Copyright � Microsoft 2006
  Info: Loaded 1 assemblies for reflection and 0 dependency assemblies.
MREFBUILDER : error : Unresolved assembly reference: System.Windows (System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e) required by yWorks.yFilesSilverlight.Viewer [R:\build\tmp\doc-rebuild-mshc\Help\Working\GenerateRefInfo.proj]
    Last step completed in 00:00:00.9431

Coordinator
Mar 3, 2011 at 7:36 PM

Can you send me an example project that is failing in the manner you describe?  As I've mentioned before, I don't use Silverlight yet so the only test projects I have are the ones people send me.  The existing support was based on getting those to build and they do.  It's possible your project has something extra that needs to be added and I won't know what it is until I can get another failing project.  My e-mail address is in the About box in the GUI and in the footer of the pages in the help file.  Thanks.

Eric

 

Coordinator
Mar 4, 2011 at 3:03 AM

I took another look at this and I think I see the problem.  From your post above, it looks like you've added the assembly and XML comments files as documentation sources.  As far as I can tell, MRefBuilder will not automatically resolve references to the Silverlight framework assemblies.  The Silverlight assemblies are also spread across two separate folders (the .\Reference Assemblies folder and the .\Microsoft SDKs folder).  If you're going to add your assemblies directly, you will need to explicitly list the reference assemblies too.  However, if you add your Visual Studio solution or project file as the documentation source instead, SHFB can scan it and add the references that it finds to the MRefBuilder response file for you.  That does work.  If you find that it doesn't, then please send me a test case.  Also, I'm running Windows 7 64-bit and haven't had any issues with the existing Silverlight test projects.  SHFB automatically runs the 32-bit version of MSBuild for the reflection info step if it see the Silverlight framework selected so that it resolves the references correctly.

Eric

 

Mar 4, 2011 at 9:19 AM

Hi Eric,

 

thanks for taking a look at this :) This could very well be the reason (I do add the assemblies etc. as documentation sources). From your description, it sounds like this ultimately is a problem in Sandcastle.

 

I can live with our current solution (so far I've generated the reference assembly list automatically anyway - guess the new wildcard reference plugin will be quite helpful) - nevertheless, I'll try if the problem persists if I use the source project instead.

 

JM

Coordinator
Mar 4, 2011 at 2:57 PM

It occurred to me later after I posted my last reply that Sandcastle supports custom assembly resolvers.  I did one for binding redirection.  It's possible I could create one to specify alternate paths to look for assemblies such as the Silverlight folders.  I'll see what I can come up with.

Eric

 

Coordinator
Mar 6, 2011 at 7:24 PM
Edited Mar 6, 2011 at 7:26 PM

I think I've come up with an acceptable solution.  If a Silverlight framework is selected and no Silverlight Visual Studio projects have been seen, SHFB will now automatically add all Silverlight Framework assemblies that it knows about as references for generating the reflection information.  It adds many more than are actually needed but does save you from having to figure out which ones to add manually.  If the preferred approach of using the solution or project as the documentation source is used, SHFB will only use the references it found in the projects.

Eric