Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • JavaScript • Angular
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

Bugged by a Serialization Assembly


:P
On this page:

I ran into a problem with Serialization today in one of my utility classes. I have an Entity generator tool I use that generates entity classes for my business objects from the database. One of the things I do in the generated file is embed the settings of the object as an embedded XML Serialization XML string right into the generated code and bracket it with #if false/#endif. I can then simply point the tool right back at this file and it can pick up the settings directly out of the generated file.

 

So the tool uses a PropertyGrid to display its properties so yesterday I mucked around with the designer attributes on the various properties I added DefaultValues and Categories for everything. Recompiled went on my merry way not checking closely. Today I want to open the file and regenerate and find the tool is not picking up the original settings. Sure enough looking at the generated file I see – no embedded XML data.

 

So what happened is that when I made these changes to the designer attributes I munged up the attributes. I did something like this on a couple of properties:

 

[Description("The namespace of the generated set of DataRowContainer classes.")]

[Category("Code Generation"), DefaultValue(false)]

public string Namespace

{

    get { return this.cNamespace; }

    set { this.cNamespace = value; }

}

string cNamespace = "Entities";

 

Notice that DefaultValue is false instead of a string value.

 

This was enough to get the XmlSerialization to fail. When I ran:

 

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

 

Serialization immediately failed complaining that string cannot be compared to a bool value. I say this casually now, but at the time I had no clue where the error was coming from. How do you debug this when some presumably black box code basically blows up?

 

Well, the black box code is not quite so black box actually. Obviously this is a type construction problem that happens when the object is initially constructed in the serialization assembly, but very difficult to track down because the error message doesn’t give a lot of information.

 

XmlSerialization usually works with dynamic code generation and compilation. In fact, when you create an XmlSerializer it actually creates a class and then compiles it. The class is generated in your temp directory and you can pick it up there. For more exact details you can check out this post from Scott Hanselman that shows exactly how to do this.

 

The key thing is that you can add a configuration setting to your applications config file which causes the serialization assembly to be generated and saved.

 

<?xml version="1.0" encoding="utf-8" ?>
<
configuration>
   <
system.diagnostics>
      <
switches>
         <
add name="XmlSerialization.Compilation" value="1" />
      </
switches>
   </
system.diagnostics>
</
configuration>

 

You can then go to your system's temp directory and look for the latest .cs (or .vb) file and related .out/.err files which contain the source code, compiler and error messages. From there it's much easier to try and pinpoint the problem.

 

You basically fire the XmlSerializer once and then watch for the generated class to show up. You can even drag the source file into Visual Studio and set a breakpoint by dragging the generated class into Visual Studio and setting a breakpoint anywhere in the code. The next time you hit the code the debugger should fire up and stop on that line of code inside of the generated class.

 

In my case the compiler output was enough to find the problem:
 

Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.312

for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727

Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

 

c:\temp\agmx8w2r.0.cs(57,17): error CS0019: Operator '!=' cannot be applied to operands of type 'string' and 'bool'

c:\temp\agmx8w2r.0.cs(60,17): error CS0019: Operator '!=' cannot be applied to operands of type 'string' and 'bool'

 

Based on that I could simply open the source file and find line 57 and 60 and sure enough I found the above type mismatch of the DefaultValue() attribute and the actual type of the property it applied to.

 

This is an extremely useful feature that’s saved my ass on a few occasions. It’s also interesting to take a look and see what actually happens inside of the serialization code. In fact I had no idea that these attributes would be used in any way by the serializer. I had always assumed the attributes where used purely by the designer…

Posted in .NET  

The Voices of Reason


 

Random
February 20, 2007

# re: Bugged by a Serialization Assembly

Abso-brilliant. I've just discovered the Xml Serialization Assembly myself. I'm going to see if your config file setting will work in an asp.net app for the classes there.

Rick Strahl's Web Log
June 23, 2007

# Rick Strahl's Web Log

# DotNetSlackers: Bugged by a Serialization Assembly


Ondrej
April 20, 2008

# re: Bugged by a Serialization Assembly

Great ! Visible generated source code of the serializer helped me with the similar problem. Thank you.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2021