Best Practices

[BK]

We've got a fairly large scale development process under way in .NET
2003. We are about a month away from go-live for phase 1, second phase
is rather short and all work should be completed in the next 2 months.
Looking back on problems encountered, we want to learn from this
project. FWIW, we are nearly on time with the original time line (only
off by about a month), and we actually added more functionality than
the original specs called for.

In this application, we have several projects we created for simple,
reusable functionality (such as a dll that handles BLOB attachements, a
dll to handle user preferences, a dll to handle system messaging, etc.)
These projects are a mixture of VB and C#, with the output for all
being a dll that the application's exe calls. It has worked really
well for us and we expect that most of these dll's will be reused in
upcoming projects.

That being said, we did have some problems. We did this project mostly
with 2 developers. We did the project WITHOUT a source control program
(that was interesting) because management hasn't bouught in to source
control yet. (That has finally changed and we are testing SourceSafe).
The dlls were included in the main project as dll's rather than as a
project. I did this because I wanted to keep the solution pared down
but I'm not sure that was the best way to do it. Any thoughts? Any
comments on referencing a dll vs referencing a project in the solution?

Going forward we plan to use source control. We are testing Visual
SourceSafe, anyone want to add their 2 cents either for or against
this? Any suggestions on other products we may want to consider? We
will be converting to .NET 2005 soon, but the cost of Team Edition and
a dedicated Team Foundation Server is too pricey. It was suggested we
look at CVS and/or Subversion. I'm a little familiar with CVS and
wasn't that impressed with it. Anyone with experience with either of
them?

Sorry for the length of the post, but I wanted to provide as much
information as possible and I hope to start a healthy dialog with
anyone interested in sharing their experiences.

Thanks,

Will I Am

[VJ]

Reference a DLL is the best and good idea. You are ok on that...

My thoughts on VSS..

1. It is a very good tool, works well for small to medium projects I mean
with upto 10 developers
2. VSS works well with situations of Single User checking out Single file...
Multiple Users checking out Single files.. I am not really sure
I have had bad experiences... I would avoid that with VSS, or not even
consider VSS, if that happens to often in the project
3. VSS is also tricky.. sometimes I have lost data keeping in it.. So you
will have to back the directories where the VSS is having the Data files
4. If I used VSS, I would also try to keep a hard back for a couple of
versions..

The real good practice that I found useful is to use regions in code... or
..CS or .VB files.. Very helpful and good practice..

VJ

"BK" <bk******@hotmail.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

We've got a fairly large scale development process under way in .NET
2003. We are about a month away from go-live for phase 1, second phase
is rather short and all work should be completed in the next 2 months.
Looking back on problems encountered, we want to learn from this
project. FWIW, we are nearly on time with the original time line (only
off by about a month), and we actually added more functionality than
the original specs called for.

In this application, we have several projects we created for simple,
reusable functionality (such as a dll that handles BLOB attachements, a
dll to handle user preferences, a dll to handle system messaging, etc.)
These projects are a mixture of VB and C#, with the output for all
being a dll that the application's exe calls. It has worked really
well for us and we expect that most of these dll's will be reused in
upcoming projects.

That being said, we did have some problems. We did this project mostly
with 2 developers. We did the project WITHOUT a source control program
(that was interesting) because management hasn't bouught in to source
control yet. (That has finally changed and we are testing SourceSafe).
The dlls were included in the main project as dll's rather than as a
project. I did this because I wanted to keep the solution pared down
but I'm not sure that was the best way to do it. Any thoughts? Any
comments on referencing a dll vs referencing a project in the solution?

Going forward we plan to use source control. We are testing Visual
SourceSafe, anyone want to add their 2 cents either for or against
this? Any suggestions on other products we may want to consider? We
will be converting to .NET 2005 soon, but the cost of Team Edition and
a dedicated Team Foundation Server is too pricey. It was suggested we
look at CVS and/or Subversion. I'm a little familiar with CVS and
wasn't that impressed with it. Anyone with experience with either of
them?

Sorry for the length of the post, but I wanted to provide as much
information as possible and I hope to start a healthy dialog with
anyone interested in sharing their experiences.

Thanks,

Will I Am

[Brian Gideon]

BK,

For assemblies that are used by many unrelated applications I use file
references. For assemblies that are only used by one application I add
the corresponding project to the solution and use project references.

A typical folder hierarchy for an application may look like the
following.

WizbangApplication
WizbangApplication
WizbangApplication.DatabaseStuff
WizbangApplication.LoggingStuff
WizbangApplication.MathAlgorithms
WizbangApplication.Setup
Resources

In the above structure the main WizbangApplication folder will contain
the .sln file and that's about it other than the subfolders. The
WizbangApplication subfolder will contain the project that outputs the
exe. The other subfolders will contain the projects that output the
dlls or msi. The Resources subfolder contains all 3rd party dlls,
in-house dlls that aren't specific to the WizbangApplication, image
files, or other resources that may need to be compiled into the
application, but are not specific to the application.

When you check things into your source code control provider make sure
it compiles. The most annoying thing to me when I transition to a new
project that's already in the works is getting the latest version of
the source code and spending 2 hours figuring out build orders, dll
dependencies, versioning issues, syntax errors, etc. If you get things
checked in correctly it should be a piece of cake to automate nightly
builds and unit tests.

I have a deep dislike for SourceSafe despite being forced to use it for
the last 7 years. CVS or Subversion are better IMO. But, it does the
job...most of the time :)

Brian
BK wrote:

We've got a fairly large scale development process under way in .NET
2003. We are about a month away from go-live for phase 1, second phase
is rather short and all work should be completed in the next 2 months.
Looking back on problems encountered, we want to learn from this
project. FWIW, we are nearly on time with the original time line (only
off by about a month), and we actually added more functionality than
the original specs called for.

In this application, we have several projects we created for simple,
reusable functionality (such as a dll that handles BLOB attachements, a
dll to handle user preferences, a dll to handle system messaging, etc.)
These projects are a mixture of VB and C#, with the output for all
being a dll that the application's exe calls. It has worked really
well for us and we expect that most of these dll's will be reused in
upcoming projects.

That being said, we did have some problems. We did this project mostly
with 2 developers. We did the project WITHOUT a source control program
(that was interesting) because management hasn't bouught in to source
control yet. (That has finally changed and we are testing SourceSafe).
The dlls were included in the main project as dll's rather than as a
project. I did this because I wanted to keep the solution pared down
but I'm not sure that was the best way to do it. Any thoughts? Any
comments on referencing a dll vs referencing a project in the solution?

Going forward we plan to use source control. We are testing Visual
SourceSafe, anyone want to add their 2 cents either for or against
this? Any suggestions on other products we may want to consider? We
will be converting to .NET 2005 soon, but the cost of Team Edition and
a dedicated Team Foundation Server is too pricey. It was suggested we
look at CVS and/or Subversion. I'm a little familiar with CVS and
wasn't that impressed with it. Anyone with experience with either of
them?

Sorry for the length of the post, but I wanted to provide as much
information as possible and I hope to start a healthy dialog with
anyone interested in sharing their experiences.

Thanks,

Will I Am

[Carlos J. Quintero [VB MVP]]

Hi,

About VS.NET and Source Code Control (SCC) integration, best practices and
so on, see this section of my web site:

http://www.mztools.com/resources_net_developers.htm#SCC
Resources about Visual Studio .NET and Source Code Control (SCC) integration

I wouldn´t recommend SourceSafe 6.0, it can cause corruption problems. Maybe
SourceSafe 2005 fixes that. TFS may be overkill for only two persons, so you
may also take a look at (I haven´t use them but they have good reputation):

- SourceVault (http://www.sourcegear.com/vault/index.html). It's free for 1
developer.
- Perforce (http://www.perforce.com/). It's free for up to 2 developers.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com
"BK" <bk******@hotmail.com> escribió en el mensaje
news:11**********************@i39g2000cwa.googlegr oups.com...

We've got a fairly large scale development process under way in .NET
2003. We are about a month away from go-live for phase 1, second phase
is rather short and all work should be completed in the next 2 months.
Looking back on problems encountered, we want to learn from this
project. FWIW, we are nearly on time with the original time line (only
off by about a month), and we actually added more functionality than
the original specs called for.

In this application, we have several projects we created for simple,
reusable functionality (such as a dll that handles BLOB attachements, a
dll to handle user preferences, a dll to handle system messaging, etc.)
These projects are a mixture of VB and C#, with the output for all
being a dll that the application's exe calls. It has worked really
well for us and we expect that most of these dll's will be reused in
upcoming projects.

That being said, we did have some problems. We did this project mostly
with 2 developers. We did the project WITHOUT a source control program
(that was interesting) because management hasn't bouught in to source
control yet. (That has finally changed and we are testing SourceSafe).
The dlls were included in the main project as dll's rather than as a
project. I did this because I wanted to keep the solution pared down
but I'm not sure that was the best way to do it. Any thoughts? Any
comments on referencing a dll vs referencing a project in the solution?

Going forward we plan to use source control. We are testing Visual
SourceSafe, anyone want to add their 2 cents either for or against
this? Any suggestions on other products we may want to consider? We
will be converting to .NET 2005 soon, but the cost of Team Edition and
a dedicated Team Foundation Server is too pricey. It was suggested we
look at CVS and/or Subversion. I'm a little familiar with CVS and
wasn't that impressed with it. Anyone with experience with either of
them?

Sorry for the length of the post, but I wanted to provide as much
information as possible and I hope to start a healthy dialog with
anyone interested in sharing their experiences.

Thanks,

Will I Am

[BK]

Thanks for your input.

Your directory structure is basically the same as what we use, but we
don't have a resource folder. I think that would resolve one of our
problems we have with keeping a uniform place for additional dll's we
use in a solution where we don't have the source code or don't need to
maintain the source code as part of the solution.

As for SourceSafe, more and more people are recommending we stay away
from it. I'm leaning toward SourceGear now. Does CVS have a GUI
interface into the administration side of it? I don't really care if
our SCC is integrated, it's not a big deal to check in and check out
code from a seperate window before/after working on the code. Is this
attitude going to get me in trouble down the road?

Bill

[BK]

Thanks for the input. We actually have more than 2 developers, there
are 20+ in the department, but about 8 of us work in .NET. I am
leaning toward SourceGear and plan to put a test in place soon for it.
Thanks for the links.

Bill