Skip to main content
Home Forums Silverlight Programming Programming with .NET - General Using SilverLight System.Xml.Core, but application trying to access System.Xml
16 replies. Latest Post by luisabreu on September 25, 2007.
(0)
sambusik
Member
14 points
8 Posts
09-25-2007 10:39 AM |
I started with the <a href="http://silverlight.net/QuickStarts/XmlFeatures/xmlData.aspx">How To: Manipulate XML Data in Silverlight</a> quick start and want to put together a proof of concept that shows data being passed around throughout layers.
My data access layer is a class library project, with a class and method that reads the contents of an Xml file into an XmlReader. I then have an ASPX project containing a web service that calls a method in the data access layer and the passes the XmlReader along.
Both of the projects reference the System.Xml.Core.dll in the SilverLight directory.
The projects were created as an ASPX application and a class library, with the target framework set to 3.5. I had to remove the default System.Xml reference and add a reference to the one in the SilverLight directory. The web project still references a bunch of 2.0 stuff, such as System.Web
When I compile, the build succeeds but I get a warning in each of the two projects: "Found conflicts between different versions of the same dependent assembly."
When I try to view the web service, I get the following Exception:
Compilation Error Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately. Compiler Error Message: CS0433: The type 'System.Xml.XmlQualifiedName' exists in both 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\e44c7941\8ff2bb5e\assembly\dl3\877c1a49\00e89da3_c3dfc701\System.Xml.Core.DLL' and 'c:\WINDOWS\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089\System.XML.dll' Source Error: Line 653:Line 654: class QueuedType {Line 655: internal XmlQualifiedName name;Line 656: internal XmlQualifiedName typeName;Line 657: internal XmlSchemaForm form; Source File: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\DefaultWsdlHelpGenerator.aspx Line: 655
Compilation Error Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0433: The type 'System.Xml.XmlQualifiedName' exists in both 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\e44c7941\8ff2bb5e\assembly\dl3\877c1a49\00e89da3_c3dfc701\System.Xml.Core.DLL' and 'c:\WINDOWS\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089\System.XML.dll'
Source Error:
Line 653:Line 654: class QueuedType {Line 655: internal XmlQualifiedName name;Line 656: internal XmlQualifiedName typeName;Line 657: internal XmlSchemaForm form;
Source File: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\DefaultWsdlHelpGenerator.aspx Line: 655
I made sure to clear out all the ASP.Net temporary files.
Seems like this is caused by references in the ASPX project. I'm not sure why it's trying to hit the hold System.Xml since I removed that reference. Confusing, since I created it with a target framework of 3.5
Appreciate any tips.
Thanks!
jasonxz
Participant
1752 points
530 Posts
09-25-2007 11:00 AM |
In your web site's property pages, look at the References tab and see what it says about the System.Xml assembly. I believe that the System.Xml assembly used by SL is the one that came with the .NET 2.0 framework, so if you have explicitly referenced the file, you're using 2 copies of the same assembly: 1 from the SL folder and the other in the GAC. The System.Web assembly references the System.Xml assembly and there was not a new version of System.Web for 3.5, so your web site will always reference the System.Xml in the GAC.
09-25-2007 11:15 AM |
Good call ... It makes sense because as you said System.Web will reference the .Net 2.0 System.Xml from the GAC. I'm referencing the SilverLight System.Xml in my ASPX and DAL projects because I have a SilverLight control in a separate project which will consume the web service (via the proxy) and expects an XmlReader.
If I use the the .Net 2.0 System.Xml in my DAL and ASPX, the web service proxy will contain an abstract partial class called XmlReader, which messes everything up royaly.
I tried instead to pass an Xml string, and read it into an XmlReader using the SilverLight System.Xml.XmlReader but it's acting "weird"; it won't see some elements of the Xml, etc. I haven't spent much time troubleshooting that side of it, but it seems like different versions of the XmlReader are treating the Xml differently.
The strange thing is if I start with the same Xml file, and directly in my SilverLight control load it into an XmlReader via a Stream, works like a charm.
Thanks
09-25-2007 12:01 PM |
That's really odd b/c I believe the Silverlight System.Xml assembly is the .NET 2.0 assembly. They should be the same file.
09-25-2007 12:30 PM |
I'm under the impression that the System.Xml that SilverLight uses is a different one and lives in the SilverLight directory. It's a slimmed down version of the old school System.Xml as I understand.
09-25-2007 12:45 PM |
If you look in Reflector at the assembly reference hierarchy starting with System.Silverlight, you'll see the following:
System.Silverlight.dll references System.dll Version 2.1.
System.dll references System.Xml.dll Version 2.0.
These are the same Version#s and PublicKeyTokens (which I didn't type in here) as the references used by System.Web Version 2.0.
Now, I don't know a whole lot about how that all works, but I would think, based on that information, they're the same System.Xml.dll file.
09-25-2007 2:17 PM |
That definitely makes sense. I'm confused though as to why a SilverLight project will reference System.Xml.Core.dll in C:\Program Files\Microsoft SilverLight by default.
Xml support in SilverLight is supposed to be slimmed down, for example there is no XmlTextWriter in the SilverLight System.Xml.Core.dll ...
Thanks for all your help Jason
luisabreu
1676 points
612 Posts
09-25-2007 2:34 PM |
hello guys,
i'm a little bit lost here, but if i recall correctly, there really ins't a system.xml.dll assembly in the Silverlight mini-clr. there's only a System.Xml.Core assembly which contains a stripped down version of the xml classes that exist on the full .net framework.
09-25-2007 2:41 PM |
Exactly ... What I'm trying to do is pass an XmlReader object (through referencing System.Xml.Core.dll from SilverLight) from an ASPX/WebService down to a SilverLight control.
By default, an ASPX application references System.Web, and thus good old System.Xml from 2.0 and caused that exception pasted into the first post.
09-25-2007 2:44 PM |
OK. I missed a very key component, here. System.Xml.Core.dll. I was really confused, myself, Luis. Back to the original question, it looks like the System.Xml.Core.dll and System.Xml.dll both have a System.Xml.XmlQualifiedName type in them. So, you can't reference System.Xml.Core.dll in your web site.
Sam, why did you feel you needed to reference the System.Xml.Core.dll?
Luis, can you explain why, in Reflector, it shows that the Silverlight assemblies reference the main System.Xml.dll from the 2.0 Framework? I understand it's supposed the be stripped down, but I don't understand how it can be if it references the big assembly. We can't assume the big one's in the GAC, can we?
09-25-2007 2:58 PM |
Hey Jason,
I'm referencing System.Xml.Core.dll in my web application because I'm trying to pass an XmlReader down to a SilverLight control and I wanted the types to match.
If I use System.Xml from .Net 2.0, my proxy web service class (generated by slwsdl) will contain an abstract partial class called XmlReader because it thinks the two types don't match. This causes a big mess in the SilverLight control because there's two types with the same names, and I can't load the "XmlReader" into an XmlReader.
I tried simply creating a string of Xml and then loading it into an XmlReader in the SilverLight control. I was seeing some really strange behavior, such as the XmlReader not seeing certain elements in the Xml. However, if in the SilverLight control I simply access the Xml file and load it into an XmlReader, all is good. This confused me more, since I was loading from the same Xml file ...
I'm trying to POC Xml data traversing through different layers of an application for a presentation I'm doing this Friday, which is why I'm doing it this way
09-25-2007 4:11 PM |
hello again.
jasonxz:Back to the original question, it looks like the System.Xml.Core.dll and System.Xml.dll both have a System.Xml.XmlQualifiedName type in them
well, i didn't check this, but i believe that might be the case.If you're writing code that must be shared by silverlight and another application, then you should follow the most excellent advice given by Daniel Moth in this great msdn article:
http://msdn.microsoft.com/msdnmag/issues/07/07/ShareCode/default.aspx
even though the article is about mobile and desktop apps, you can easilly adapt the principles to write code that should be shared by silverlight and oher kind of apps. do notice that i'm talking about writing code that you reuse in different kind of applications.
jasonxz:Luis, can you explain why, in Reflector, it shows that the Silverlight assemblies reference the main System.Xml.dll from the 2.0 Framework? I understand it's supposed the be stripped down, but I don't understand how it can be if it references the big assembly.
hum...really no idea...i mean, i've fired up reflector and i'm not seeing any dependency on the .NET system.xml assembly...
jasonxz:We can't assume the big one's in the GAC, can we?
yes, you cannot. even if it were, you'd never be able to use it from your silverlight code...
09-25-2007 4:16 PM |
hello.
sambusik: I'm referencing System.Xml.Core.dll in my web application because I'm trying to pass an XmlReader down to a SilverLight control and I wanted the types to match.
i believe this is not possible right now and i doubt it will ever work in the future... currently, silverlight can only interop with the DOM and JS code. You cannot use full .NET components or even use ActiveX controls from your silverlight code. if you need this, you'll have to put them on the html page and use js to interop with those controls...
sambusik:I tried simply creating a string of Xml and then loading it into an XmlReader in the SilverLight control. I was seeing some really strange behavior, such as the XmlReader not seeing certain elements in the Xml. However, if in the SilverLight control I simply access the Xml file and load it into an XmlReader, all is good
have you seen this quickstart:
http://silverlight.net/QuickStarts/XmlFeatures/default.aspx
not sure on what POC is. can you give more info?
thanks
09-25-2007 4:21 PM |
Luis,
Thanks for your help, I've seen those Quickstarts but I'll take a much closer look at them.
POC is a Proof of Concept. I was putting together a solution that shows Xml data being passed through a web service into a SilverLight control and came across this issue.
09-25-2007 5:21 PM |
oh, that's what a poc is :)
ok, now the xml part: i believe the quickstart has the scenario you want. btw, do notice that if you're calling a web service that is hosted on the same domain that the page that hosts your sl control, then you can generate a proxy,making your web service call a no brainer.
09-25-2007 5:26 PM |
Yeah I got the proxy running and had to find my way around the whole cross-domain call issue ...
Thanks everyone for your help on this.
09-25-2007 5:35 PM |
oh, then xml is the way to go :)