G
Guest
I'm come from a self-taught ASP/Dreamweaver background and over the last
year have used VS.NET/ASP.NET/C# more and more to the point that it is my
primary development environment now. VS.NET is an amazing tool but I think
that my use of it is suboptimum.
I work on one "main" website but there are many logical divisons within that
website: one app does one thing, one thing does another. In VS.NET, Right
now I have everything lumped together in one huge project with
subdirectories as my only mechanism for dividing stuff up. Builds are very
slow, and I am less productive than I think I should be.
I was looking through Wrox's recent "MVP Hacks" book and it seemed to point
me in the way of a much smarter way to work: dividing my solution into
projects.
I want to understand whether this would work for me, what's involved in
making it happen, and whether this would speed up my builds.
Some chief concerns include:
1) I use the EntitySpaces ORM framework and a collection of classes it built
for me. I want all of my projects to use that same code.
2) I am developing a common collection of user controls and I want to be
able to use them across projects.
3) I have a bunch of nifty controls as binaries in my bin folder and I want
those shared as well.
If items 1, 2, and 3 can be managed, I am wondering how I should go about
chopping up my existing mess into something less messy. If I understand the
project metaphor correctly, it needn't move files outside of where I have
them now -- the projects just group things sensible and "point" to the
constituent files.
Thanks for any practical experience and advice you can offer. I feel like I
should really know this myself, but not having come originally from a
developer background, not everything here is intuitive. I don't want to
trash my slow-but-functional setup in the process of learning how all of
this works.
-KF
year have used VS.NET/ASP.NET/C# more and more to the point that it is my
primary development environment now. VS.NET is an amazing tool but I think
that my use of it is suboptimum.
I work on one "main" website but there are many logical divisons within that
website: one app does one thing, one thing does another. In VS.NET, Right
now I have everything lumped together in one huge project with
subdirectories as my only mechanism for dividing stuff up. Builds are very
slow, and I am less productive than I think I should be.
I was looking through Wrox's recent "MVP Hacks" book and it seemed to point
me in the way of a much smarter way to work: dividing my solution into
projects.
I want to understand whether this would work for me, what's involved in
making it happen, and whether this would speed up my builds.
Some chief concerns include:
1) I use the EntitySpaces ORM framework and a collection of classes it built
for me. I want all of my projects to use that same code.
2) I am developing a common collection of user controls and I want to be
able to use them across projects.
3) I have a bunch of nifty controls as binaries in my bin folder and I want
those shared as well.
If items 1, 2, and 3 can be managed, I am wondering how I should go about
chopping up my existing mess into something less messy. If I understand the
project metaphor correctly, it needn't move files outside of where I have
them now -- the projects just group things sensible and "point" to the
constituent files.
Thanks for any practical experience and advice you can offer. I feel like I
should really know this myself, but not having come originally from a
developer background, not everything here is intuitive. I don't want to
trash my slow-but-functional setup in the process of learning how all of
this works.
-KF