1.1 vs 2.0 - Multiple DLLs?

[Bob Johnson]

I'm finally getting around to migrating a "big" ASP.NET 1.1 app to 2.0. I've
been reading up on the differences and I'm NOT finding something I was lead
to believe was the case [about 2.0] a long time ago. I somehow was under the
impression that, when compiling an ASP.NET 2.0 app, that multiple dll files
were output for the project: one .dll per ASPX page/file. Gone was the day
when we could simply compile the project and get a single .dll that we could
then move to the production bin folder.

But in doing my current round of research to get up to speed on 2.0, I'm not
finding anything that supports that erstwhile understanding.

So - do we still get one big happy .dll in the bin folder for our ASP.NET
2.0 Web applications when we compile? Or do we really get multiple output
dlls (one per ASPX page/file).???

Thanks!

 

[Michael Nemtsev]

Hello Bob,

Use "web deployment project" to control the dll compiling output http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx
There you can change how your project will be build - with the single dll
or with several


---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

BJ> I'm finally getting around to migrating a "big" ASP.NET 1.1 app to
BJ> 2.0. I've been reading up on the differences and I'm NOT finding
BJ> something I was lead to believe was the case [about 2.0] a long time
BJ> ago. I somehow was under the impression that, when compiling an
BJ> ASP.NET 2.0 app, that multiple dll files were output for the
BJ> project: one .dll per ASPX page/file. Gone was the day when we could
BJ> simply compile the project and get a single .dll that we could then
BJ> move to the production bin folder.
BJ>
BJ> But in doing my current round of research to get up to speed on 2.0,
BJ> I'm not finding anything that supports that erstwhile understanding.
BJ>
BJ> So - do we still get one big happy .dll in the bin folder for our
BJ> ASP.NET 2.0 Web applications when we compile? Or do we really get
BJ> multiple output dlls (one per ASPX page/file).???
BJ>
BJ> Thanks!
BJ>

 

[Mark Fitzpatrick]

I'm assuming you're using VS to generate the project. VS 2005 SP 1
introduced the Web Application Project that works very similar to the VS
2002/3 web project and compiles everything into a single dll. The original
web project, called Web Site Project, that shipped with VS 2005 does have
this behavior. Mainly it uses a different directive to identify the code
seperated from the web page. It uses the CodeFile directive instead of the
CodeBehind. Unfortunatley, this can lead to some problems sharing code
amongst pages if they're in different directories since they don't
necessarily know about eachother. The way around this was the App_Code
directory, which gets compiled first and is available to all pages. The Web
Site Project was a nice idea, but so many people cried foul on it that MS
hurried and created the Web Application Project to give us the same
experience we were used to for 1.x development.

 

[Bob Johnson]

Thank you Mark... so, to cut to the chase on my scenario, is it true (given
what you wrote) that I will need to do the following to get my 1.1 app into
2.0 and get the single-dll-when-compiling experience I had in 1.1?

Step 1 - install SP1 for VS 2005 (I have not already done this)
Step 2 - open my 1.1 project in VS 2005 and let the conversion wizard take
over; converting everything to 2.0.
Step 3 - go on with life in the 2.0 world just like I would have in the 1.1
world (i.e, I can keep my carefully planned folder structure without having
to migrate it all to App_Code"; compile and get a single dll, etc).

Would you expect the above steps to get me where I want to go?

Separately, I do understand the option that Mr. Nemtsev presented - but I'd
prefer to avoid having to create a deployment project if I can get what I
want without creating the deployment project.

Thanks

-Bob

I'm assuming you're using VS to generate the project. VS 2005 SP 1
introduced the Web Application Project that works very similar to the VS
2002/3 web project and compiles everything into a single dll. The original
web project, called Web Site Project, that shipped with VS 2005 does have
this behavior. Mainly it uses a different directive to identify the code
seperated from the web page. It uses the CodeFile directive instead of the
CodeBehind. Unfortunatley, this can lead to some problems sharing code
amongst pages if they're in different directories since they don't
necessarily know about eachother. The way around this was the App_Code
directory, which gets compiled first and is available to all pages. The
Web Site Project was a nice idea, but so many people cried foul on it that
MS hurried and created the Web Application Project to give us the same
experience we were used to for 1.x development.


--
Hope this helps,
Mark Fitzpatrick
Microsoft FrontPage MVP 199?-2006. 2007 and beyond

I'm finally getting around to migrating a "big" ASP.NET 1.1 app to 2.0.
I've been reading up on the differences and I'm NOT finding something I
was lead to believe was the case [about 2.0] a long time ago. I somehow
was under the impression that, when compiling an ASP.NET 2.0 app, that
multiple dll files were output for the project: one .dll per ASPX
page/file. Gone was the day when we could simply compile the project and
get a single .dll that we could then move to the production bin folder.

But in doing my current round of research to get up to speed on 2.0, I'm
not finding anything that supports that erstwhile understanding.

So - do we still get one big happy .dll in the bin folder for our ASP.NET
2.0 Web applications when we compile? Or do we really get multiple output
dlls (one per ASPX page/file).???

Thanks!

 

[bruce barker]

just like 1.1, 2.0 creates a dll per page. with a deploy project you can
precompile 2.0 page dll's. with 1.1 these are created in a temp folder
at runtime (basically every recycle).

the difference between 2.0 and 1.1 (or 2.0 sp1 web applications) is the
codebehind handling. in 1.1 an extra dll is created thats the
codebehind. in 2.0 the codebehind is included in the page dll.

if you don't mind your 2.0 to having the same slow startup as 1.1, then
don't use deploy projects.

-- bruce (sqlwork.com)

Thank you Mark... so, to cut to the chase on my scenario, is it true (given
what you wrote) that I will need to do the following to get my 1.1 app into
2.0 and get the single-dll-when-compiling experience I had in 1.1?

Step 1 - install SP1 for VS 2005 (I have not already done this)
Step 2 - open my 1.1 project in VS 2005 and let the conversion wizard take
over; converting everything to 2.0.
Step 3 - go on with life in the 2.0 world just like I would have in the 1.1
world (i.e, I can keep my carefully planned folder structure without having
to migrate it all to App_Code"; compile and get a single dll, etc).

Would you expect the above steps to get me where I want to go?

Separately, I do understand the option that Mr. Nemtsev presented - but I'd
prefer to avoid having to create a deployment project if I can get what I
want without creating the deployment project.

Thanks

-Bob

I'm assuming you're using VS to generate the project. VS 2005 SP 1
introduced the Web Application Project that works very similar to the VS
2002/3 web project and compiles everything into a single dll. The original
web project, called Web Site Project, that shipped with VS 2005 does have
this behavior. Mainly it uses a different directive to identify the code
seperated from the web page. It uses the CodeFile directive instead of the
CodeBehind. Unfortunatley, this can lead to some problems sharing code
amongst pages if they're in different directories since they don't
necessarily know about eachother. The way around this was the App_Code
directory, which gets compiled first and is available to all pages. The
Web Site Project was a nice idea, but so many people cried foul on it that
MS hurried and created the Web Application Project to give us the same
experience we were used to for 1.x development.


--
Hope this helps,
Mark Fitzpatrick
Microsoft FrontPage MVP 199?-2006. 2007 and beyond

I'm finally getting around to migrating a "big" ASP.NET 1.1 app to 2.0.
I've been reading up on the differences and I'm NOT finding something I
was lead to believe was the case [about 2.0] a long time ago. I somehow
was under the impression that, when compiling an ASP.NET 2.0 app, that
multiple dll files were output for the project: one .dll per ASPX
page/file. Gone was the day when we could simply compile the project and
get a single .dll that we could then move to the production bin folder.

But in doing my current round of research to get up to speed on 2.0, I'm
not finding anything that supports that erstwhile understanding.

So - do we still get one big happy .dll in the bin folder for our ASP.NET
2.0 Web applications when we compile? Or do we really get multiple output
dlls (one per ASPX page/file).???

Thanks!

 

[Cowboy \(Gregory A. Beamer\)]

Actually, the more important one is the web application project:
http://msdn2.microsoft.com/en-us/asp.net/aa336618.aspx

 

[Bob Johnson]

Thanks Bruce, RE:
<< if you don't mind your 2.0 to having the same slow startup as 1.1, then
don't use deploy projects. >>

Okay I *do* mind that. So, given this additional consideration/benefit of
using 2.0 (precompilation) - is there any general recommendation as to which
VS 2005 project type to migrate to (from 1.1) ---> Web Site Project vs. Web
Application Project (ala 2005/SP1) --- and given my objectives as listed
below:

OBJECTIVES
1. Migrate from 1.1 to 2.0 and KEEP my existing non trivial 1.1 file/folder
structure organization.
2. Compile to one .dll (for ease of updating production -- I don't want to
have to keep track of and move [up to] dozens of .dlls to production for
maintenance releases)
3. Gain the benefits of 2.0 precompilation (for faster [than 1.1] startups).

Please comment on the following plan: Does it seem like a reasonable
strategy ? given the above objectives?

1. I will migrate the old 2003/1.1 project to the new Web Application
Project (ala 2005/SP1).

2. I will then create a deployment project (for precompilation purposes).

Thanks again for your perspectives.