By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,143 Members | 1,908 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,143 IT Pros & Developers. It's quick & easy.

XmlSerializer & FileNotFound (NOT the usual problem!)

P: n/a
SJD
I've just read Christoph Schittko's article on XmlSerializer:

http://msdn.microsoft.com/library/de...trblshtxsd.asp

. . . and very informative it is too.

I, too, am getting nasty FileNotFound exceptions. I've read, and
digested the article, and I think I've found a bug -- it's difficult to
track, though it does happen often.

We have a large C# binary set, normally run from zero-deploy/IEExec. We
use XmlSerializer. We use it against one type in particular. We
**randomly** get the FileNotFound exception. So, to me, it's (a) not a
reflection/serialization issue, and (b) not a security problem (as it's
always run in the same user/machine/environment). I even ran the
XmlSerializerPreCompiler through, and the Type passed.

Has anyone come across the same thing? I'm on .NET Framework v1.1 (no
SP1, yet).

Maybe I'll just log it via MSDN regardless.

Anyway, many thanks.

Sean Donovan
(a C# developer from NYC)
Nov 12 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Could you post some code that shows the error. Are you using filestream?
What other streams ontop?

--
William Stacey, MVP
http://mvp.support.microsoft.com

"SJD" <sj*@newsgroup.nospam> wrote in message
news:#D**************@TK2MSFTNGP14.phx.gbl...
I've just read Christoph Schittko's article on XmlSerializer:

http://msdn.microsoft.com/library/de...trblshtxsd.asp
. . . and very informative it is too.

I, too, am getting nasty FileNotFound exceptions. I've read, and
digested the article, and I think I've found a bug -- it's difficult to
track, though it does happen often.

We have a large C# binary set, normally run from zero-deploy/IEExec. We
use XmlSerializer. We use it against one type in particular. We
**randomly** get the FileNotFound exception. So, to me, it's (a) not a
reflection/serialization issue, and (b) not a security problem (as it's
always run in the same user/machine/environment). I even ran the
XmlSerializerPreCompiler through, and the Type passed.

Has anyone come across the same thing? I'm on .NET Framework v1.1 (no
SP1, yet).

Maybe I'll just log it via MSDN regardless.

Anyway, many thanks.

Sean Donovan
(a C# developer from NYC)


Nov 12 '05 #2

P: n/a
Hi Sean,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you're receiving a FileNotFound
exception when doing XmlSerialization. If there is any misunderstanding,
please feel free to let me know.

I think it's very hard to say if it is a bug before reproducing it. I
haven't run into this before. So could you please post some of your code
here. And do you know which line of code throws the exception? I would be
glad to look into it if I can get a repro. Thanks for your cooperation!

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #3

P: n/a
SJD
Many thanks for the replies.

I've attached the exception-stack (ExceptionStack.txt) from when the
problem occurs.

It's just constructing the XmlSerializer, with the provided type:

... = new XmlSerializer(typeof(SpreadsheetPrintSettings));

I've attached the class for the Type SpreadsheetPrintSettings. As you
can see, it's fairly simple. The class isn't neat (I didn't write it).

:-)

So, it hasn't even got to parsing, it's just building the initial DLL.

IMPORTANT:

1. We only see this problem when running our application from
zero-deploy (ie. IEExec.exe).

2. It's random. Sometimes the call works, sometimes it doesn't.
Unfortunately, at the moment, I can't repeat it in any consistent way
that I can attempt to debug. The same user can start the binary once,
and it works. That same user then starts the same binary again (from
the same hosting URL), and it can fail.

ANALYSIS:

We're convinced the bug is something to do with zero-deploy. I need to
know, when does XmlSerializer decide to build the .DLL? Is it always
done on-the-fly, or, only the first time? If it detects that the
underlying binaries haven't changed, does it just reuse the previous DLL
it built? If it detects/re-uses previously built DLLs, we suspect there
is a corruption that can happen (which is what we're seeing).

If it doesn't use the previously built DLLs, I'm stumped.

Sean

Kevin Yu [MSFT] wrote:
Hi Sean,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you're receiving a FileNotFound
exception when doing XmlSerialization. If there is any misunderstanding,
please feel free to let me know.

I think it's very hard to say if it is a bug before reproducing it. I
haven't run into this before. So could you please post some of your code
here. And do you know which line of code throws the exception? I would be
glad to look into it if I can get a repro. Thanks for your cooperation!

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Top Level Exception:

System.TypeInitializationException: The type initializer for "Summit.Framework.View.SprPrintSettingsSeriali zer" threw an exception. ---> System.IO.FileNotFoundException: File or assembly name qxm483sa.dll, or one of its dependencies, was not found.

File name: "qxm483sa.dll"

at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Boolean isStringized, Evidence assemblySecurity, Boolean throwOnFileNotFound, Assembly locationHint, StackCrawlMark& stackMark)

at System.Reflection.Assembly.InternalLoad(AssemblyNa me assemblyRef, Boolean stringized, Evidence assemblySecurity, StackCrawlMark& stackMark)

at System.Reflection.Assembly.Load(AssemblyName assemblyRef, Evidence assemblySecurity)

at System.CodeDom.Compiler.CompilerResults.get_Compil edAssembly()

at System.CodeDom.Compiler.CompilerResults.get_Compil edAssembly()

at System.Xml.Serialization.Compiler.Compile()

at System.Xml.Serialization.TempAssembly..ctor(XmlMap ping[] xmlMappings)

at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)

at System.Xml.Serialization.XmlSerializer..ctor(Type type)

at Summit.Framework.View.SprPrintSettingsSerializer.. ctor()

at Summit.Framework.View.SprPrintSettingsSerializer.. cctor()


/// <summary>
/// A class to store the page settings to be used for printing.
/// </summary>
public class SpreadsheetPrintSettings
{
/// <summary>
/// constructor
/// </summary>
public SpreadsheetPrintSettings() {}

private Orientation _pageOrientation;

/// <summary>
/// Landscape or Portrait
/// </summary>
public Orientation PageOrientation
{
get { return _pageOrientation; }
set {_pageOrientation = value; }
}

private bool _scaling;

/// <summary>
/// Indicate if the spreadsheet should be reduced to fit in page(s).
/// </summary>
public bool Scaling
{
get { return _scaling; }
set { _scaling = value; }
}

private int _fitToPage;

/// <summary>
/// If spreadsheet should be reduced to fit in page(s), then how many page(s)?
/// </summary>
public int FitToPage
{
get { return _fitToPage; }
set { _fitToPage = value; }
}

private decimal _topMargin;

/// <summary>
/// Top margin
/// </summary>
public decimal TopMargin
{
get { return _topMargin; }
set { _topMargin = value; }
}

private decimal _bottomMargin;

/// <summary>
/// Bottom margin
/// </summary>
public decimal BottomMargin
{
get { return _bottomMargin; }
set { _bottomMargin = value; }
}

private decimal _leftMargin;

/// <summary>
/// Left margin
/// </summary>
public decimal LeftMargin
{
get { return _leftMargin; }
set { _leftMargin = value; }
}

private decimal _rightMargin;

/// <summary>
/// Right margin
/// </summary>
public decimal RightMargin
{
get { return _rightMargin; }
set { _rightMargin = value; }
}

private string _headerText;

/// <summary>
/// Header
/// </summary>
public string HeaderText
{
get { return _headerText; }
set { _headerText = value; }
}

private bool _headerAutoMargin;

/// <summary>
/// Indicate if the spreadsheet should calculate the amount of space
/// to be used for the header
/// </summary>
public bool HeaderAutoMargin
{
get { return _headerAutoMargin; }
set { _headerAutoMargin = value; }
}

private decimal _headerMargin;

/// <summary>
/// If spreadsheet should not calculate the amount of space for
/// the header, this is to set how much.
/// </summary>
public decimal HeaderMargin
{
get { return _headerMargin; }
set { _headerMargin = value; }
}

private string _headerAlignment;

/// <summary>
/// Alignment of the header
/// </summary>
public string HeaderAlignment
{
get { return _headerAlignment; }
set { _headerAlignment = value; }
}

private FontData _headerFont = new FontData();

/// <summary>
/// Font of the header
/// </summary>
public FontData HeaderFont
{
get { return _headerFont; }
set { _headerFont = value; }
}

private string _footerText;

/// <summary>
/// Footer
/// </summary>
public string FooterText
{
get { return _footerText; }
set { _footerText = value; }
}

private bool _footerAutoMargin;

/// <summary>
/// Indicate if the spreadsheet should calculate the amount of space
/// to be used for the footer.
/// </summary>
public bool FooterAutoMargin
{
get { return _footerAutoMargin; }
set { _footerAutoMargin = value; }
}

private decimal _footerMargin;

/// <summary>
/// If spreadsheet should not calculate the amount of space for
/// the footer, this is to set how much.
/// </summary>
public decimal FooterMargin
{
get { return _footerMargin; }
set { _footerMargin = value; }
}

private string _footerAlignment;

/// <summary>
/// Alignment of the footer
/// </summary>
public string FooterAlignment
{
get { return _footerAlignment; }
set { _footerAlignment = value; }
}

private FontData _footerFont = new FontData();

/// <summary>
/// Font of the footer
/// </summary>
public FontData FooterFont
{
get { return _footerFont; }
set { _footerFont = value;
}
}
}
Nov 12 '05 #4

P: n/a
Hi SJD,

I'm not quite sure what do you mean by "when does XmlSerializer decide to
build the .DLL". XmlSerializer doesn't build DLLs. Actually, when we run
programs on smart client, the assembly was fist downloaded to the client
and saved to c:\windows\assembly\download folder. Then it will be loaded by
CLR.

The second time we run this, CLR will first compare the DLL on the server
with the local copy to see if they are the same one, mainly using the
version number. If it is a strong named assembly, it will also compare the
public key token. If same, client will use the local copy directly, and if
not, download again from server.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #5

P: n/a
SJD
You might want to check, I'm 100% sure XmlSerializer builds randomly
named DLLs (into c:\temp). Well, to clarify; when running locally, the
built DLLs go into c:\temp. With a smart-client, I'm not sure where
they get built to (probably under the download cache).

I understand how the smart-client DLL load process works. Yup, all of
our binaries are strong-named. My question is, how does a smart-client
deal with DLLs that XmlSerializer builds? We think that's the mechanism
that has the problem.

Sean

Kevin Yu [MSFT] wrote:
Hi SJD,

I'm not quite sure what do you mean by "when does XmlSerializer decide to
build the .DLL". XmlSerializer doesn't build DLLs. Actually, when we run
programs on smart client, the assembly was fist downloaded to the client
and saved to c:\windows\assembly\download folder. Then it will be loaded by
CLR.

The second time we run this, CLR will first compare the DLL on the server
with the local copy to see if they are the same one, mainly using the
version number. If it is a strong named assembly, it will also compare the
public key token. If same, client will use the local copy directly, and if
not, download again from server.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #6

P: n/a

Sean,

The temporary assemblies go into whatever is configured to be the temp
directory for executing application's identity. Check what's in the
%temp% environment variable for your logged on user. It should be
\Documents And Settings\<username>[.domainname]\Local Settings\Temp

Since Smart Clients can invoke Web services just fine (which may require
the XmlSerializer to run in a partially trusted context) -- as you
stated it's mostly likely not something in your program that's causing
the error, since it seems to be running OK sometimes.

To answer your question. It's my understanding that the XmlSerializer
builds the temporary assembly once per process, i.e. the first time you
instantiate it for a given type during the life time of a process. If
you launch the process again, then the XmlSerializer will create a new
assembly. However, this is only true if you are using the basic
constructor overload (new XmlSerializer(typeof(YourType))). Other
constructor overloads are not guaranteed to behave like that. They may
compile the assembly for every instantiation of an XmlSerializer
instance. I can go back and check if you're using any other overloads.

To help troubleshooting. Have you thought about:

Running FileMon from www.sysinternals.com to monitor for any file system
related problems during the compilation?

Turning on Security auditing from Control Panel | Administrative Tools |
Local Security Policy | Local Policies | Audit Policies in the hope to
find anything there.

Are you logging the current identity of the process before it's
instantiating the XmlSerializer. Is it always the same or can it change?

Is this always happening on the same box for the same user or other
boxes/for other users, too?

If you really need to solve this problem: Take the source for the
XmlSerializerPreCompiler and build it into an test app that you run via
IEExec and then serialize the type in question. Make sure you put lots
of instrumentation in the app, too.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

-----Original Message-----
From: SJD [mailto:sj*@newsgroup.nospam]
Posted At: Thursday, December 09, 2004 9:22 AM
Posted To: microsoft.public.dotnet.xml
Conversation: XmlSerializer & FileNotFound (NOT the usual problem!)
Subject: Re: XmlSerializer & FileNotFound (NOT the usual problem!)

You might want to check, I'm 100% sure XmlSerializer builds randomly
named DLLs (into c:\temp). Well, to clarify; when running locally, the
built DLLs go into c:\temp. With a smart-client, I'm not sure where
they get built to (probably under the download cache).

I understand how the smart-client DLL load process works. Yup, all of
our binaries are strong-named. My question is, how does a smart-client deal with DLLs that XmlSerializer builds? We think that's the mechanism that has the problem.

Sean

Kevin Yu [MSFT] wrote:
Hi SJD,

I'm not quite sure what do you mean by "when does XmlSerializer decide
to
build the .DLL". XmlSerializer doesn't build DLLs. Actually, when we
run programs on smart client, the assembly was fist downloaded to the client and saved to c:\windows\assembly\download folder. Then it will be loaded by
CLR.

The second time we run this, CLR will first compare the DLL on the server
with the local copy to see if they are the same one, mainly using

the version number. If it is a strong named assembly, it will also

compare the
public key token. If same, client will use the local copy directly,
and if
not, download again from server.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."


Nov 12 '05 #7

P: n/a
SJD
Many, many thanks for replying. I've done some more research, and this
is what I've just logged with MSDN:

Problem:

We have an application (1 exe, and 30+ DLLs) that we run over
ZERO-DEPLOY. Occassionally (it's not predictable), when creating a new
XmlSerializer instance (passing in a Type instance) -- we get a run-time
exception, IO.FileNotFound.

The code it fails on is:

_settingsSerializer = new XmlSerializer(typeof(SpreadsheetPrintSettings));

NOTE: The class SpreadsheetPringSettings is one of our own.

**IMPORTANT**. Most of the time, this method works. For example, I
start the application 4 times. The first 3 times, the call will work.
On the 4th time, the method will exception. The code doesn't change.
NOTE; this method does NOT fail when running locally, it's only a
problem with zero-deployment.

Analysis:

I understand the basics of how XmlSerializer works. It builds temporary
DLLs, into the user's temp directory. In our case, this is c:\temp. In
an example failure, it generated the following files:

12/13/2004 12:08 PM 24,410 njygrzsw.0.cs
12/13/2004 12:08 PM 389 njygrzsw.cmdline
12/13/2004 12:08 PM 0 njygrzsw.dll
12/13/2004 12:08 PM 0 njygrzsw.err

For some reason, it did NOT build the DLL. Why? If you look at the
..cmdline file, it contains:

/t:library /utf8output /R:"c:\winnt\profiles\sdonovan\local
settings\application
data\assembly\dl2\5g68bm21.9e0\wyldql33.lmz\2839e8 b4\807f05db_7fdec401\framework.dll"
/R:"c:\winnt\microsoft.net\framework\v1.1.4322\msco rlib.dll"
/R:"c:\winnt\assembly\gac\system.xml\1.0.5000.0__b7 7a5c561934e089\system.xml.dll"
/out:"C:\Temp\njygrzsw.dll" /debug- /optimize+ /w:1 "C:\Temp\njygrzsw.0.cs"

IMPORTANT; the file:

c:\winnt\profiles\sdonovan\local settings\application
data\assembly\dl2\5g68bm21.9e0\wyldql33.lmz\2839e8 b4\807f05db_7fdec401\framework.dll

. . . DOES NOT exist.

I need to re-iterate, there is no corruption in the .cs file. It was
generated A-OK. I even copied out njygrzsw.cmdline and tried to compile
njygrzsw.0.cs, and it worked fine. I know that most problems with the
IO.FileNotFound exception are due (for whatever reason) to the generated
..cs file being bad. This isn't the case here.

When our C# application starts, via zero-deployment, I can get it to
provide a list of the static/run-time DLLs that it's loaded, and WHERE
they are loaded from. All of these files state they are from below the
path:

c:\winnt\profiles\sdonovan\local settings\application
data\assembly\dl2\5g68bm21.9e0\wyldql33.lmz

HOWEVER, even though the file **states** it's full file-name, if you
check to see the file, over half of them aren't actually there!

Many thanks,

Sean
Christoph Schittko [MVP] wrote:
Sean,

The temporary assemblies go into whatever is configured to be the temp
directory for executing application's identity. Check what's in the
%temp% environment variable for your logged on user. It should be
\Documents And Settings\<username>[.domainname]\Local Settings\Temp

Since Smart Clients can invoke Web services just fine (which may require
the XmlSerializer to run in a partially trusted context) -- as you
stated it's mostly likely not something in your program that's causing
the error, since it seems to be running OK sometimes.

To answer your question. It's my understanding that the XmlSerializer
builds the temporary assembly once per process, i.e. the first time you
instantiate it for a given type during the life time of a process. If
you launch the process again, then the XmlSerializer will create a new
assembly. However, this is only true if you are using the basic
constructor overload (new XmlSerializer(typeof(YourType))). Other
constructor overloads are not guaranteed to behave like that. They may
compile the assembly for every instantiation of an XmlSerializer
instance. I can go back and check if you're using any other overloads.

To help troubleshooting. Have you thought about:

Running FileMon from www.sysinternals.com to monitor for any file system
related problems during the compilation?

Turning on Security auditing from Control Panel | Administrative Tools |
Local Security Policy | Local Policies | Audit Policies in the hope to
find anything there.

Are you logging the current identity of the process before it's
instantiating the XmlSerializer. Is it always the same or can it change?

Is this always happening on the same box for the same user or other
boxes/for other users, too?

If you really need to solve this problem: Take the source for the
XmlSerializerPreCompiler and build it into an test app that you run via
IEExec and then serialize the type in question. Make sure you put lots
of instrumentation in the app, too.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

Nov 12 '05 #8

P: n/a
Hi Sean,

It is really weird that the app cannot find the files, since they are there.

Looking at the nature of this issue, it would require intensive
troubleshooting which would be done quickly and effectively with direct
assistance from a Microsoft Support Professional through Microsoft Product
Support Services. You can contact Microsoft Product Support directly to
discuss additional support options you may have available, by contacting us
at 1-(800)936-5800 or by choosing one of the options listed at
http://support.microsoft.com/default...d=sz;en-us;top.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #9

P: n/a
SJD
Well, I'm an MSDN Universal subscriber, and sent the issue in yesterday.
If "quickly and efficiently", means that they haven't got back to me
at all in 24 hours (not even with a courtesy call) then I guess you're
right.

:-)

Sean
Kevin Yu [MSFT] wrote:
Hi Sean,

It is really weird that the app cannot find the files, since they are there.

Looking at the nature of this issue, it would require intensive
troubleshooting which would be done quickly and effectively with direct
assistance from a Microsoft Support Professional through Microsoft Product
Support Services. You can contact Microsoft Product Support directly to
discuss additional support options you may have available, by contacting us
at 1-(800)936-5800 or by choosing one of the options listed at
http://support.microsoft.com/default...d=sz;en-us;top.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #10

P: n/a
SJD
I've just discovered the following. This is totally BIZARRE. To those
debugging XmlSerializer issues with smart-client/zero-deployment apps,
you aren't insane.

----->

OK, I've done some more investigation. I can categorically prove that
it's not a problem with XmlSerializer, and a problem with
zero-deployment/smart-client.

Our application is 1x EXE and approx. 40x DLLs. We launch the
application from IE, and it starts as IEExec.exe. Nothing wrong with that.

For fun, just as the application starts, I put some reflection code in
to locate the Assembly's filestore DLL location, and output whether the
file exists or not. I used the following code:

string message = "";

foreach( AssemblyName refAssemblyName in
Assembly.GetEntryAssembly().GetReferencedAssemblie s() )
{
// From the assembly-name, get the Assembly itself.
Assembly refAssembly = Assembly.Load( refAssemblyName );

message += refAssembly.Location + " = ";
message += File.Exists( refAssembly.Location ) ? "OK" : "Missing";
message += System.Environment.NewLine;
}

MessageBox.Show( message, "Assembly Locations" );

Guess what? EVERY time I try to start the application, an
**unpredictable** number of the assemblies are missing from the filestore!!

Example:

Test #1: Missing; summitoffice.dll, summitreports.dll
Test #2: Missing; framework.dll
Test #3: Missing; marketrisk.dll, quicktradeentry.dll,
sharedapplications.dll,
backendprocess.dll, securityadmin.dll, bondtrade.dll
Test #3: Missing; framework.dll, fxoption.dll, fxstatic.dll,
fxtrade.dll, fxviewer.dll,
static.dll, summitreports.dll

Now, this is definitely not normal. So, in my code, if I constructed an
XmlSerializer, with the constructor

XmlSerializer( Type type )

.. . . and that type lived in an assembly that was "missing", it would
error. Because, it externally builds the .cs file in c:\temp, and tries
to compile it, and link to the DLL which could be non-existent.

This is C#, .NET Framework V1.1 (NO SP), running in IE v6 and XP
Professional SP1.


SJD wrote:
Many, many thanks for replying. I've done some more research, and this
is what I've just logged with MSDN:

Problem:

We have an application (1 exe, and 30+ DLLs) that we run over
ZERO-DEPLOY. Occassionally (it's not predictable), when creating a new
XmlSerializer instance (passing in a Type instance) -- we get a run-time
exception, IO.FileNotFound.

The code it fails on is:

_settingsSerializer = new
XmlSerializer(typeof(SpreadsheetPrintSettings));

NOTE: The class SpreadsheetPringSettings is one of our own.

**IMPORTANT**. Most of the time, this method works. For example, I
start the application 4 times. The first 3 times, the call will work.
On the 4th time, the method will exception. The code doesn't change.
NOTE; this method does NOT fail when running locally, it's only a
problem with zero-deployment.

Analysis:

I understand the basics of how XmlSerializer works. It builds temporary
DLLs, into the user's temp directory. In our case, this is c:\temp. In
an example failure, it generated the following files:

12/13/2004 12:08 PM 24,410 njygrzsw.0.cs
12/13/2004 12:08 PM 389 njygrzsw.cmdline
12/13/2004 12:08 PM 0 njygrzsw.dll
12/13/2004 12:08 PM 0 njygrzsw.err

For some reason, it did NOT build the DLL. Why? If you look at the
.cmdline file, it contains:

/t:library /utf8output /R:"c:\winnt\profiles\sdonovan\local
settings\application
data\assembly\dl2\5g68bm21.9e0\wyldql33.lmz\2839e8 b4\807f05db_7fdec401\framework.dll"
/R:"c:\winnt\microsoft.net\framework\v1.1.4322\msco rlib.dll"
/R:"c:\winnt\assembly\gac\system.xml\1.0.5000.0__b7 7a5c561934e089\system.xml.dll"
/out:"C:\Temp\njygrzsw.dll" /debug- /optimize+ /w:1
"C:\Temp\njygrzsw.0.cs"

IMPORTANT; the file:

c:\winnt\profiles\sdonovan\local settings\application
data\assembly\dl2\5g68bm21.9e0\wyldql33.lmz\2839e8 b4\807f05db_7fdec401\framework.dll
. . . DOES NOT exist.

I need to re-iterate, there is no corruption in the .cs file. It was
generated A-OK. I even copied out njygrzsw.cmdline and tried to compile
njygrzsw.0.cs, and it worked fine. I know that most problems with the
IO.FileNotFound exception are due (for whatever reason) to the generated
.cs file being bad. This isn't the case here.

When our C# application starts, via zero-deployment, I can get it to
provide a list of the static/run-time DLLs that it's loaded, and WHERE
they are loaded from. All of these files state they are from below the
path:

c:\winnt\profiles\sdonovan\local settings\application
data\assembly\dl2\5g68bm21.9e0\wyldql33.lmz

HOWEVER, even though the file **states** it's full file-name, if you
check to see the file, over half of them aren't actually there!

Many thanks,

Sean
Christoph Schittko [MVP] wrote:
Sean,

The temporary assemblies go into whatever is configured to be the temp
directory for executing application's identity. Check what's in the
%temp% environment variable for your logged on user. It should be
\Documents And Settings\<username>[.domainname]\Local Settings\Temp

Since Smart Clients can invoke Web services just fine (which may require
the XmlSerializer to run in a partially trusted context) -- as you
stated it's mostly likely not something in your program that's causing
the error, since it seems to be running OK sometimes.

To answer your question. It's my understanding that the XmlSerializer
builds the temporary assembly once per process, i.e. the first time you
instantiate it for a given type during the life time of a process. If
you launch the process again, then the XmlSerializer will create a new
assembly. However, this is only true if you are using the basic
constructor overload (new XmlSerializer(typeof(YourType))). Other
constructor overloads are not guaranteed to behave like that. They may
compile the assembly for every instantiation of an XmlSerializer
instance. I can go back and check if you're using any other overloads.

To help troubleshooting. Have you thought about:

Running FileMon from www.sysinternals.com to monitor for any file system
related problems during the compilation?

Turning on Security auditing from Control Panel | Administrative Tools |
Local Security Policy | Local Policies | Audit Policies in the hope to
find anything there.

Are you logging the current identity of the process before it's
instantiating the XmlSerializer. Is it always the same or can it change?

Is this always happening on the same box for the same user or other
boxes/for other users, too?

If you really need to solve this problem: Take the source for the
XmlSerializerPreCompiler and build it into an test app that you run via
IEExec and then serialize the type in question. Make sure you put lots
of instrumentation in the app, too.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

Nov 12 '05 #11

P: n/a
Hi Sean,

If you open a case in PSS, they will contact you ASAP for sure. Maybe the
case is currently being routed to a support professional. Please wait and
be patient. If they still don't contact you, you can try to call the
service center for a strike. Thanks for your understanding.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Nov 12 '05 #12

P: n/a
I'd be very interested to hear about the resolution of that one.

Would you mind sending me the outcome of this? You can also contact
Microsoft Support (PSS) with this issue if you don't get a response --
they shouldn't charge for hotfixes due to bugs in the framework.

HTH,
Christoph Schittko
MS MVP XML
http://weblogs.asp.net/cschittko
-----Original Message-----
From: SJD [mailto:sj*@newsgroup.nospam]
Posted At: Tuesday, December 14, 2004 3:46 PM
Posted To: microsoft.public.dotnet.xml
Conversation: XmlSerializer & FileNotFound (NOT the usual problem!)
Subject: Re: XmlSerializer & FileNotFound (NOT the usual problem!)

I've just discovered the following. This is totally BIZARRE. To those debugging XmlSerializer issues with smart-client/zero-deployment apps,
you aren't insane.

----->

OK, I've done some more investigation. I can categorically prove that
it's not a problem with XmlSerializer, and a problem with
zero-deployment/smart-client.

Our application is 1x EXE and approx. 40x DLLs. We launch the
application from IE, and it starts as IEExec.exe. Nothing wrong with
that.

For fun, just as the application starts, I put some reflection code in
to locate the Assembly's filestore DLL location, and output whether the file exists or not. I used the following code:

string message = "";

foreach( AssemblyName refAssemblyName in
Assembly.GetEntryAssembly().GetReferencedAssemblie s() )
{
// From the assembly-name, get the Assembly itself.
Assembly refAssembly = Assembly.Load( refAssemblyName );

message += refAssembly.Location + " = ";
message += File.Exists( refAssembly.Location ) ? "OK" :
"Missing";
message += System.Environment.NewLine;
}

MessageBox.Show( message, "Assembly Locations" );

Guess what? EVERY time I try to start the application, an
**unpredictable** number of the assemblies are missing from the
filestore!!

Example:

Test #1: Missing; summitoffice.dll, summitreports.dll
Test #2: Missing; framework.dll
Test #3: Missing; marketrisk.dll, quicktradeentry.dll,
sharedapplications.dll,
backendprocess.dll, securityadmin.dll,
bondtrade.dll
Test #3: Missing; framework.dll, fxoption.dll, fxstatic.dll,
fxtrade.dll, fxviewer.dll,
static.dll, summitreports.dll

Now, this is definitely not normal. So, in my code, if I constructed an XmlSerializer, with the constructor

XmlSerializer( Type type )

. . . and that type lived in an assembly that was "missing", it would
error. Because, it externally builds the .cs file in c:\temp, and tries to compile it, and link to the DLL which could be non-existent.

This is C#, .NET Framework V1.1 (NO SP), running in IE v6 and XP
Professional SP1.


SJD wrote:
Many, many thanks for replying. I've done some more research, and this
is what I've just logged with MSDN:

Problem:

We have an application (1 exe, and 30+ DLLs) that we run over
ZERO-DEPLOY. Occassionally (it's not predictable), when creating a new XmlSerializer instance (passing in a Type instance) -- we get a run-time exception, IO.FileNotFound.

The code it fails on is:

_settingsSerializer = new
XmlSerializer(typeof(SpreadsheetPrintSettings));

NOTE: The class SpreadsheetPringSettings is one of our own.

**IMPORTANT**. Most of the time, this method works. For example, I
start the application 4 times. The first 3 times, the call will work. On the 4th time, the method will exception. The code doesn't change. NOTE; this method does NOT fail when running locally, it's only a
problem with zero-deployment.

Analysis:

I understand the basics of how XmlSerializer works. It builds temporary DLLs, into the user's temp directory. In our case, this is c:\temp. In an example failure, it generated the following files:

12/13/2004 12:08 PM 24,410 njygrzsw.0.cs
12/13/2004 12:08 PM 389 njygrzsw.cmdline
12/13/2004 12:08 PM 0 njygrzsw.dll
12/13/2004 12:08 PM 0 njygrzsw.err

For some reason, it did NOT build the DLL. Why? If you look at the
.cmdline file, it contains:

/t:library /utf8output /R:"c:\winnt\profiles\sdonovan\local
settings\application

data\assembly\dl2\5g68bm21.9e0\wyldql33.lmz\2839e8 b4\807f05db_7fdec401\f
ra mework.dll"
/R:"c:\winnt\microsoft.net\framework\v1.1.4322\msco rlib.dll"

/R:"c:\winnt\assembly\gac\system.xml\1.0.5000.0__b7 7a5c561934e089\system
..x ml.dll"
/out:"C:\Temp\njygrzsw.dll" /debug- /optimize+ /w:1
"C:\Temp\njygrzsw.0.cs"

IMPORTANT; the file:

c:\winnt\profiles\sdonovan\local settings\application

data\assembly\dl2\5g68bm21.9e0\wyldql33.lmz\2839e8 b4\807f05db_7fdec401\f
ra mework.dll


. . . DOES NOT exist.

I need to re-iterate, there is no corruption in the .cs file. It was generated A-OK. I even copied out njygrzsw.cmdline and tried to compile njygrzsw.0.cs, and it worked fine. I know that most problems with the IO.FileNotFound exception are due (for whatever reason) to the generated .cs file being bad. This isn't the case here.

When our C# application starts, via zero-deployment, I can get it to
provide a list of the static/run-time DLLs that it's loaded, and WHERE they are loaded from. All of these files state they are from below the path:

c:\winnt\profiles\sdonovan\local settings\application
data\assembly\dl2\5g68bm21.9e0\wyldql33.lmz

HOWEVER, even though the file **states** it's full file-name, if you
check to see the file, over half of them aren't actually there!

Many thanks,

Sean
Christoph Schittko [MVP] wrote:
Sean,

The temporary assemblies go into whatever is configured to be the temp directory for executing application's identity. Check what's in the
%temp% environment variable for your logged on user. It should be
\Documents And Settings\<username>[.domainname]\Local Settings\Temp

Since Smart Clients can invoke Web services just fine (which may
require the XmlSerializer to run in a partially trusted context) -- as you
stated it's mostly likely not something in your program that's causing the error, since it seems to be running OK sometimes.

To answer your question. It's my understanding that the XmlSerializer builds the temporary assembly once per process, i.e. the first time you instantiate it for a given type during the life time of a process. If you launch the process again, then the XmlSerializer will create a new assembly. However, this is only true if you are using the basic
constructor overload (new XmlSerializer(typeof(YourType))). Other
constructor overloads are not guaranteed to behave like that. They may compile the assembly for every instantiation of an XmlSerializer
instance. I can go back and check if you're using any other overloads.
To help troubleshooting. Have you thought about:

Running FileMon from www.sysinternals.com to monitor for any file system related problems during the compilation?

Turning on Security auditing from Control Panel | Administrative Tools |
Local Security Policy | Local Policies | Audit Policies in the hope
to find anything there.

Are you logging the current identity of the process before it's
instantiating the XmlSerializer. Is it always the same or can it

change?
Is this always happening on the same box for the same user or other
boxes/for other users, too?

If you really need to solve this problem: Take the source for the
XmlSerializerPreCompiler and build it into an test app that you run via IEExec and then serialize the type in question. Make sure you put lots of instrumentation in the app, too.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko


Nov 12 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.