Hi,

I read the first few parts. The author specifically says not to put some files into source control but does not say anything about not putting the solution file in there.

Another question... I'm working with someone at the moment that says not to put project files into source control. I think that this is not very sensible given the amount of configuration that can be made to a project file. What do you think?

Cheers, Ian.

Ian wrote:

I read the first few parts. The author specifically says not to put some files into source control but does not say anything about not putting the solution file in there.

Because you should check your solution file in.

Ian wrote:

Another question... I'm working with someone at the moment that says not to put project files into source control. I think that this is not very sensible given the amount of configuration that can be made to a project file. What do you think?

Um... YES you should certainly check in both your Solution file and Project files. How else would it work when another dev adds a class to the project?

What you shouldn't check in are the "user" solution and project files. These are the .sou and .user files. They have user settings in them like reference paths, what projects are expanded, which project is the start project, etc.

They main mistake I think VS makes is that for a web application the URL is in the project file rather than the .user file. This forces all of our devs to use the same vdir for each app/branch.

BOb

What you should check in are the "user" solution and project files.

Are you sure you don't mean "should not check in"?

Its a little confusing really. I've now worked with one person that said don't add the solution to source control and another that said don't add a project.

It makes most sense to me that both should be in source control - as you say.

Depends on the sourcecontrol system you're using

If it's subversion or similar sourcecontrol systems: go ahead, and add it. If it's any microsoft's SCC api using sourcecontrol system: I'm not so sure. The thing is that vs.net adds sourcecontrol crap to the solution file when it is under sourcecontrol.

The main downside is that when you want to share a project under multiple solutions, you can't. You have to copy the project inside the sourcecontrol system under multiple solutions, otherwise you'll get nightmares with the path information inside the solution files as they contain sourcecontrol info about the projects!

Ian wrote:

What you should check in are the "user" solution and project files.

Are you sure you don't mean "should not check in"?

Yes... sorry. I edit and fixed that.

BOb

Otis wrote:

If it's any microsoft's SCC api using sourcecontrol system: I'm not so sure. The thing is that vs.net adds sourcecontrol crap to the solution file when it is under sourcecontrol.

That's a good point... and a main reason I don't use SCC providers. The apps always want to mess with my files. I guess my history with Visual FoxPro and SCC providers really trashing the project files always keep me from using them. Some people like it, but I am much prefering the shell add-in interface of Tortiose to any SCC interface I have used yet.

I still don't know why at times VS opens the Pending Checkins window. I have none of my solutions using SCC and it still want's to open that window.

Bob

When using CVS with .NET projects, don't you experience problems when multiple users create new files in the same project? I've used the TortoiseCVS client and experienced the issue so I switched to VSS. With ASP.NET web applications, however, you don't really have the concept of project files so CVS works pretty well there.

I find VSS to be pretty good in enforcing locks when working in small teams.

Recently, I've been using SVN (with the TortoiseSVN client) and think it's pretty cool - especially for conflict resolution.

Um... YES you should certainly check in both your Solution file and Project files. How else would it work when another dev adds a class to the project?

If project files are added to source control then doesn't this mean that all project contributors have to have the same directory structure so that the project's references can always find their corresponding dll?

So if my main web project references a dll that's generated by a secondary project (perhaps containing web controls) then...

a) all other users that share the project file for the web site _must _checkout the secondary project and

b) make sure that the location of the secondary project relative to the main project is as expected by main's project file?

Maybe that didn't make much sense. Let me try again....

Um... YES you should certainly check in both your Solution file and Project files. How else would it work when another dev adds a class to the project?

Yes of course. But what if another dev wants to reference a different version of a referenced dll?

Lets say a project is referencing a release dll in a 'binaries' folder and a developer wants to debug the source code for the referenced dll. So they check out the project for the referenced dll and change the reference so that it points to the debug dll generated by the checked out project.

Now, if this developer checks their project back in then when everyone else checks it out, they'll get compilation errors because they haven't dowloaded the source project.

I guess what I'm saying is that it seems projects contain shared data _and _developer specific data.

I may be way of track here but I reckon there should be a default value for references which are shared and then overides for these values that are developer specific.