Re: VS.NET Q: where to put common DLLs in a multi project solution, web vs. web application Q
- From: "John Saunders [MVP]" <john.saunders at trizetto.com>
- Date: Fri, 22 Jun 2007 21:45:13 -0400
<kenfine@xxxxxxxxxxxxx> wrote in message
news:eTxVDQStHHA.4972@xxxxxxxxxxxxxxxxxxxxxxx
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
"John Saunders [MVP]" <john.saunders at trizetto.com> wrote in message
news:OD$5iDQtHHA.3640@xxxxxxxxxxxxxxxxxxxxxxx
<kenfine@xxxxxxxxxxxxx> wrote in message
news:On9Yc4PtHHA.4916@xxxxxxxxxxxxxxxxxxxxxxx
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]
.
- References:
- VS.NET Q: where to put common DLLs in a multi project solution, web vs. web application Q
- From: kenfine
- Re: VS.NET Q: where to put common DLLs in a multi project solution, web vs. web application Q
- From: John Saunders [MVP]
- Re: VS.NET Q: where to put common DLLs in a multi project solution, web vs. web application Q
- From: kenfine
- VS.NET Q: where to put common DLLs in a multi project solution, web vs. web application Q
- Prev by Date: Re: VS.NET Q: where to put common DLLs in a multi project solution, web vs. web application Q
- Next by Date: RE: need a help
- Previous by thread: Re: VS.NET Q: where to put common DLLs in a multi project solution, web vs. web application Q
- Next by thread: Re: VS.NET Q: where to put common DLLs in a multi project solution, web vs. web application Q
- Index(es):
Relevant Pages
|