Comparison / Best Practices of VS 2005 project styles
Moderator: SourceGear
-
- Posts: 1
- Joined: Mon Mar 12, 2007 12:54 pm
Comparison / Best Practices of VS 2005 project styles
I’m looking for some best practices and/or advantages/disadvantages analysis of utilizing the various VS 2005 projects with SourceGear. For example, Web Application Projects work great with SourceGear as they were designed ala the VS 2003 model for which SourceGear was also originally designed. However, what about the use of Web Site/File Projects in SourceGear? Wouldn’t compiling and adding third-party libraries where the Bin directory is included in SourceGear cause problems in a multi-developer environment?
We are currently working on some new articles for VS2005, but really, I guess I can't say I see where there's been any specific problems. The one difference I've seen is that rather than going to the source control menus in Visual Studio that one instead goes to the web menu for opening and a few other operations, and then select source control in that dialog box instead. That is detailed out in this KB article: http://support.sourcegear.com/viewtopic.php?t=5548.
Can you describe for me what you're seeing?
How do you intend to use those files? I have some customers who never modify them, some that treat them like regular parts of a project, some that have their own modified version on each system that never get checked in, and some that don't bother putting them into source control.
Can you describe for me what you're seeing?
How do you intend to use those files? I have some customers who never modify them, some that treat them like regular parts of a project, some that have their own modified version on each system that never get checked in, and some that don't bother putting them into source control.
(Changed username)
In a Web Application Project (WAP), if you delete the bin folder and compile, it recreates it. Further, in a WAP, you never check the bin folder (or obj folder) into SourceGear. However, in a Web Project, the bin folder not only contains the output of your referenced projects, it contains any third-party dlls which means you have to check-in your bin folder in a WAP just like any other folder or file. If I remember correctly, that causes serious problems in a exclusive checkout scenario ala VSS. I would imagine that using a CVS style checkin this wouldn't be as much as a problem. Am I missing something? How are people using Web Projects with SourceGear in a team enviroment or are they?
In a Web Application Project (WAP), if you delete the bin folder and compile, it recreates it. Further, in a WAP, you never check the bin folder (or obj folder) into SourceGear. However, in a Web Project, the bin folder not only contains the output of your referenced projects, it contains any third-party dlls which means you have to check-in your bin folder in a WAP just like any other folder or file. If I remember correctly, that causes serious problems in a exclusive checkout scenario ala VSS. I would imagine that using a CVS style checkin this wouldn't be as much as a problem. Am I missing something? How are people using Web Projects with SourceGear in a team enviroment or are they?
Right, that's a Visual Studio thing.if you delete the bin folder and compile, it recreates it.
I don't recall seeing an exclusive checkout issue with Vault with those files. CVS style won't work with Visual Studio.
We have lots of users using the IDE integration of Vault with Visual Studio including with Web Projects.
The most common scenario is that users don't store the bin files in source control.
Then how do references to third-party dlls get into SourceCode control since with Web Projects they are stored in the Bin folder? Do you simply include a "Lib" folder and developers re-reference those dlls' whenever they rebuild their directory tree?We have lots of users using the IDE integration of Vault with Visual Studio including with Web Projects.
Is it not the case that when you add the site to SCM via VS that it adds the bin folder by default?
So, basically the short version is that you have to hack up VS ;->.
Being serious, would not that solution have problems in terms of SCM? In other words, the spiffy pre-build step wouldn't get into SourceGear. Thus, if someone blows out their working directory and gets the latest code, they'll have to reconfigure that pre-build process for every project would they not?
Being serious, would not that solution have problems in terms of SCM? In other words, the spiffy pre-build step wouldn't get into SourceGear. Thus, if someone blows out their working directory and gets the latest code, they'll have to reconfigure that pre-build process for every project would they not?