WebServices and getting FileNotFoundException

  • Thread starter Thread starter Tim Mavers
  • Start date Start date
T

Tim Mavers

From googling my problem before posting, I learned that this seems to be a
very common problem with Web Services and dotnet. I read through countless
articles and suggestions but still could only find one way to fix my
problem, which IMHO, is not acceptable.

First let me explain what's happening:

We are using .NET 1.0 (forced by the client) and have built an ASP.NET
application that communicates with our business tier through Web Services.
This was all designed and built in Visual Studio.NET 2002 (the original
VS.NET) and is running on various WinXP and Windows 2000 Server machines.

Like many web applications, a user is required to log on to the 'site'.
This is done through a web service call. The problem is that when the
WebService proxy code is called, an exception is thrown with this message:

"File or assembly name wwapnylv.dll, or one of its dependencies, was not
found."

The dll name, in this case wwapnylv, is different each call and appears to
be generated dynamically by the .NET runtime in the C:\WinNT\Temp directory.
I have confirmed this with a File Monitoring tool. At first I assumed it
was a permissions problem, so I made sure that:

- The local ASPNET and I_USR* accts had full NTFS access to C:\WinNT\Temp

- The local ASPNET and I_USR* accts had full NTFS to the 'Temporary ASP.NET
Files' inside the Framework directory in WinNT\

- After reading a solution posted by someone, I gave the local
NETWORK_SERVICE user full NTFS rights to both of the above directories.

- I reran aspnet_config script on the box (it actually happens on every
machine we use--probably 50 or more so I discounted that this was some
corrupt configuration issue).

It still did not work. The only way I could get it to work, and it worked
immediately was to change what user the aspnet_wp.exe process runs as from
the default of "MACHINE" to "SYSTEM". Once it became SYSTEM everything
worked flawlessly.

The problem is this is a pretty big jump in security rights. This totally
sounds like a permissions problem as running as SYSTEM grants many more
privileges.

What confused me however is that in many posts people said that by
alternating their code such as ensuring there was a default constructor in
their proxy, or realized their XML was invalid. So basically I am at a
loss. Right now I am running it as SYSTEM, but I would really like to full
understand why this is (especially if Microsoft is so vocal about how they
are focusing on security).

Any ideas?
 
The symptom you describe,

"file or assembly named xxxxxx.dll, or one if its dependencies, was not
found"

can result from a number of different problems:
- a security issue, as you initially suspected
- if you compile an app with .NET framework 1.1 and run on .NET framework
1.0
- an XML serialization failure - the XmlSerializer chokes on some complex
classes

Of course the bad news is that this error is totally opaque and gives you no
hints as to which of the reasons caused the problem. :< Mea culpa. We
are working on improviing this situation for future releases.

First, can we clarify, where is this exception occurring - on the server
side or client side?

If on the server side,
You said, "appears to
be generated dynamically by the .NET runtime in the C:\WinNT\Temp"

Appears to be, based on what?

Can you manually create a file in c:\winnt\temp from an ASP.NET page or
webservice?

If this is an XmlSerializer problem, check out
http://weblogs.asp.net/cschittko/articles/33045.aspx
for some hints on how to troubleshoot it.
 
Dino Chiesa said:
The symptom you describe,

"file or assembly named xxxxxx.dll, or one if its dependencies, was not
found"

First, can we clarify, where is this exception occurring - on the server
side or client side?
Click to expand...

It's on the server-side... When I debug the code, the exception occurs when
we first instantiate our WebService Proxy class.
The only thing I see in the code that could be a problem (I wasn't the
original author and they no longer work here so I am not sure for the
rationale), but our WebServiceProxy actually inherits from a custom class
which then inherits from the WebServicesClientProtocol class.

Since we have this class in the middle, is there anything I might look for
to make sure it has been implemented correctly?

The thing that really stumps me is that if I change the user ASP runs as
from MACHINE to SYSTEM, everything works great. But that's a pretty big
security risk in our case. That said, this sounds like a permission
problem (can't create a file in C:\WinNT\Temp). Although I believe I have
set the appropriate permissions, what is the easiest way to create a file
from ASP.NET to a specific local directory?

Thanks,
 
A little more information. I read through the XmlSerializer link you
included which is a great resouce btw, thks!

I noticed that there is a switch that can be set in my web.config which
tells the XmlSerializer to leave the working files that are generated when
accessing a web service.

That said, I enabled the switch and was able to see several files in my
C:\WinNT\Temp directory as expected. To me, this proves the ASP.NET code
has write access to C:\WinNT\Temp so it's not a permissions problem, well
probably not.

I still can't figure out why changing the ASP.NET user to SYSTEM in
machine.config fixes my problem (or hides some subtlety that could be the
real problem), because everything works _perfectly_ when the ASP.NET user is
set to SYSTEM.

Is there anything you can think of in the XMLSerializer logic that would
require some implicit security rights that I might not be aware of?

There were four files generated in the C:\WinNT\Temp directory when the
exception was caught in my ASP.NET code. The files are:

_tp0kj5z.0.cs
_tp0kj5z.cmdline
_tp0kj5z.err
_tp0kj5z.out

_tp0kj5z is the assembly reported as not be found in the exception block.
_tp0kj5z.err is empty (0 bytes)
_tp0kj5z.out contains the following:

C:\WINNT\system32> "c:\winnt\microsoft.net\framework\v1.0.3705\csc.exe"
/t:library /utf8output
/R:"c:\winnt\assembly\gac\system.xml\1.0.3300.0__b77a5c561934e089\system.xml
..dll" /R:"c:\winnt\microsoft.net\framework\v1.0.3705\temporary asp.net
files\mywebapp\d7cab26e\fd15af93\assembly\dl2\3dbca1e0\f04dcd2b_8a28c401\myw
ebapp.references.websvc.dll"
/R:"c:\winnt\microsoft.net\framework\v1.0.3705\mscorlib.dll"
/out:"C:\WINNT\TEMP\_tp0kj5z.dll" /D:DEBUG /debug+ /optimize- /warnaserror
/w:1
/nowarn:183,184,602,612,626,672,679,1030,1200,1201,1202,1203,1522,1570,1574,
1580,1581,1584,1589,1590,1592,1596,1598,1607,2002,2014,2023,3012,5000
"C:\WINNT\TEMP\_tp0kj5z.0.cs"

Microsoft (R) Visual C# .NET Compiler version 7.00.9466
for Microsoft (R) .NET Framework version 1.0.3705
Copyright (C) Microsoft Corporation 2001. All rights reserved.

fatal error CS0007: Unexpected common language runtime initialization
error -- 'Class not registered '

---cut---

Any ideas?

Thanks again for your help,
 
There might be some other dependency that is not available. Use the FusLogVw
app to help you debug the assemblies that are being loaded or that have
failed to load.

Chris Rolon
 
Weird.
"Class not registered"
It looks like your ASP.NET app cannot run the C# compiler.
 
Dino Chiesa said:
Weird.
"Class not registered"
It looks like your ASP.NET app cannot run the C# compiler.
Click to expand...

While I know it's hard to predict, what would be some of the basic causes of
this? As I mentioned before, if we change the ASP.NET user in
machine.config from "machine" to "system", everything works great, but at
the expense of a huge security issue. I have tried all of the suggestions
posted here, but still can't track it down.

Can you (or anyone else) provide a little information on just what happens
when a web service is first called? Maybe that might identify some area
where the problem lies.

It sounds like a permission problem, but what exactly is granted to the
"system" account. I assumed pretty much everything, and when set to
"machine" (i.e. machine\ASPNET user), only a limited set of privileges are
granted--but enough to run the basic ASP.NET (including web service)
framework).

Thanks,
 
Back
Top