Difference between ASP.NET Website and ASP.NET Application Project

[daveh551]

What, from a high level point of view, is the difference (in Visual
Studio 2005) between Website (accessed with Open Website or Create
Website from the StartPage) that is an ASP.NET Website, and a Project
that is created with the "ASP.NET Application" template?

I see some obvious differences: the Project creates the working folder
under the Visual Studio 2005\Projects directory, while the Website
creates it in the Inetpub\wwwroot directory. And there are some more
subtle differences that I don't understand as well. The project
creates some .cs (in C#) files for a lot of the things that the
website does not (e.g., in the Website, there is no .cs file generated
for DataSets (.xsd files), and theres no <page>.designer.cs file
generated for pages). The project uses different namespace
definitions for the same files in the same relative directory
positions. And it seems that some of the web administration tools (the
whole Website menu, including "Copy Web") is missing when you're
working with a project. Also, it appears (I'm not sure) that the
compiled code for the website is never stored (it seems to be being
regenerated on the fly when I access the website.)

I see these differences, but I don't understand why they're there or
to what purpose they are there. Can someone explain it to me?

Thanks.

 

[Stan]

What, from a high level point of view, is the difference (in Visual
Studio 2005) between Website (accessed with Open Website or Create
Website from the StartPage) that is an ASP.NET Website, and a Project
that is created with  the "ASP.NET Application" template?

I see some obvious differences: the Project creates the working folder
under the Visual Studio 2005\Projects directory, while the Website
creates it in the Inetpub\wwwroot directory. And there are some more
subtle differences that I don't understand as well.  The project
creates some .cs (in C#) files for a lot of the things that the
website does not (e.g., in the Website, there is no .cs file generated
for DataSets (.xsd files), and theres no <page>.designer.cs file
generated for pages).  The project uses different namespace
definitions for the same files in the same relative directory
positions. And it seems that some of the web administration tools (the
whole Website menu, including "Copy Web") is missing when you're
working with a project.  Also, it appears (I'm not sure) that the
compiled code for the website is never stored (it seems to be being
regenerated on the fly when I access the website.)

I see these differences, but I don't understand why they're there or
to what purpose they are there. Can someone explain it to me?

Thanks.

Hi

The project form of a web app is similar to the previous version of
visual studio (VS2003) where everything is compiled into a DLL
assembly file. ASP.NET 1.1 could only support "code behind" in this
manner, the alternative being script embedded in the .aspx files.

ASP.NET 2.0 allows code behind files (.cs files) to accompany
the .aspx in the deployed version, whereupon it is compiled "on the
fly" by the web server. The "web site" form of web application in
VS2005 works on the same principle. It has the advantage of being
simpler to deploy and update. In addition to the project folder it can
create a website folder in your documents area instead of using
inetpub/wwwroot (which may not have been installed anyway). In this
mode VS2005 runs its own web server software using a special port
number.

Hope that throws some light on it.

 

[daveh551]

Hi

The project form of a web app is similar to the previous version of
visual studio (VS2003) where everything is compiled into a DLL
assembly file. ASP.NET 1.1 could only support "code behind" in this
manner, the alternative being script embedded in the .aspx files.

ASP.NET 2.0 allows code behind files (.cs files) to accompany
the .aspx in the deployed version, whereupon it is compiled "on the
fly" by the web server. The "web site" form of web application in
VS2005 works on the same principle. It has the advantage of being
simpler to deploy and update. In addition to the project folder it can
create a website folder in your documents area instead of using
inetpub/wwwroot (which may not have been installed anyway). In this
mode VS2005 runs its own web server software using a special port
number.

Hope that throws some light on it.

Thanks, Stan. That does help some. But I guess it raises the question
of "WHY???" Why would you want to compile something everytime you run
the web application, instead of compiling it and downloading the DLL?
And it seems to expose you to the possibility of more inconsistencies
if your execution environment is different from your development
envirionment. Like right now I'm having fits because it's trying to
compile the .XSD Dataset definition files on the server that I've
deployed to, and immediately cratering (on line 1) for no apparent
reason, but apparently SOMETHING is different about the compiler or
environment that is running on the server compared to what I built
with. If I was deploying the .dll , I wouldn't have that problem.

 

[Stan]

Thanks, Stan.  That does help some. But I guess it raises the question
of "WHY???" Why would you want to compile something everytime you run
the web application, instead of compiling it and downloading the DLL?
And it seems to expose you to the possibility of more inconsistencies
if your execution environment is different from your development
envirionment. Like right now I'm having fits because it's trying to
compile the .XSD Dataset definition files on the server that I've
deployed to, and immediately cratering (on line 1) for no apparent
reason, but apparently SOMETHING is different about the compiler or
environment that is running on the server compared to what I built
with.  If I was deploying the .dll , I wouldn't have that problem.- Hidequoted text -

- Show quoted text -

The DLL file does not contain code that can be executed directly by
the Server processor. It's an intermediate language that saves time
parsing the source code from scratch. Issues due to compiler version
differences might still arise.

However if you suspect that then try using the option of "publishing"
the web site which will create a DLL out of the .cs and other files.

 

[daveh551]

The DLL file does not contain code that can be executed directly by
the Server processor. It's an intermediate language that saves time
parsing the source code from scratch. Issues due to compiler version
differences might still arise.

However if you suspect that then try using the option of "publishing"
the web site which will create a DLL out of the .cs and other files.

THANK YOU, Thank you, thank you, Stan. Publishing solved my parser
error problem. And MOST everything seems to be working now EXCEPT for
one critical thing. My login page (which, of course, is critical to
the guts of the site!) blows up with this error:

Compilation Error
Description: An error occurred during the compilation of a resource
required to service this request. Please review the following specific
error details and modify your source code appropriately.

Compiler Error Message: CS0030: Cannot convert type 'ASP.login_aspx'
to 'System.Web.UI.WebControls.Login'

Source Error:

[No relevant source lines]


Here is the .aspx file for that page:

<%@ page language="C#" masterpagefile="~/TakeCharge.master"
autoeventwireup="true" inherits="Login, App_Web_8mstyslz"
title="Login" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent"
Runat="Server">
<h1>Login now to create, revise, or view your plan.
</h1> <asp:Login ID="Login1" runat="server"
OnLoggedIn="Login_LoggedIn">
</asp:Login>
<br />

[followed by some text and links]

Once again, it runs fine in development, and it runs fine when moved
over to my Win 2000 Server machine. I haven't a clue as to what's
wrong.

If it will help, feel free to visit the site and look at the error
output. It put out a couple hundred lines of compiler source, which I
didn't think it was worthwhile to copy in here. The site is
www.takechargeofyourdebts.com, and the CustomErrors is turned off (as
of 4/18/2008 - I obviously won't leave it that way once I get this
resolved.)

Thanks for your help.

 

[daveh551]

The DLL file does not contain code that can be executed directly by
the Server processor. It's an intermediate language that saves time
parsing the source code from scratch. Issues due to compiler version
differences might still arise.

However if you suspect that then try using the option of "publishing"
the web site which will create a DLL out of the .cs and other files.

Stan, I thought I had replied already thanking you for your help.
Publishing gets me over the hurdle of the parser error in the XSD
file. It generated a strange compilation error though. The login
page bombed out, saying it couldn't convert type ASP.login_aspx to
System.Web.UI.Controls.Login. I don't get that error when I run (even
the precompiled version) on my local server, but I figured out that it
seems to have to do with having a page named (and therefore a class
named) the same as one of the controls, namely Login (the page) and
Login (the control). This is rather strange since it's my
understanding that "Login.aspx" is the default and accepted name for
the login page used by forms authentication. But I was able to work
around it by creating a new page called "LoginPage.aspx", and
redirecting the forms authentication there.

Now it's just getting a security exception when it (apparently) tries
to open the Config file, but we're getting way outside the original
scope of this thread.

Again, thank you for your help.