IIS does not find precompiled ASP.NET code

[Martin Plechsmid]

Hello.

(Details at the end of this post.)

I have published my web site from VS2008 with the non-updatable option (i.e.
updatable="false" in PrecompiledApp.config). The site is precompiled,
however when requesting an .asmx file, the server responds with

"The file '/test/PdfServiceLib.asmx' has not been pre-compiled, and
cannot be requested."

I used the ProcessMonitor to see what's happenning, and the w3wp.exe process
behaves strangely. Six times (6x !) it finds the
"pdfservicelib.asmx.cdcab7d2.compiled" successfully in the bin directory,
but the seventh time it looks for it in the "Temporary ASP.NET Files"
directory under the .NET installation - and fails.

Why does IIS look for the pre-compiled file in the ASP.NET cache, when the
site is marked as non-updatable? What do I need to set up in order IIS does
not copy the files into the ASP.NET cache?

Thank you,
Martin.

------------------
Details:

The ultimate purpose of making the site non-updatable was to prevent IIS to
copy the precompiled files into the ASP.NET cache. The asmx file refers to a
..NET assembly that depends on native DLL libraries. The problem is that when
the site is updatable, IIS copies the assembly into the ASP.NET cache, and
the assembly is then unable to find the native DLLs - because IIS leaves the
DLLs at the original place and does not copy them into the ASP.NET cache as
well.

PdfServiceLib.asmx contains a single line:
<%@ WebService Class="PdfServiceLib.PdfServiceLibClass" %>
When the site is compiled, the "bin/pdfservicelib.asmx.cdcab7d2.compiled" is
created from the PdfServiceLib.asmx file.

The PdfServiceLib.dll assembly implementing the
="PdfServiceLib.PdfServiceLibClass" class is placed in the bin/ folder. It
is written in C++/CLI and depends on the native C++ runtime DLLs. Besides
the ASP.NET HTTP module interface it supports also the COM interface, and
this way it works correctly.

The computer is Windows 2003 Server SP2, x64 edition, IIS 6. The DLLs are
32-bit and the IIS is switched to the 32-bit mode. trhe assembly uses .NET
2.0.

 

[Guest]

Hello.

(Details at the end of this post.)

I have published my web site from VS2008 with the non-updatable option (i..e.
updatable="false" in PrecompiledApp.config). The site is precompiled,
however when requesting an .asmx file, the server responds with

    "The file '/test/PdfServiceLib.asmx' has not been pre-compiled, and
cannot be requested."

I used the ProcessMonitor to see what's happenning, and the w3wp.exe process
behaves strangely. Six times (6x !) it finds the
"pdfservicelib.asmx.cdcab7d2.compiled" successfully in the bin directory,
but the seventh time it looks for it in the "Temporary ASP.NET Files"
directory under the .NET installation - and fails.

Why does IIS look for the pre-compiled file in the ASP.NET cache, when the
site is marked as non-updatable? What do I need to set up in order IIS does
not copy the files into the ASP.NET cache?

Thank you,
       Martin.

------------------
Details:

The ultimate purpose of making the site non-updatable was to prevent IIS to
copy the precompiled files into the ASP.NET cache. The asmx file refers to a
.NET assembly that depends on native DLL libraries. The problem is that when
the site is updatable, IIS copies the assembly into the ASP.NET cache, and
the assembly is then unable to find the native DLLs - because IIS leaves the
DLLs at the original place and does not copy them into the ASP.NET cache as
well.

PdfServiceLib.asmx contains a single line:
    <%@ WebService Class="PdfServiceLib.PdfServiceLibClass" %>
When the site is compiled, the "bin/pdfservicelib.asmx.cdcab7d2.compiled" is
created from the PdfServiceLib.asmx file.

The PdfServiceLib.dll assembly implementing the
="PdfServiceLib.PdfServiceLibClass" class is placed in the bin/ folder. It
is written in C++/CLI and depends on the native C++ runtime DLLs. Besides
the ASP.NET HTTP module interface it supports also the COM interface, and
this way it works correctly.

The computer is Windows 2003 Server SP2, x64 edition, IIS 6. The DLLs are
32-bit and the IIS is switched to the 32-bit mode. trhe assembly uses .NET
2.0.

Is /test a virtual directory under root? Can it be the same case as it
is described here
http://blogs.msdn.com/asiatech/arch...een-pre-compiled-and-cannot-be-requested.aspx

?

 

[Martin Plechsmid]

Is /test a virtual directory under root? Can it be the same case as it

is described here
http://blogs.msdn.com/asiatech/arch...een-pre-compiled-and-cannot-be-requested.aspx
?

Thank you for your response. Everything is compiled and installed correctly,
but doesn't work.

In fact, I created a clean webservice project with a simple "hello world"
..asmx page. It worked correctly - untill I copied the PdfServiceLib.dll file
into the bin folder! Even though the PdfServiceLib.dll is totally unrelated
to the "hello world" asmx page. When I copied another dll instead into the
bin folder, the "hello world" page continued working without any problem. So
the fatal result is caused by the PdfServiceLib.dll alone.

I expect that IIS tries to load all DLLs that it finds in the bin directory,
but as PdfserviceLib.dll fails to load, IIS signals a configuration error:

"The specified module could not be found. (Exception from HRESULT:
0x8007007E)"

and in Event Viewer:

"Generate Activation Context failed for
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
Files\testsite2\acddac77\70d7c63b\assembly\dl3\a26fae56\2c31b76e_47e1ca01\PdfServiceLib.DLL.
Reference error message: The referenced assembly is not installed on your
system."

When I request PdfServiceLib.asmx directly (instead of the "hello world"
asmx), I get the following error:

"The file '/TestSite2/PdfserviceLib.asmx' has not been pre-compiled, and
cannot be requested."

and in Event Viewer:

Event code: 3008
Event message: A configuration error has occurred.
Event time: 27.4.2010 9:43:42
Event time (UTC): 27.4.2010 7:43:42
Event ID: fe254c7c2f834582bd6a76acc81a67f8
Event sequence: 7
Event occurrence: 2
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1/Root/TestSite2-15-129168275203231221
Trust level: Full
Application Virtual Path: /TestSite2
Application Path: c:\inetpub\wwwroot\TestSite2\
Machine name: XXXXX

Process information:
Process ID: 1104
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE

Exception information:
Exception type: InvalidOperationException
Exception message: Unable to handle request.

Request information:
Request URL: http://localhost/TestSite2/Service.asmx
Request path: /TestSite2/Service.asmx
User host address: 127.0.0.1
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE

Thread information:
Thread ID: 6
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: False
Stack trace: at
System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type,
HttpContext context, HttpRequest request, HttpResponse response, Boolean&
abortProcessing)
at
System.Web.Services.Protocols.WebServiceHandlerFactory.CoreGetHandler(Type
type, HttpContext context, HttpRequest request, HttpResponse response)

Now it is clear that I'm returning to my original problem that I wanted to
get around by setting the site non-updatable. That is, IIS probably copies
all assemblies that it finds in the bin directory into its "ASP.NET Temp
Files" cache, without copying all DLLs on which the assemblies depend.

Any suggestion?

Martin.

 

[Martin Plechsmid]

More info:

When I manually copy all the required DLLs into the "ASP.NET Temporary
Files" cache directory, the webservice begins miraculously to work. (Of
course, this cannot be used as a production solution.) This confirms that
the only problem is in that IIS doesn't copy all the required DLLs together
with the assemblies into the cache.

It seems, however, that on computers with Visual Studio installed the
webservice works, but on computers without it the webservice doesn't work.
Tested on two computers with and two computers without VS. Independently
whether the computer is a server or a workstation, whether 32 bit or 64 bit.
Strange.

Any idea?

Thank you,
Martin.