Source Control - what files should/shouldn't be stored in source control

[MarkusR]

I am currently using StarTeam for my source control. (Will eventual
switch to whatever the latest Visual Source Safe is going to be
called).

With debug, installers, deploy and everything the project directory
structure is a mess of files and directories

What files should be in source control (All final builds willbe done on
anothe machine)?

I read that PDB and SUO files should not be checked it.

My typical structure is:

Main project dir -
common
data (test data not to be source controlled)
project
Setup
Debug
Release
Frm (GUI)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties
Svc (Service)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties

What directories/file extensions should be in source control and which
ones will be rebuilt? My build machine probably will not have the exact
some file paths.

-Markus_R

[Bruce Wood]

MarkusR wrote:

I am currently using StarTeam for my source control. (Will eventual
switch to whatever the latest Visual Source Safe is going to be
called).

With debug, installers, deploy and everything the project directory
structure is a mess of files and directories

What files should be in source control (All final builds willbe done on
anothe machine)?

I read that PDB and SUO files should not be checked it.

My typical structure is:

Main project dir -
common
data (test data not to be source controlled)
project
Setup
Debug
Release
Frm (GUI)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties
Svc (Service)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties

What directories/file extensions should be in source control and which
ones will be rebuilt? My build machine probably will not have the exact
some file paths.

-Markus_R

I do not check in .suo, .csproj.user, or any generated files (.exe,
..dll, .pdb, etc)

Also I usually don't check in .sln.

Unfortunately (in .NET 1.1), some wiseacre at Microsoft decided to
store "critical source control information" in the .suo file, or so the
error message says. Equally unfortunately, the .suo file apparently
contains hard-coded directory paths, so checking out code into a
different workspace doesn't play nice with Visual Studio.

I hope that this area improves with .NET 2.0. :-)

[Robbe Morris [C# MVP]]

Those and anything under the /bin/debug and /bin/release folders
--
Robbe Morris - 2004-2006 Microsoft MVP C#
I've mapped the database to .NET class properties and methods to
implement an multi-layered object oriented environment for your
data access layer. Thus, you should rarely ever have to type the words
SqlCommand, SqlDataAdapter, or SqlConnection again.
http://www.eggheadcafe.com/articles/..._generator.asp

"MarkusR" <ma*******@gmail.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...

>I am currently using StarTeam for my source control. (Will eventual
switch to whatever the latest Visual Source Safe is going to be
called).

With debug, installers, deploy and everything the project directory
structure is a mess of files and directories

What files should be in source control (All final builds willbe done on
anothe machine)?

I read that PDB and SUO files should not be checked it.

My typical structure is:

Main project dir -
common
data (test data not to be source controlled)
project
Setup
Debug
Release
Frm (GUI)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties
Svc (Service)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties

What directories/file extensions should be in source control and which
ones will be rebuilt? My build machine probably will not have the exact
some file paths.

-Markus_R

[Yury]

ignore all *.suo, *.user files
and \bin directories.

Also prepare you repository for branching (create folder for them).
http://svnbook.red-bean.com/nightly/...e.maint.layout

\trunk
\branches
'v3.5.x
\v3.6.x

And take a look at svn+tsvn.

http://tortoisesvn.net/about
http://tortoisesvn.net/big_picture

PS: "whatever the latest Visual Source Safe" is really sucks.

MarkusR wrote:

I am currently using StarTeam for my source control. (Will eventual
switch to whatever the latest Visual Source Safe is going to be
called).

With debug, installers, deploy and everything the project directory
structure is a mess of files and directories

What files should be in source control (All final builds willbe done on
anothe machine)?

I read that PDB and SUO files should not be checked it.

My typical structure is:

Main project dir -
common
data (test data not to be source controlled)
project
Setup
Debug
Release
Frm (GUI)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties
Svc (Service)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties

What directories/file extensions should be in source control and which
ones will be rebuilt? My build machine probably will not have the exact
some file paths.

-Markus_R

[Robbe Morris [C# MVP]]

Team Foundation Server is actually pretty nice. Pain
in the neck to install though.

http://www.eggheadcafe.com/articles/...ion_server.asp

I am forced to use Subversion at work. There is not
a day that goes by that I don't curse our former
CIO for forcing us to switch to Subversion.

That worthless Ankh for visual studio blows even worse.

God, I hate Subversion...

--
Robbe Morris - 2004-2006 Microsoft MVP C#
I've mapped the database to .NET class properties and methods to
implement an multi-layered object oriented environment for your
data access layer. Thus, you should rarely ever have to type the words
SqlCommand, SqlDataAdapter, or SqlConnection again.
http://www.eggheadcafe.com/articles/..._generator.asp

"Yury" <Yu**********@gmail.comwrote in message
news:11**********************@e3g2000cwe.googlegro ups.com...

ignore all *.suo, *.user files
and \bin directories.

Also prepare you repository for branching (create folder for them).
http://svnbook.red-bean.com/nightly/...e.maint.layout

\trunk
\branches
'v3.5.x
\v3.6.x

And take a look at svn+tsvn.

http://tortoisesvn.net/about
http://tortoisesvn.net/big_picture

PS: "whatever the latest Visual Source Safe" is really sucks.

MarkusR wrote:

>I am currently using StarTeam for my source control. (Will eventual
switch to whatever the latest Visual Source Safe is going to be
called).

With debug, installers, deploy and everything the project directory
structure is a mess of files and directories

What files should be in source control (All final builds willbe done on
anothe machine)?

I read that PDB and SUO files should not be checked it.

My typical structure is:

Main project dir -
common
data (test data not to be source controlled)
project
Setup
Debug
Release
Frm (GUI)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties
Svc (Service)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties

What directories/file extensions should be in source control and which
ones will be rebuilt? My build machine probably will not have the exact
some file paths.

-Markus_R

[Yury]

We have started to use TFS since second beta. We were waiting
release... we hoped that it would be better. We were using TFS release
for 1 month.
It's big pain.
* Stupid concept of workspaces.
* Stupid merging/branching (noticed a lot of unnecessary
changes/conflicts).
* Not working off-line without stupid hacks.
* Really slow (studio hangs for a while before I can edit a file.)
* Can't do anything without studio...
* Stupid Shelving (it doesn't support merge back. Why we need it
without merge?)
* And can't rollback commit/changeset!!!! What they were thinking
about??? And after release they create "admin tool" for that....
Blah...

So we leave TFS as our bug tracking system and migrate our code back to
svn.

And don't use Ankh. Use TortoiseSVN.
Robbe Morris [C# MVP] wrote:

Team Foundation Server is actually pretty nice. Pain
in the neck to install though.

http://www.eggheadcafe.com/articles/...ion_server.asp

I am forced to use Subversion at work. There is not
a day that goes by that I don't curse our former
CIO for forcing us to switch to Subversion.

That worthless Ankh for visual studio blows even worse.

God, I hate Subversion...

--
Robbe Morris - 2004-2006 Microsoft MVP C#
I've mapped the database to .NET class properties and methods to
implement an multi-layered object oriented environment for your
data access layer. Thus, you should rarely ever have to type the words
SqlCommand, SqlDataAdapter, or SqlConnection again.
http://www.eggheadcafe.com/articles/..._generator.asp

"Yury" <Yu**********@gmail.comwrote in message
news:11**********************@e3g2000cwe.googlegro ups.com...

ignore all *.suo, *.user files
and \bin directories.

Also prepare you repository for branching (create folder for them).
http://svnbook.red-bean.com/nightly/...e.maint.layout

\trunk
\branches
'v3.5.x
\v3.6.x

And take a look at svn+tsvn.

http://tortoisesvn.net/about
http://tortoisesvn.net/big_picture

PS: "whatever the latest Visual Source Safe" is really sucks.

MarkusR wrote:

I am currently using StarTeam for my source control. (Will eventual
switch to whatever the latest Visual Source Safe is going to be
called).

With debug, installers, deploy and everything the project directory
structure is a mess of files and directories

What files should be in source control (All final builds willbe done on
anothe machine)?

I read that PDB and SUO files should not be checked it.

My typical structure is:

Main project dir -
common
data (test data not to be source controlled)
project
Setup
Debug
Release
Frm (GUI)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties
Svc (Service)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties

What directories/file extensions should be in source control and which
ones will be rebuilt? My build machine probably will not have the exact
some file paths.

-Markus_R

[Brian Gideon]

I'll second Subversion. I just started playing around with it this
week. It's *way* better than VSS. And for those who thinks it's
difficult to use...I setup a Subversion server, repository, and the
TortoiseSVN client in about 15 minutes with zero prior knowledge of how
to use it.

Is there an explorer-like client for SVN?

Is there a web interface for SVN?

Brian

Yury wrote:

ignore all *.suo, *.user files
and \bin directories.

Also prepare you repository for branching (create folder for them).
http://svnbook.red-bean.com/nightly/...e.maint.layout

\trunk
\branches
'v3.5.x
\v3.6.x

And take a look at svn+tsvn.

http://tortoisesvn.net/about
http://tortoisesvn.net/big_picture

PS: "whatever the latest Visual Source Safe" is really sucks.

MarkusR wrote:

I am currently using StarTeam for my source control. (Will eventual
switch to whatever the latest Visual Source Safe is going to be
called).

With debug, installers, deploy and everything the project directory
structure is a mess of files and directories

What files should be in source control (All final builds willbe done on
anothe machine)?

I read that PDB and SUO files should not be checked it.

My typical structure is:

Main project dir -
common
data (test data not to be source controlled)
project
Setup
Debug
Release
Frm (GUI)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties
Svc (Service)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties

What directories/file extensions should be in source control and which
ones will be rebuilt? My build machine probably will not have the exact
some file paths.

-Markus_R

[Mark Jerde]

Is there an explorer-like client for SVN?

TortoiseSVN integrates into Windows Explorer.

http://tortoisesvn.tigris.org/

-- Mark

[Matt]

Mark Jerde wrote:

Is there an explorer-like client for SVN?

TortoiseSVN integrates into Windows Explorer.

http://tortoisesvn.tigris.org/

I'll second Tortoise, but stress that you should get the latest
version.
It has a LOT of bug fixes for things that were not really that big of a

deal but were VERY annoying.

Matt

[Jon Skeet [C# MVP]]

Robbe Morris [C# MVP] <jo*****@joe.comwrote:

Team Foundation Server is actually pretty nice. Pain
in the neck to install though.

http://www.eggheadcafe.com/articles/...ion_server.asp

Yes - but that's not the latest version of VSS. VSS still lives as a
product, unfortunately.

I am forced to use Subversion at work. There is not
a day that goes by that I don't curse our former
CIO for forcing us to switch to Subversion.

Interesting. We moved from VSS to SVN a while ago, and I absolutely
love it. There are some problems merging when someone has either
branched incorrectly or deleted then recreated files, but those issues
can always be worked around in my experience. The rest of the time SVN
works extremely well. What do you have against it?

That worthless Ankh for visual studio blows even worse.

Ah, now that I could understand. I haven't used Ankh myself - I use the
command line and TortoiseSVN when I'm on a Windows box, and Eclipse and
the command line on Linux.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Yury]

Jon wrote:

Interesting. We moved from VSS to SVN a while ago, and I absolutely
love it. There are some problems merging when someone has either
branched incorrectly or deleted then recreated files, but those issues
can always be worked around in my experience. The rest of the time SVN
works extremely well. What do you have against it?

didn't noticed any bugs with merging/branching

Ah, now that I could understand. I haven't used Ankh myself - I use the
command line and TortoiseSVN when I'm on a Windows box, and Eclipse and
the command line on Linux.

Jon, take a look at subclipse http://subclipse.tigris.org/
I know people who use it and like it a lot.

[Brian Gideon]

Mark,

Yeah, that's what I've been using. I was wondering if there were any
clients that didn't use explorer shell extensions. I didn't articulate
my question very well.

Brian

Mark Jerde wrote:

Is there an explorer-like client for SVN?

TortoiseSVN integrates into Windows Explorer.

http://tortoisesvn.tigris.org/

-- Mark

[Yury]

Brian Gideon wrote:

Mark,

Yeah, that's what I've been using. I was wondering if there were any
clients that didn't use explorer shell extensions. I didn't articulate
my question very well.

http://rapidsvn.tigris.org/

[Brian Gideon]

Excellent. Thanks.

Yury wrote:

Brian Gideon wrote:

Mark,

Yeah, that's what I've been using. I was wondering if there were any
clients that didn't use explorer shell extensions. I didn't articulate
my question very well.

http://rapidsvn.tigris.org/

[Jon Skeet [C# MVP]]

Yury <Yu**********@gmail.comwrote:

Jon wrote:

Interesting. We moved from VSS to SVN a while ago, and I absolutely
love it. There are some problems merging when someone has either
branched incorrectly or deleted then recreated files, but those issues
can always be worked around in my experience. The rest of the time SVN
works extremely well. What do you have against it?

didn't noticed any bugs with merging/branching

There are a couple of bugs which have been fixed by 1.4 (which we're
not using yet) but it's more that you can get yourself into awkward
situations if you're not careful. They're not bugs, just gotchas.

Ah, now that I could understand. I haven't used Ankh myself - I use the
command line and TortoiseSVN when I'm on a Windows box, and Eclipse and
the command line on Linux.

Jon, take a look at subclipse http://subclipse.tigris.org/
I know people who use it and like it a lot.

Oh absolutely. My point was that I don't need to use Ankh - sorry that
I wasn't clear on that front. (There's also Subversive, which I haven't
used, but which is providing good competition for Subclipse.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[MarkusR]

So then I would check in the following(?):

proj\FormMain.Designer.cs
proj\FormMain.resx
proj\Program.cs
proj\FormMain.cs
proj\ProjectInstaller.cs
proj\ProjectInstaller.Designer.cs
proj\ProjectInstaller.resx

proj\obj\ <nothing>

proj\properties\AssemblyInfo.cs
proj\properties\licenses.licx
proj\properties\Resources.Designer.cs
proj\properties\Resources.resx
proj\properties\Settings.Designer.cs
proj\properties\Settings.settings

setup\ProjSetup.vdproj

-Markus

Bruce Wood wrote:

I do not check in .suo, .csproj.user, or any generated files (.exe,
.dll, .pdb, etc)

Also I usually don't check in .sln.

Unfortunately (in .NET 1.1), some wiseacre at Microsoft decided to
store "critical source control information" in the .suo file, or so the
error message says. Equally unfortunately, the .suo file apparently
contains hard-coded directory paths, so checking out code into a
different workspace doesn't play nice with Visual Studio.

I hope that this area improves with .NET 2.0. :-)

[MarkusR]

If I do not check in the .sln or .csproj how would I open the project
in VS2005?

MarkusR wrote:

So then I would check in the following(?):

proj\FormMain.Designer.cs
proj\FormMain.resx
proj\Program.cs
proj\FormMain.cs
proj\ProjectInstaller.cs
proj\ProjectInstaller.Designer.cs
proj\ProjectInstaller.resx

proj\obj\ <nothing>

proj\properties\AssemblyInfo.cs
proj\properties\licenses.licx
proj\properties\Resources.Designer.cs
proj\properties\Resources.resx
proj\properties\Settings.Designer.cs
proj\properties\Settings.settings

setup\ProjSetup.vdproj

-Markus

Bruce Wood wrote:

I do not check in .suo, .csproj.user, or any generated files (.exe,
.dll, .pdb, etc)

Also I usually don't check in .sln.

Unfortunately (in .NET 1.1), some wiseacre at Microsoft decided to
store "critical source control information" in the .suo file, or so the
error message says. Equally unfortunately, the .suo file apparently
contains hard-coded directory paths, so checking out code into a
different workspace doesn't play nice with Visual Studio.

I hope that this area improves with .NET 2.0. :-)

[Brian Gideon]

Markus,

I usually set it up like the following.

MyProduct\MyProduct.sln

MyProduct\Project1\Project1.csproj
MyProduct\Project1\File1.cs
MyProduct\Project1\File2.cs
MyProduct\Project1\FileN.cs

MyProduct\Project2\Project1.csproj
MyProduct\Project2\File1.cs
MyProduct\Project2\File2.cs
MyProduct\Project2\FileN.cs

MyProduct\ProjectN\ProjectN.csproj
MyProduct\ProjectN\File1.cs
MyProduct\ProjectN\File2.cs
MyProduct\ProjectN\FileN.cs

MyProduct\References\ThirdPartyAssembly1.dll
MyProduct\References\ThirdPartyAssembly2.dll
MyProduct\References\ThirdPartyAssemblyN.dll
MyProduct\References\SeperatelyVersionedAssembly1. dll
MyProduct\References\SeperatelyVersionedAssembly2. dll
MyProduct\References\SeperatelyVersionedAssemblyN. dll

Your product, whether shrink wrapped or in-house, should be completely
self-contained underneath one folder. There is a References folder
which contains all dependent third party assemblies and separately
versioned in-house assemblies. Projects that depend on each other use
a project reference while projects that depend on assemblies in the
References folder use relative binary references.

This offers several advantages. First, all a developer needs to do to
compile the product is get the lastest version of the MyProduct folder,
double-click the sln to open VS, and then build. If setup correctly it
should build everytime without having to track down missing
dependecies, syntax errors, etc. Second, versioning is very simple.
Since the product is completely self-contained you can label, branch,
tag, or merge at anytime. Each branch can use different versions of
the assemblies in the References folder. That's useful when you
receive a new version of a third party assembly and want to test its
compatibility with your product. If it's incompatible then you can
modify code accordingly in that branch.

Brian

MarkusR wrote:

If I do not check in the .sln or .csproj how would I open the project
in VS2005?

MarkusR wrote:

So then I would check in the following(?):

proj\FormMain.Designer.cs
proj\FormMain.resx
proj\Program.cs
proj\FormMain.cs
proj\ProjectInstaller.cs
proj\ProjectInstaller.Designer.cs
proj\ProjectInstaller.resx

proj\obj\ <nothing>

proj\properties\AssemblyInfo.cs
proj\properties\licenses.licx
proj\properties\Resources.Designer.cs
proj\properties\Resources.resx
proj\properties\Settings.Designer.cs
proj\properties\Settings.settings

setup\ProjSetup.vdproj

-Markus

Bruce Wood wrote:

I do not check in .suo, .csproj.user, or any generated files (.exe,
.dll, .pdb, etc)
>
Also I usually don't check in .sln.
>
Unfortunately (in .NET 1.1), some wiseacre at Microsoft decided to
store "critical source control information" in the .suo file, or so the
error message says. Equally unfortunately, the .suo file apparently
contains hard-coded directory paths, so checking out code into a
different workspace doesn't play nice with Visual Studio.
>
I hope that this area improves with .NET 2.0. :-)

[MarkusR]

Thanks Brian.

Brian Gideon wrote:

Markus,

I usually set it up like the following.

MyProduct\MyProduct.sln

MyProduct\Project1\Project1.csproj
MyProduct\Project1\File1.cs
MyProduct\Project1\File2.cs
MyProduct\Project1\FileN.cs

MyProduct\Project2\Project1.csproj
MyProduct\Project2\File1.cs
MyProduct\Project2\File2.cs
MyProduct\Project2\FileN.cs

MyProduct\ProjectN\ProjectN.csproj
MyProduct\ProjectN\File1.cs
MyProduct\ProjectN\File2.cs
MyProduct\ProjectN\FileN.cs

MyProduct\References\ThirdPartyAssembly1.dll
MyProduct\References\ThirdPartyAssembly2.dll
MyProduct\References\ThirdPartyAssemblyN.dll
MyProduct\References\SeperatelyVersionedAssembly1. dll
MyProduct\References\SeperatelyVersionedAssembly2. dll
MyProduct\References\SeperatelyVersionedAssemblyN. dll

Your product, whether shrink wrapped or in-house, should be completely
self-contained underneath one folder. There is a References folder
which contains all dependent third party assemblies and separately
versioned in-house assemblies. Projects that depend on each other use
a project reference while projects that depend on assemblies in the
References folder use relative binary references.

This offers several advantages. First, all a developer needs to do to
compile the product is get the lastest version of the MyProduct folder,
double-click the sln to open VS, and then build. If setup correctly it
should build everytime without having to track down missing
dependecies, syntax errors, etc. Second, versioning is very simple.
Since the product is completely self-contained you can label, branch,
tag, or merge at anytime. Each branch can use different versions of
the assemblies in the References folder. That's useful when you
receive a new version of a third party assembly and want to test its
compatibility with your product. If it's incompatible then you can
modify code accordingly in that branch.

Brian

MarkusR wrote:

If I do not check in the .sln or .csproj how would I open the project
in VS2005?

MarkusR wrote:

So then I would check in the following(?):
>
proj\FormMain.Designer.cs
proj\FormMain.resx
proj\Program.cs
proj\FormMain.cs
proj\ProjectInstaller.cs
proj\ProjectInstaller.Designer.cs
proj\ProjectInstaller.resx
>
proj\obj\ <nothing>
>
proj\properties\AssemblyInfo.cs
proj\properties\licenses.licx
proj\properties\Resources.Designer.cs
proj\properties\Resources.resx
proj\properties\Settings.Designer.cs
proj\properties\Settings.settings
>
setup\ProjSetup.vdproj
>
-Markus
>
Bruce Wood wrote:
I do not check in .suo, .csproj.user, or any generated files (.exe,
.dll, .pdb, etc)

Also I usually don't check in .sln.

Unfortunately (in .NET 1.1), some wiseacre at Microsoft decided to
store "critical source control information" in the .suo file, or so the
error message says. Equally unfortunately, the .suo file apparently
contains hard-coded directory paths, so checking out code into a
different workspace doesn't play nice with Visual Studio.

I hope that this area improves with .NET 2.0. :-)

[Joerg Jooss]

Thus wrote Robbe Morris [C# MVP],

Team Foundation Server is actually pretty nice. Pain in the neck to
install though.

http://www.eggheadcafe.com/articles/...ion_server.asp

I am forced to use Subversion at work. There is not
a day that goes by that I don't curse our former
CIO for forcing us to switch to Subversion.
That worthless Ankh for visual studio blows even worse.

God, I hate Subversion...

Praising TFS and cursing Subversion seems nonsensical to me, as both are
conceptually quite similar.

Cheers,
--
Joerg Jooss
ne********@joergjooss.de

[MarkusR]

Hey Guys,

It looks like I started a Version Control war here. Peace everyone
peace. :)

I couldn't care less about which Version Control system one uses. I
don't have a choice. Currently it is Star Team and next it will be MS
new VSS. Not my say.

The point of my question was what file extentions need to be checked
into source control so I can check them out on the build machine and
build.

One poster mentioned not checking in the .sln files (which I don't
quite understand since that is the project file isn't it and how would
one open and compile the project then? Rebuild the project from
scratch?

I think he also mentioned not checking in the .csproj. Aren't these
intragral parts of the project. Note. My typical project usually
contain a windows application program, a windows service and a setup
program. (GUI for testing, service for running on the server, and the
installation program). My common code for the GUI and service are in
one unit in a project common directory.

Markus_R2
(since there appears to be another Markus_R out there posting :) )

[Jon Skeet [C# MVP]]

MarkusR <ma*******@gmail.comwrote:

It looks like I started a Version Control war here. Peace everyone
peace. :)

I couldn't care less about which Version Control system one uses. I
don't have a choice. Currently it is Star Team and next it will be MS
new VSS. Not my say.

The point of my question was what file extentions need to be checked
into source control so I can check them out on the build machine and
build.

One poster mentioned not checking in the .sln files (which I don't
quite understand since that is the project file isn't it and how would
one open and compile the project then? Rebuild the project from
scratch?

Well, without the .sln file I suspect you're okay *if* your projects
don't refer to each other. I'd suggest checking in the .sln files as
well though.

I think he also mentioned not checking in the .csproj. Aren't these
intragral parts of the project. Note. My typical project usually
contain a windows application program, a windows service and a setup
program. (GUI for testing, service for running on the server, and the
installation program). My common code for the GUI and service are in
one unit in a project common directory.

I don't think anyone suggested not checking in the .csproj files, but
the .csproj.user files, which give user-specific settings for the
project.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Laurent Bugnion, GalaSoft]

Hi,

Jon Skeet [C# MVP] wrote:

MarkusR <ma*******@gmail.comwrote:

>>One poster mentioned not checking in the .sln files (which I don't
quite understand since that is the project file isn't it and how would
one open and compile the project then? Rebuild the project from
scratch?

Well, without the .sln file I suspect you're okay *if* your projects
don't refer to each other. I'd suggest checking in the .sln files as
well though.

In my last project, we checked in a few SLN files together with the
other project files. The SLN files represented typical configurations
(for example, we had one SLN for everything, one for only the web server
part of the application, one for only reporting related stuff, etc...).

When we started working on the next version of the application, we tried
not checking in the SLN files. We thought it would be easier, no need to
maintain the SLN files if there are changes in the project. Well, it
worked in the beginning, but as soon as you start maintaining
(correcting bugs, implementing change requests), it becomes a nightmare.
Mostly the locally saved SLN files are either gone or don't work
anymore. We ended up re-checking SLN files in the source control tool,
and we will keep it this way.

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch