SeeAlso: EDRAWiki

Summary: This pages contains suggestions for how to use VSS with EDRA.

1. SNK file management

There are different ways of handling the management of your SNK file, but the best option is to have everyone share a single SNK file. It'll make things the easiest. If a developer has already installed EDRA with the creating a new SNK file option, then overwrite the one on their machines with the single shared SNK file and re-run the template setup.wsf script. It will recompile the DLL's using the replaced SNK and re-update the config file references to the correct PublicKeyToken.

I would store the single shared SNK file in VSS for easy retrieval access. You can have your developers use the "SNK file already exists" option when installing the EDRA MSI, but it's really just as easy to overwrite the new SNK file with the shared one (via pulling from VSS) as your first step after installing the EDRA MSI using the "Create new SNK file" option.

2. Management of framework source

One option is you could modify the template project to reference the framework code in DLL form instead of project references and we included a template built this way in v1.1, but it does eliminate the ability to trace into the framework code and many developers will prefer to retain the ability to trace through the framework code. Another option is not keeping the framework source in VSS and letting the developers get the framework source onto their machine via running the EDRA msi. You'll still be able to rely on the consistent presence and structure of the framework source on their machine. If you're planning on making changes to the framework source then I would recommend keeping a single copy of the framework source in VSS versus a copy of the framework source in each projects VSS tree.

3. Config file management

Sharing a single SNK file will solve much of the trouble here, so you don't have to worry about DLL references. To handle the other problem of directory path references in the config files, the easiest effective solution is to get every developer on a project to use the same directory structure for the project, so effectively it means them all setting their VSS working folder to the same path on their local machines. That way, the directory path references in the config file will be valid for all developer machines.

4. Project source management

When starting a new project, you should have one developer use the CreateNewTemplate script to copy the template project to an alternate location (outside of the Program Files directory) then adding the template project (from the alternate location) to VSS and having the other developers pull it from VSS (with their working folder set to the same path as the developer that added it). If your developers tend to work on more then one project, then make sure the projects created with the CreateNewTemplate option use unique folder locations so your developers won't have a pathname conflict when setting their working folders for each project.