Strange XmlSerializer error

Question

Dear all,

I am programming in VB.NET , using the .NET Framework 2.0 on a Windows Vista machine running VS 2005 with the SP1 beta applied.

I have a VB class which was derived from an .XSD schema using the XSD.exe tool.

I am able to instantiate objects from this class and build by "XML" object up using it, without too much difficulty.

However, when I come to serialize the output to an XML stream, it fails, with a FileNotFoundException on the serialize line, e.g.:

Dim serializer As New XmlSerializer(GetType(eGov.IRenvelope))

Where eGov is my class namespace, and the IRenvelope is the class within the namespace that corresponds to my object which I am attempting to serialize.

The interesting thing is, that if I run the exe directly (i.e. not in debug, even if it is a debug .exe) there is no problem and the code runs fine. However, when inside the IDE, I always get the error (see below).

I have tried the build options for "Generate serialization assemblies" to on, off and auto (default) and nothing seems to work. I assume that I'm looking for my ebXML.Serialization.dll assembly, but nothing is ever created.

I'm up against a tight deadline here (hence working at 2:30am), so would appreciate all and any advice that you can give.

Many thanks in advance for your help.

Mike

--

The assembly with display name 'ebXML.XmlSerializers' failed to load in the 'Load' binding context of the AppDomain with ID 1. The cause of the failure was: System.IO.FileNotFoundException: Could not load file or assembly 'ebXML.XmlSerializers' or one of its dependencies. The system cannot find the file specified.
File name: 'ebXML.XmlSerializers'

=== Pre-bind state information ===
LOG: User = xxxx\Mike
LOG: DisplayName = ebXML.XmlSerializers
 (Partial)
LOG: Appbase = file:///F:/2/ebXML/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///F:/2/ebXML/bin/Debug/ebXML.XmlSerializers.DLL.
LOG: Attempting download of new URL file:///F:/2/ebXML/bin/Debug/ebXML.XmlSerializers/ebXML.XmlSerializers.DLL.
LOG: Attempting download of new URL file:///F:/2/ebXML/bin/Debug/ebXML.XmlSerializers.EXE.
LOG: Attempting download of new URL file:///F:/2/ebXML/bin/Debug/ebXML.XmlSerializers/ebXML.XmlSerializers.EXE.

Answer 1

Will this a hint for you? (Be ware that it may complete not relevance) --- "CultureInfo".  Have you change language setting in the regional setting in the control panel?

I don't have good knowledge on this topic to use precise wording:

Dot Net always loads assembly by fullname, which includes "Culture".  If load assembly by a short name, which does not have "Culture", a default "Culture" is supplied from somewhere.  If this "Culture" does not match the "Culture" of the assemblies in the search path, FileNotFoundException is thrown.

Answer 2

Thanks for the heads up. The culture as far as I can see is no different. Actually, regarding the FileNotFound exception, the .serializer.dll isn't found. It's not one of my .dll's. Why does VS need to create this assembly, and why isn't it created on my machine?

Perhaps there's something "wrong" with the classes I have which cause them to error during serialization at debug runtime.

Anyone?

Answer 3

I am getting the EXACT same problem. Did you figure it out? I will post here if I find a solution..

Answer 4

Hi Shane,

No joy here. I still have the same problem. My betting is that this is a bug with VS2005, as I have searched high and low for a solution.

As it turns out, I am attempting to serialise a home-made class, all the attributes are serializable so that's not it - but it might be, who knows?

Anyway, it works if I just ignore the error. When I deploy the solution it still works. However, this is making debugging really inconvenient.

Let me know if you find a solution! I'm going to escalate this one to Microsoft Product Support. I'll probably have an answer sometime in February/March.

Answer 5

This exception is a part of the XmlSerializer's normal operation. It is expected and will be caught and handled inside of the Framework code. Just ignore it and continue. If it bothers you during debugging, set the Visual Studio debugger to only stop on unhandled exceptions instead of all exceptions.

 

Answer 6

Eugene,

Many thanks for the response. It is really not the answer I'm looking for; this is a bug of VS2005 and not a feature!

Will we see a fix for this bug in VS2005 SP1?

Still marked as answer in any case, and thanks for the clarification.

Mike

Answer 7

No; it's not a bug. What Eugene says is that we know that there is an exception being thrown if the precompiled serialization assembly can't be found and we deliberately made the decision to allow that to happen since avoiding that exception would be too costly. "Too costly" means here: "It would slow down your program if we did that".

Answer 8

Hi, Mike,

I ran into the same annoyance. I attempted running the sgen utility directly on my dll; sgen spit out an error. This was interesting mainly because I never received an error/warning from visual studio when building my project, even though i had "Generate Serialization Assembly" set to "on".

The reason sgen errored was due to an identically named class in separate namespace in my DLL (yes, really lame, but we're in the middle of reworking our data structure). Simply adding the attribute

[XmlRoot(Namespace = "http://www.blahblahblah.com.net.org")]

to my class resolved the sgen issue; once i generated the serialization.dll one manually, I had no further issues.

Hope that helps.

 

Answer 9

I can't seem to locate any information out there, my question is this: When the "Generate Serialization Assembly" is set to "Auto", what exactly triggers Visual Studio to "Automatically" create the serialization dll? I've yet to see the projectName.serializtion.dll created without the setting being turned "On" or by invoking sgen manually.

 

Answer 10

Yes, that works. Interesting that sgen <> "Generate Serialization Assembly" = Auto or Yes.

Answer 11

I don't think you realize how bad it is for Microsoft to be saying that a reasonable programming practice is "throw exceptions as part of normal operation".  We have a vendor who frequently throws exceptions as part of normal operation; one of their engineers pointed me to this page.  Microsoft does it, so it must be OK.

The fact is, everyone thinks "oh, it's just one more mouse click", and pretty soon in a large application you are clicking through 20 or more exception messages.

To quote from Eugene:

"If it bothers you during debugging, set the Visual Studio debugger to only stop on unhandled exceptions instead of all exceptions."

If part of your job is to track down and solve exceptions (which includes most people who develop or debug large software projects) the fact that you no longer stop on exceptions might actually be significant.  It saddens me to see flippant comments like this responding to significant customer issues.

Answer 12

I totally agree Geoff. I just spent four hours trying to hunt this thread down only to see "throw exceptions as part of normal operation?" Well I guess when you think about it, it is normal operation for Microsoft.

"Flippant comment, cancel or allow?" :)

Answer 13

Yes, it seems to me that it ought to be much better to actually LOOK for the applicable DLL first off. If it's not there then MAKE it instead of throwing an exception when you try to get it, then do something about it (like making it).

It's always better to be proactive in a potential error condition.

Answer 14

I think you guys are being a little harsh. I think what the developer from Microsoft is saying is that they are internally throwing an error and then somewhere up the callstack they handle the error and they eventually resolve it and he is saying that it is more efficient to do it that way. Since you have break on all errors turned on you break at the exception and see the error message you are referring to. If you click continue a few times after the code stops at the debug exception it will eventually resolve itself and pass through and execute your code correctly. Note: You can turn off that specific error if you drill down in the debug CLR tree in the Debug->Exceptions dialog. That way you can debug all other exceptions. (REMEMBER: You have break on ALL exceptions. This includes HANDLED exceptions)

 

BTW: If you never throw exceptions in your own code then you may want to do some reading on the subject. It is a sound programming strategy in many cases.

 

Billy

Answer 15

I realize this is a 5 year old thread, but...

The problem I have with this behavior is that if you try and call a function which creates the XmlSerializer object using the Immediate Window while at a breakpoint the Raised Exception keeps you from ever continuing to execute the code.