IttyUrl.Net

Today we’ll look at an example where sgen did not solve the problem with a dynamically loaded XmlSerializers assembly.   This issue was found by a customer and filed as a bug on the Microsoft Connect site for SQL Server: http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=209210

In brief, the code was trying to write out an XmlSchema object to a MemoryStream using XmlTextWriter.  Under the covers, however, XmlSchema.Write calls the following:

XmlSerializer serializer = new XmlSerializer(typeof(XmlSchema));

This looks just like the typical Xml Serialization use case which sgen was able to solve; however, in this case the clr is looking for an XmlSerializer for the framework defined XmlSchema class, rather than a class that the customer created.  Running sgen on the user’s assembly does not create an XmlSerializer for XmlSchema because it is defined in System.Xml.Dll.

At first, it seems the workaround to this would be simply to sgen System.Xml.dll for the XmlSchema type and load the resultant XmlSerializers assembly into SQL Server.  However, if you try this, you’ll note that running sgen on System.Xml.dll won’t work because System.Xml.dll is signed with Microsoft’s private key, which you are unlikely to have.

C:\Windows\Microsoft.NET\Framework\v2.0.50727>sgen /t:System.Xml.Schema.XmlSchema System.Xml.Dll

Microsoft (R) Xml Serialization support utility

[Microsoft (R) .NET Framework, Version 2.0.50727.42]

Copyright (C) Microsoft Corporation. All rights reserved.

Error: Generated serialization assembly is not signed: System.Xml.XmlSerializers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null. Please specify strong name key file via /compiler:/keyfile:<file> switch.

So what are our other options?  One possibility is to incorporate the generated XmlSchema.XmlSerializer dll into the user’s assembly and reference it directly.   

After all, what the code is really doing is creating a specialized Serializer for the XmlSchema class.  If the XmlSerializer already exists, then we can use it directly and bypass the magic dynamic assembly generation step altogether.  Although sgen returned an error because the Serializer assembly isn’t signed and can’t be used automatically, we can instead use the XmlSerializer it generated manually by renaming the file and adding a reference to it in the project.

Now all we have to do is change the code to explicitly use our specified XmlSchemaSerializer.  In this case, it’s done by replacing the code

 GeneratedSchema.Write(Writer)

With

Dim GeneratedSchemaSerializer As XmlSchemaSerializerGeneratedSchemaSerializer = New XmlSchemaSerializer()GeneratedSchemaSerializer.Serialize(Writer, GeneratedSchema)

The code now works.  Although the workaround is a little messy, it accomplishes the goal of serializing a system defined class without requiring a dynamic assembly to be loaded.

Today we’ll look at an example where sgen did not solve the problem with a dynamically loaded XmlSerializers assembly.   This issue was found by a customer and filed as a bug on the Microsoft Connect site for SQL Server: http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=209210

In brief, the code was trying to write out an XmlSchema object to a MemoryStream using XmlTextWriter.  Under the covers, however, XmlSchema.Write calls the following:

XmlSerializer serializer = new XmlSerializer(typeof(XmlSchema));

This looks just like the typical Xml Serialization use case which sgen was able to solve; however, in this case the clr is looking for an XmlSerializer for the framework defined XmlSchema class, rather than a class that the customer created.  Running sgen on the user’s assembly does not create an XmlSerializer for XmlSchema because it is defined in System.Xml.Dll.

At first, it seems the workaround to this would be simply to sgen System.Xml.dll for the XmlSchema type and load the resultant XmlSerializers assembly into SQL Server.  However, if you try this, you’ll note that running sgen on System.Xml.dll won’t work because System.Xml.dll is signed with Microsoft’s private key, which you are unlikely to have.

C:\Windows\Microsoft.NET\Framework\v2.0.50727>sgen /t:System.Xml.Schema.XmlSchema System.Xml.Dll

Microsoft (R) Xml Serialization support utility

[Microsoft (R) .NET Framework, Version 2.0.50727.42]

Copyright (C) Microsoft Corporation. All rights reserved.

Error: Generated serialization assembly is not signed: System.Xml.XmlSerializers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null. Please specify strong name key file via /compiler:/keyfile:<file> switch.

So what are our other options?  One possibility is to incorporate the generated XmlSchema.XmlSerializer dll into the user’s assembly and reference it directly.   

After all, what the code is really doing is creating a specialized Serializer for the XmlSchema class.  If the XmlSerializer already exists, then we can use it directly and bypass the magic dynamic assembly generation step altogether.  Although sgen returned an error because the Serializer assembly isn’t signed and can’t be used automatically, we can instead use the XmlSerializer it generated manually by renaming the file and adding a reference to it in the project.

Now all we have to do is change the code to explicitly use our specified XmlSchemaSerializer.  In this case, it’s done by replacing the code

 GeneratedSchema.Write(Writer)

With

Dim GeneratedSchemaSerializer As XmlSchemaSerializerGeneratedSchemaSerializer = New XmlSchemaSerializer()GeneratedSchemaSerializer.Serialize(Writer, GeneratedSchema)

The code now works.  Although the workaround is a little messy, it accomplishes the goal of serializing a system defined class without requiring a dynamic assembly to be loaded.

TechEd '06 is now officially over and it was so great to see so many developers, ASPInsiders, MVPs and ASP.NET customers at the ASP.NET booth on the Expo/Learning Center floor.   For those of you who couldn't attend, don't worry!   There's a 'Virtual TechEd' site at http://virtualteched.com/default.aspx where you can view many of the breakout sessions that were recorded and view some other great videos and blogs that will get you as close to the TechEd experience as you can get.

So what were some of the Web Development highlights of the conference?    Here are just a few:

• The Microsoft.com operations team gave some very popular talks on how they manage IIS and ASP.NET in a large production environment.   Microsoft.com was one of the first large deployments of ASP.NET 2.0, with the Download Center going live shortly after Visual Studio 2005 ("Whidbey") Beta 2.

• Scott Guthrie gave a great end-to-end talk on ASP.NET 2.0, Atlas and IIS 7 in a packed ballroom.    He created an app from the ground up, showing how how it benefited from each of the new features in the web platform.

• Thomas Deml did a talk on the IIS 7 Integrated HTTP pipeline, including demos of the magic you can do with the pipeline - including how to spice up the common file listing in IIS to include photos and other useful file information.

We'll be doing more TechEd conferences around the world through the end of the year.   In particular, the team will be presenting at the TechEd Southeast Asia and Europe conferences.  See http://www.microsoft.com/events/teched2006/worldwide.mspx for information about a TechEd worldwide conference near you. 

"Atlas" June CTP

We just released the "Atlas" June CTP at the end of this month, which includes several bug fixes and some new functionality, including Dynamic Update Panels which allow you to add UpdatePanels from your code throughout the page lifecycle.   UpdatePanels can also now be added inside templates and work inside WebParts.   WebParts can also be included inside UpdatePanels.    

Blinq Preview

Don't Blinq or you'll miss it!   There's a new tool in the Sandbox (http://sandbox.asp.net/) called Blinq.    Blinq allows you to create a web application instantly out of any data schema.   It uses the LINQ prototype for dynamically generating SQL queries inline with VB and VC# code.   Give it a try!

French Atlas Website

French-speaking developers will welcome the new French ASP.NET website at http://www.asp.net/fr.  We'll keep updating this page with great content as we find it!

Contact: richarde@microsoft.com

Disclaimer: This information is provided "AS IS" with no warranties, and confers no rights.  Copyright^© 2006, Microsoft Corporation.   All Rights Reserved.  Use of these contents is subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

I recently made the verbal error of saying that for the new BASE element changes in IE 7 you had to put your tag inside the HEAD element. Well, someone pointed out to me rather quickly that on Firefox you could just have a bare TITLE and BASE followed by some body content and away you go the page would validate and parse properly. Well, we do the same thing in IE, and it is called implied tags in HTML. There are some gotchas though.

First, I'll start with the trick... What in the heck is IE doing?<HTML id="dumpInternals"><TITLE></TITLE><BASE href="foo"><BUTTON onClick="alert(dumpInternals.outerHTML)">Click Me!</BUTTON></HTML>

That is your boilerplate. When you click on your button there you'll find that IE is actually putting the TITLE/BASE in the implied HEAD of the document and then putting the BUTTON into the implied BODY. Good stuff, and the document is still perfectly valid. Issues can arise when you do this though because you aren't necessarily realizing what elements belong in the HEAD and which belong in the BODY and so you might terminate your HEAD enclosure early and put a bunch of random elements that don't belong in the BODY into the BODY.

This won't look right without your IE 7 Beta 1, since the BASE element is going to wrap a bunch of stuff, but you can get the gist. The below will show you that the second BASE ended up inside of the BODY. That isn't good, we don't look for BASE elements there and it won't get used. (Read my previous post on IE 6 behavior and you'll see that it used to get used because of some container magic, but not anymore, we are compliant).<HTML id="dumpInternals"><TITLE></TITLE><BASE href="foo"><BUTTON onClick="alert(dumpInternals.outerHTML)">Click Me!</BUTTON><BASE href="foo"></HTML>

The set of implied rules has impacts in other areas as well. You can, for instance, end up using document.writeln to prematurely terminate your HEAD element and move a bunch of stuff out into the BODY. So, if you are doing inline document writes you should probably do them where you want the content to go. Writing the content out in script blocks that appear in the head is the wrong way to go about it. You could hook up to some events or have a container element that you write into, and that is acceptable, but with inline writes you could get unexpected behavior.

Recently I noticed a site that was doing a document.writeln in their HEAD element about half-way through the head content. End result? Well, the content got moved into the BODY element and the object model tree for the page was completely wrong. Good thing they weren't navigating the object model looking for stuff and good thing the extra META/LINK elements weren't being used as well. With a static parse of the page you wouldn't even notice these problems, but when DHTML becomes involved it can change the structure of your document on the fly and rewrite what the object model tree looks like.

I should back this up with some samples. I'll try and get those prepared shortly.