How do we setup a SharePoint dev environment with VSeWSS 1.2 and Source Safe?

Does anyone use the MS SharePoint Solution Generator and VSeWSS 1.2 in a multi-developer environment with source safe? We are having issues re-deploying (because it doesn't really upgrade the solution with stsadm). It keeps saying the same feature is already installed - which it is, but it should retract the feature and re-install it - which it doesn't on some machines. Something is messed up with the feature's GUID but we can't find where that might be. One dev will be able to deploy and re-deploy but then the next dev won't. Where does VSeWSS 1.2 change the GUIDs? ARG!!!

We see the nice deployment targets (upgrade, etc) in STSDev but we're reluctant to use STSDev or the other codeplex tools because they are not supported by Microsoft. We have Visual Studio 2005 but not the money to upgrade to VS 2008 to get VSeWSS 1.3 - bummer.

---UPDATE---- I think we found a bug in VSeWSS that other's have commented on: Editing the projects properties resets some feature GUIDs.

It might also be a problem with the scope of the install. How do we get a site definition to install to the FARM scope in VSeWSS 1.2?

From stackoverflow

• Don't worry too much about supported by Microsoft too much. While it is a consideration, the end result of MS SharePoint Solution Generator (terrible) and VSeWSS 1.2 are still SharePoint solutions and all solutions need to contain the same xml.

  Could the deployment targets for STSDev be modified to work with your VSeWSS solution? After all, the deployment targets here are just working with STSAdm and a solution file.

• In order to avoid the usual "works on my machine" you should set up a build and deployment system. If you are using virtual server or ESX server it should be fairly simply, and cheap as well. You should be able to use open source software all the way if you have more man power then money.

  dirq : We could have a virtual machine for each developer - is that what you're saying? Although it wouldn't be "cheap" - we'd have to have a Windows Server 2003 license for each VPC and probably another license for Visual Studio..

  Kasper : No not nessisarily, the idea is to have a central build machine and deploy the solution to a "clean" machine (new) each night. A MSDN subscription is not cheap but it is great for a dev shop, since you will get both server licenses and visual studio.

• VSeWSS 1.2 and 1.3 store the feature GUID's in files in the /PKG directory of your Visual Studio solution. If you delete these files, or check our project into Source Control without these files and check them out on another machine, you will lose your GUIDs. Sure, VSeWSS will recreate the missing files for you, but it will do so with new GUIDs and new feature names.

  A common requirement is to add the /PKG directory to your Visual Studio 2008 project and get it into source control.

  You can read more about the files in the /PKG directory in the Release Notes for VSeWSS 1.3 here.

  PS: We did some improvements to the Solution Generator in VSeWSS 1.3, but it wont generate a 100% perfect solution for you.