VS.NET Q: where to put common DLLs in a multi project solution, web vs. web application Q

[Guest]

I have learned about compartmentalizing my code base using Class Libraries.
I have my common code such as my ORM framework broken out into their own
Class Libraries, which are referenced as projects from my Website.

I also have a common set of DLLs I use across all of my applications. It
would be great if I could put all of those DLLs into their own projects, and
to reference that project from various solutions.

The way my solution is currently structured, I have a Website wtith several
other projects -- Class Library projects -- that are referenced from that
Website. I am wondering if this is the wrong arrangement for what I describe
in the previous paragraph. I know there is a "website" model, and a "web
application model" in VS.NET 2005.

What I need to know is:
1) What project type I should use to encapsulate my collection of common
DLLs. Should they be contained in their own class library with references to
the required DLLs (versus the Website's "bin" folder?)

2) Do I want to convert to the "Web application model" based on my described
needs.

Thanks. I'll understand this completely soon.

-KF

 

[John Saunders [MVP]]

I have learned about compartmentalizing my code base using Class Libraries.
I have my common code such as my ORM framework broken out into their own
Class Libraries, which are referenced as projects from my Website.

I also have a common set of DLLs I use across all of my applications. It
would be great if I could put all of those DLLs into their own projects,
and to reference that project from various solutions.

The way my solution is currently structured, I have a Website wtith
several other projects -- Class Library projects -- that are referenced
from that Website. I am wondering if this is the wrong arrangement for
what I describe in the previous paragraph. I know there is a "website"
model, and a "web application model" in VS.NET 2005.

What I need to know is:
1) What project type I should use to encapsulate my collection of common
DLLs. Should they be contained in their own class library with references
to the required DLLs (versus the Website's "bin" folder?)

2) Do I want to convert to the "Web application model" based on my
described needs.

My personal feeling is that the Web Site model was a mistake on the part of
Microsoft. I would recommend it as a second line of defense for anyone who
feels that the Web Application model is too complex. I think that it's a
mistake to get people starting with the Web Site model and then to try to
get them to convert to the Web Application model only when the Web Site
model isn't enough.

That's the situation you're in right now. As soon as you start talking about
class libraries as opposed to code files in App_Code, you need the Web
Application model.

Regardless of which Web model you use, I would create a single solution to
contain all of your projects. Place each class library into a single
project, based on how they reference each other. In particular, a set of
classes which reference each other frequently should be in the same project
so they'll be in the same assembly, so they can use the "internal" and
"protected internal" access levels to reference each other's members.

Projects that reference each other can have project references to each
other. That will cause the projects to rebuild as necessary.

Finally, if you go with the Web Application model, the Web Application will
have project references to the projects it needs. When it builds, those
assemblies will be copied into the bin directory of the Web Application.

Things get a little more complicated with multiple solutions, but not much
more. I'd suggest starting with this and changing to multiple solutions when
the single solution becomes a problem.

 

[Guest]

Wow, this is the information and synthesis I've been seeking for a long
time, I really appreciate it, John.

I agree with you regarding the problems with the Web Site model. More
generally, I think Microsoft needed/needs to do a much better job explaining
to newbies how professional developers structure a set of projects,
reference class libraries, deploy to virtual directories, and so forth.

The problem now is that a lot of people have walked into VS.NET from a
Dreamweaver/ASP background, rather than a "real developer" background, and
the organizational idiom there is completely different. Some of us from
non-dev backgrounds start out the process of making compiled apps having no
clue of what's being made or how to organize the pieces. With Dreamweaver
et. al, file/project organization tends to be much more literal: on my dev
machine was an archive of a bazillion files that exactly mirrored the
production server. My ASP-based web applications churned out thousands of
files (rendered PDFs and images), and naturally my dev machine served a
backup of what was on production. Simple. This arrangement is easy and works
great for Dreamweaver-ish sites. But it was a disaster when I started
dealing with compiled projects, and cluelessly created one mega solution
based off it. I found it frustrating that my simple projects took minutes to
compile, and that I did not have the seem to have the agility I had when I
wrote Classic ASP apps. I didn't understand why such a great tool with a
great debugger and great Intellisense was so terribly sluggish.

Fortunately for me, .NET-specific tools like EntitySpaces' ORM and Telerik's
components were compelling enough that I stuck with it long enough to figure
out some of how things should be done and to ask the right questions of
helpful people like yourself. I think Microsoft needs to think about the
bazillions of newly minted coders who are going to be coming into VS.NET,
attracted by its amazing IDE, Silverlight Apha's clean programming model
(compared to AS2...), and the ever-increasing capability of the ASP.NET
plafrom. If newbies do not understand the basics of how to structure their
projects and solutions, and they do not have peers to teach them the right
way to do things, many people will not figure out how to make the tool
acceptably performant, or how referenced class libaries as projects can
centralize code smartly, or many other basic, critical things.

One person's $0.02. Stepping off the lonely soapbox, let me thank you again
for your generous help.

-KF

 

[bruce barker]

your arrangement is correct.

i would not convert to web application mode (its just a hack), nor does
it improve your problem. all it does is make an additional project file
for the code behind files (which are built into a dll, the ide then has
hide the source files from the aspnet compiler). a separate dll is still
built for each page and the aspnet compiler still builds the site code.

asp.net notion of dll library is the bin folder. all dlls not in the gac
or the framework folder must be copied to the bin folder. vs will this
copy for you if the web site or web application project has a reference
to the dll or class project.

so you will need to add a reference to each dll to the website or web
application in either case.

msbuild supports website solutions, and deployment projects, so you can
do commandline builds of the site and have a deployment folder built. if
you are not using deployment projects, you should.

-- bruce (sqlwork.com)

 

[John Saunders [MVP]]

Wow, this is the information and synthesis I've been seeking for a long
time, I really appreciate it, John.

I agree with you regarding the problems with the Web Site model. More
generally, I think Microsoft needed/needs to do a much better job
explaining to newbies how professional developers structure a set of
projects, reference class libraries, deploy to virtual directories, and so
forth.

The problem now is that a lot of people have walked into VS.NET from a
Dreamweaver/ASP background, rather than a "real developer" background, and
the organizational idiom there is completely different. Some of us from
non-dev backgrounds start out the process of making compiled apps having
no clue of what's being made or how to organize the pieces. With
Dreamweaver et. al, file/project organization tends to be much more
literal: on my dev machine was an archive of a bazillion files that
exactly mirrored the production server. My ASP-based web applications
churned out thousands of files (rendered PDFs and images), and naturally
my dev machine served a backup of what was on production. Simple. This
arrangement is easy and works great for Dreamweaver-ish sites. But it was
a disaster when I started dealing with compiled projects, and cluelessly
created one mega solution based off it. I found it frustrating that my
simple projects took minutes to compile, and that I did not have the seem
to have the agility I had when I wrote Classic ASP apps. I didn't
understand why such a great tool with a great debugger and great
Intellisense was so terribly sluggish.

Fortunately for me, .NET-specific tools like EntitySpaces' ORM and
Telerik's components were compelling enough that I stuck with it long
enough to figure out some of how things should be done and to ask the
right questions of helpful people like yourself. I think Microsoft needs
to think about the bazillions of newly minted coders who are going to be
coming into VS.NET, attracted by its amazing IDE, Silverlight Apha's clean
programming model (compared to AS2...), and the ever-increasing capability
of the ASP.NET plafrom. If newbies do not understand the basics of how to
structure their projects and solutions, and they do not have peers to
teach them the right way to do things, many people will not figure out how
to make the tool acceptably performant, or how referenced class libaries
as projects can centralize code smartly, or many other basic, critical
things.

One person's $0.02. Stepping off the lonely soapbox, let me thank you
again for your generous help.

-KF

KF, it's good to hear from someone who got here from the other direction.

It seems to me that,with discipline, it should be possible to use the Web
Site model for pure "web site" stuff, and use a "real" development model for
producing the class libraries used by the web site to deal with the
"application" part of what it does. That would allow people used to web site
developemt to continue using their familiar tools and techniques.

The problem comes when trying to wedge non-UI code into the web site model.
It just doesn't work well.

John