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
"John Saunders [MVP]" <john.saunders at trizetto.comwrote in message
news:OD**************@TK2MSFTNGP05.phx.gbl...
<ke*****@nospam.nospamwrote in message
news:On**************@TK2MSFTNGP05.phx.gbl...
>>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.
--
John Saunders [MVP]
