These are the SharePoint developer tools for Visual Studio 2008. I had been using these to develop some features for SharePoint, specifically Content Types and Site Columns.
When VSeWSS 1.3 packages (builds the WSP) the SharePoint project for deployment it creates a pkg folder inside your project directory where it maintains the IDs of the solution and features (manifest.xml, feature.xml) for the project. This folder is not connected to source control by default and so this is where all the problems begin.
If you ever plan to upgrade a solution you deployed to SharePoint all the Feature IDs must match, including the Solution ID. If the pkg folder does not exist Visual Studio will recreate it and assign all new GUIDs to your IDs which make upgrading your solution impossible.
You can of course fix this manually by getting the Feature IDs and Solution ID from the .xml files of the .wsp you deployed previously and synch them up with the .xml files in the pkg folder. This is not ideal so I recommend that you check-in the pkg folder and its contents so the next developer on your team that updates a feature ensures that all the IDs match those of what was deployed to production.
If you want to see information about a particular solution installed in your farm you can execute the following command:
stsadm -o displaysolution -name <feature name>
Upgrading a solution:
stsadm -o upgradesolution -name <feature name> -filename <filename> -immediate -allowgacdeployment
If a feature you added to your upgraded solution is not deployed you can execute the following command to check:
stsadm -o scanforfeatures –displayonly
This will scan for new features in the file system, you might find that your feature is listed and if it is run the same command dropping the displayonly option.