Help! - Could not load type error

[Paul Smith]

I am hoping this is a simple problem for someone. We have two development
servers, DEVNET (a web server) and DEVSQL (a DB / File Server). We have
recently moved all of our .NET source code from an old server to DEVSQL,
where it compiles beautifully. We have an application with several
projects. One of them (Pages) has all of the ASPX files, the Global.asax
file, etc. in it. The other projects in the solution are made up of the C#
files for the business logic. When attempting to run the application, we
receive the following error:

Parser Error
Description: An error occurred during the parsing of a resource required to
service this request. Please review the following specific parse error
details and modify your source file appropriately.

Parser Error Message: Could not load type 'EGG.Yeoman.Pages.Global'.

Source Error:
Line 1: <%@ Application CodeBehind="Global.asax.cs"
Inherits="EGG.Yeoman.Pages.Global" %>

Source File: \\devsql\Source Code\Solutions\EGG.Yeoman.Pages\global.asax
Line: 1

----------------------------------------------------------------------------
----

Version Information: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET
Version:1.1.4322.573

I have tried every approach found in the various news groups I have
searched. The standard (and as far as I can tell only) Microsoft answer
(recompile) does NOT solve the problem. The appropriate DLLs are ALL
included in the \bin subdirectory of the IIS virtual directory.

Anyone have any ideas? Is this a problem caused by creating the virtual
directory with a UNC path to its actual content? If so, is it possible to
host an ASP.NET application from a virtual directory with a UNC path to a
different physical server?

Paul

[Scott Allen]

Hi Paul:

You hit upon the problem in the second paragraph.

I have tried every approach found in the various news groups I have
searched. The standard (and as far as I can tell only) Microsoft answer
(recompile) does NOT solve the problem. The appropriate DLLs are ALL
included in the \bin subdirectory of the IIS virtual directory.

Anyone have any ideas? Is this a problem caused by creating the virtual
directory with a UNC path to its actual content? If so, is it possible to
host an ASP.NET application from a virtual directory with a UNC path to a
different physical server?

There are two obstacles to overcome when pointing a vdir to a UNC
share and trying to run an ASP.NET web app.

The first obstacle happens because a web app must run in "full trust"
mode, and .NET does not fully trust an assembly on a remote machine
unless you tell it to. Go to the Microsoft .NET Framework Wizards in
Administrative Tools and walk through the steps for "Trust an
Assembly".

Secondly, the web app has to be able to read the files on the remote
share. If the web app is running under the ASPNET account you could
duplicate the account on the second machine and synchronize the
passwords, or run your web app under a "least privileged" domain
account.

HTH,

--
Scott
http://www.OdeToCode.com

[Paul]

Scott,

Thank you for the information. This looks very promising. Our network administrator and I did some additional research, though, and I have another question. Is using a UNC path for the virtual directory's content compatible with using impersonation / delegation in the ASP.NET application. A presentation we found by Erik Olson form MSDN TV seemed to suggest that impersonation would not work in this case. What are the implications for using impersonation when the content of the application's virtual directory is found on a UNC share?

"Scott Allen" wrote:

Hi Paul:

You hit upon the problem in the second paragraph.

I have tried every approach found in the various news groups I have
searched. The standard (and as far as I can tell only) Microsoft answer
(recompile) does NOT solve the problem. The appropriate DLLs are ALL
included in the \bin subdirectory of the IIS virtual directory.

Anyone have any ideas? Is this a problem caused by creating the virtual
directory with a UNC path to its actual content? If so, is it possible to
host an ASP.NET application from a virtual directory with a UNC path to a
different physical server?

There are two obstacles to overcome when pointing a vdir to a UNC
share and trying to run an ASP.NET web app.

The first obstacle happens because a web app must run in "full trust"
mode, and .NET does not fully trust an assembly on a remote machine
unless you tell it to. Go to the Microsoft .NET Framework Wizards in
Administrative Tools and walk through the steps for "Trust an
Assembly".

Secondly, the web app has to be able to read the files on the remote
share. If the web app is running under the ASPNET account you could
duplicate the account on the second machine and synchronize the
passwords, or run your web app under a "least privileged" domain
account.

HTH,

--
Scott
http://www.OdeToCode.com

[Paul]

Scott,

Thank you for the information. This looks very promising. Our network administrator and I did some additional research, though, and I have another question. Is using a UNC path for the virtual directory's content compatible with using impersonation / delegation in the ASP.NET application. A presentation we found by Erik Olson form MSDN TV seemed to suggest that impersonation would not work in this case. What are the implications for using impersonation when the content of the application's virtual directory is found on a UNC share?

"Scott Allen" wrote:

Hi Paul:

You hit upon the problem in the second paragraph.

I have tried every approach found in the various news groups I have
searched. The standard (and as far as I can tell only) Microsoft answer
(recompile) does NOT solve the problem. The appropriate DLLs are ALL
included in the \bin subdirectory of the IIS virtual directory.

Anyone have any ideas? Is this a problem caused by creating the virtual
directory with a UNC path to its actual content? If so, is it possible to
host an ASP.NET application from a virtual directory with a UNC path to a
different physical server?

There are two obstacles to overcome when pointing a vdir to a UNC
share and trying to run an ASP.NET web app.

The first obstacle happens because a web app must run in "full trust"
mode, and .NET does not fully trust an assembly on a remote machine
unless you tell it to. Go to the Microsoft .NET Framework Wizards in
Administrative Tools and walk through the steps for "Trust an
Assembly".

Secondly, the web app has to be able to read the files on the remote
share. If the web app is running under the ASPNET account you could
duplicate the account on the second machine and synchronize the
passwords, or run your web app under a "least privileged" domain
account.

HTH,

--
Scott
http://www.OdeToCode.com

[Scott Allen]

Paul:

That could be another problem. I've never tried running off a UNC
share with impersonation, but you might be running into the "two-hop"
rule, where the user can be impersonated on the web server, but the
web server cannot use that security context to access network
resources without some configuration, specifically you have to set up
Kerberos.

This KB article has some more info:
http://support.microsoft.com/default.aspx?kbid=810572

On Tue, 6 Jul 2004 06:12:01 -0700, "Paul"
<Pa**@discussions.microsoft.com> wrote:

Scott,

Thank you for the information. This looks very promising. Our network administrator and I did some additional research, though, and I have another question. Is using a UNC path for the virtual directory's content compatible with using impersonation / delegation in the ASP.NET application. A presentation we found by Erik Olson form MSDN TV seemed to suggest that impersonation would not work in this case. What are the implications for using impersonation when the content of the application's virtual directory is found on a UNC share?

"Scott Allen" wrote:

Hi Paul:

You hit upon the problem in the second paragraph.

>I have tried every approach found in the various news groups I have
>searched. The standard (and as far as I can tell only) Microsoft answer
>(recompile) does NOT solve the problem. The appropriate DLLs are ALL
>included in the \bin subdirectory of the IIS virtual directory.
>
>Anyone have any ideas? Is this a problem caused by creating the virtual
>directory with a UNC path to its actual content? If so, is it possible to
>host an ASP.NET application from a virtual directory with a UNC path to a
>different physical server?
>

There are two obstacles to overcome when pointing a vdir to a UNC
share and trying to run an ASP.NET web app.

The first obstacle happens because a web app must run in "full trust"
mode, and .NET does not fully trust an assembly on a remote machine
unless you tell it to. Go to the Microsoft .NET Framework Wizards in
Administrative Tools and walk through the steps for "Trust an
Assembly".

Secondly, the web app has to be able to read the files on the remote
share. If the web app is running under the ASPNET account you could
duplicate the account on the second machine and synchronize the
passwords, or run your web app under a "least privileged" domain
account.

HTH,

--
Scott
http://www.OdeToCode.com

--
Scott
http://www.OdeToCode.com

[Scott Allen]

Paul:

That could be another problem. I've never tried running off a UNC
share with impersonation, but you might be running into the "two-hop"
rule, where the user can be impersonated on the web server, but the
web server cannot use that security context to access network
resources without some configuration, specifically you have to set up
Kerberos.

This KB article has some more info:
http://support.microsoft.com/default.aspx?kbid=810572

On Tue, 6 Jul 2004 06:12:01 -0700, "Paul"
<Pa**@discussions.microsoft.com> wrote:

Scott,

Thank you for the information. This looks very promising. Our network administrator and I did some additional research, though, and I have another question. Is using a UNC path for the virtual directory's content compatible with using impersonation / delegation in the ASP.NET application. A presentation we found by Erik Olson form MSDN TV seemed to suggest that impersonation would not work in this case. What are the implications for using impersonation when the content of the application's virtual directory is found on a UNC share?

"Scott Allen" wrote:

Hi Paul:

You hit upon the problem in the second paragraph.

>I have tried every approach found in the various news groups I have
>searched. The standard (and as far as I can tell only) Microsoft answer
>(recompile) does NOT solve the problem. The appropriate DLLs are ALL
>included in the \bin subdirectory of the IIS virtual directory.
>
>Anyone have any ideas? Is this a problem caused by creating the virtual
>directory with a UNC path to its actual content? If so, is it possible to
>host an ASP.NET application from a virtual directory with a UNC path to a
>different physical server?
>

There are two obstacles to overcome when pointing a vdir to a UNC
share and trying to run an ASP.NET web app.

The first obstacle happens because a web app must run in "full trust"
mode, and .NET does not fully trust an assembly on a remote machine
unless you tell it to. Go to the Microsoft .NET Framework Wizards in
Administrative Tools and walk through the steps for "Trust an
Assembly".

Secondly, the web app has to be able to read the files on the remote
share. If the web app is running under the ASPNET account you could
duplicate the account on the second machine and synchronize the
passwords, or run your web app under a "least privileged" domain
account.

HTH,

--
Scott
http://www.OdeToCode.com

--
Scott
http://www.OdeToCode.com