Remote Administration

  • Thread starter Thread starter Thom Little
  • Start date Start date
T

Thom Little

I developed and run some ASP.NET applications on my local machine. I have
IIS 5.0 available on two servers from two different ISPs. I would like to
have the applications served from the two ISP controlled machines. I have
FTP-access (only) to the two remote servers.

Simple .aspx applications execute (such as trace) but .aspx applications
with a .aspx.cs code behind file fail on the statement ...

<%@ Page language="c#" Codebehind="Sample.aspx.cs" AutoEventWireup="false"
Inherits="Sample.Sample" %>

.... because it can not resolve the Sample.Sample

Any suggestions on how to proceed?
Is there documentation available on installing an application on a remote
ISP-controlled machine?
 
Hello Thom,

Thanks for your post. As I understand, the problem you are facing is that
your ASP .NET web pages with codebehind do not work after deploying to
remote web server. Please correct me if there is any misunderstanding.

As you know, ASP .NET application includes a project DLL if the code-behind
features of .asp files are used. This DLL together with other assemblies
are located in the bin folder underneath the virtual directory of the
application. Did you also copy them to your target machine? For simple Web
applications, it is often appropriate to XCOPY all the files of your ASP
.NET application to the target computer. Please refer to the following MSDN
article for detailed ASP .NET deployment information:

Deploying .NET Applications Lifecycle Guide
http://www.microsoft.com/italy/net/business/netarchitect/dotNET_application_
lifecycle_guide.pdf

Hope this helps.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Thank you for the response.

The problem I was having was that the /bin directory had to be in the root
of the website in order for the class resolution to occur. In my case it
was not. Simply creating a /bin in the root and moving the dll into it
resolved my problem.

My guess is that this is a "feature".
 
Back
Top