468,103 Members | 1,172 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,103 developers. It's quick & easy.

what's different between asp application and web site

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

Nov 7 '07 #1
6 2267
http://msdn2.microsoft.com/en-us/lib...80(VS.80).aspx


"william" <wi*****@discussions.microsoft.comwrote in message
news:DC**********************************@microsof t.com...
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

Nov 7 '07 #2
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)

william wrote:
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
Nov 7 '07 #3
"william" <wi*****@discussions.microsoft.comwrote in message
news:DC**********************************@microsof t.com...

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?sourc...nt+Projects%22
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

Nov 7 '07 #4
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.
Nov 7 '07 #5
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. wrote:
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.

Nov 8 '07 #6
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

"bruce barker" <no****@nospam.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
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. wrote:
>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.
Nov 8 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by SatishPasala | last post: by
11 posts views Thread by =?Utf-8?B?UGF0Qg==?= | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.