what's different between asp application and web site

[Guest]

Hi,

I posted this in wrong group, so just re-post here.
There are two ways to create web-based application or web service, from VS
start page, click on File and New, two options you can choose, one is
Projects which leads you to create ASP.NET Web Application or ASP.NET Web
Service Application. Another one is Web Site which leads you to create
ASP.NET Web Site or ASP.NET Web Service.
My question is what is the difference between these two ways. Especially in
terms of production performance, maintainance, resource consuming.
I got an answer saying compatibility is slightly different from VS2003.
Anyway what's the real difference except compatibility?
The reason I'm asking this question is that I am designing an upgrading
system from VB6 to .NET, it will be web-based SOA system. I used VS2003 for
developing web application and web service, when I deploy them, I deploy all
BLL assemblies at centrolized location on application server instead of
having a copy of them under web bin folder. But in VS2005, if I use creating
web site approach, all referenced dlls will be included under bin folder, and
any time if any dll has been changed, I need to deploy it both places.


Thanks.

William

 

[Scott M.]

http://msdn2.microsoft.com/en-us/library/aa730880(VS.80).aspx

 

[bruce barker]

a web application has a project file, and visual studio compiles the
codebehinds into a dll, and the asp.net (or the aspnet_compiler in
precompiled sites) compiles the aspx pages into dll's. this is more
compatible with vs2003 projects as codebehind files can refer to publics
in each other.

a web site has no project file, and asp.net (or the aspnet_compiler if
precomplied) includes the codebehind with the page dlls. this means
pages can not refer to each other, interfaces should be used (the 2003
conversion wizard would do this).

in either case you should should use a deployment project which will
maintain the the pages and binaries needed to deploy in a separate
folder system (say your application server). deployment projects can
also edit the web.config settings.

-- bruce (sqlwork.com)

 

[Mark Rae [MVP]]

As Bruce has correctly said, using a Web Deployment Project will greatly
assist you in all your deployment tasks - WDP aren't perfect, but they're a
huge improvement on the built-in functionality.

I never use anything else...

http://www.google.co.uk/search?sour...H_en-GBGB220GB220&q="Web+Deployment+Projects"

 

[Scott M.]

Can you explain what this means?

a web site has no project file, and asp.net (or the aspnet_compiler if
precomplied) includes the codebehind with the page dlls. this means pages
can not refer to each other, interfaces should be used (the 2003 conversion
wizard would do this).

I have read articles and listened to webcast from Microsoft and haven't
heard anything about pages not being able to refer to each other. Also,
what do you mean by "includes the codebehind with the page dlls"?

Thank you.

 

[bruce barker]

if vs compiles all the codebehind files into 1 assembly, all public
variables and methods can see each other without requiring a reference.

note: .net does not allow 2 assemblies to reference each other (called a
circular reference).

for example

page1.aspx's codebehind has a static method page1call() and page2.aspx's
codebehind has a static method page2call().

in vs2003 and in a web application, page1.aspx can call page2call() and
page2.aspx can call page1call() because they are in the same assembly.

in a web application page1.aspx will method not found, unless you add a
reference (page directive) to page2.aspx. if you add the refence page1
can call page2call(), but page2 cannot call page1call(), nor can you add
the reference because this would be circular.

this may seem like a limitation, but its not. good coding practice would
require the methods be extracted in a public class anyway. in a web
application, all files in the appcode folder go into one dll (assembly).

with a server transfer you often want to access properties on previous
page. in a web application you can access public properties defined in
the codebehind by casting the previous page to the right type.

in a web applicaton, you define a formal interface in the appcode
folder, then the page implements the interface. he caller then cats the
page to the inteface. this allows mulitple pages to implement the same
interface and is considered the correct approach even in a web application.


one dll per page:

in asp.net version 1 and 2, the aspx page is compiled into an assembly
(dll) and loaded at runtime. in version 1 this was at runtime in a temp
folder. in version 2 this can be done at runtime or precompiled. in a
precompiled web site/application the aspx page are empty, just place
holders for iis authentication. the compiled assemblies end up in the
bin folder.

note: you can run the merge utility to bundle all the separate dlls into
one to make deployment easier.


-- bruce (sqlwork.com)

 

[Scott M.]

Thanks Bruce. I am aware of all this, but what you've now written is
contradictory to your first statement:
"this means pages can not refer to each other", which is what I was
objecting to. The statement was just unclear. It should have said:

"Without an assembly making a reference to another that it wishes to use the
codebase from, it won't be able to. Web Application Projects don't have to
make these references when they want to refer to code from another page in
the site."

-Scott