Building AlphaVSS from Source
Files and Projects
The AlphaVSS solution and project files were created using Visual Studio 2008. If you download a released source, you should have no problems opening these. If you download from the trunk, chances are you will get an error message about missing TFS bindings
or something similar. This is no cause for alarm as Visual Studio should present you with an option to remove these bindings.
The solution contains two projects, AlphaVSS.Common which is common to all platforms and can be built in two configurations, Release and Debug, as well as AlphaVSS.Platform which contains the platform specific code. This is available in 12 configurations in
total, WinXP, Win2003, and Win2008 all in both Release and Debug modes as well as targeted for x86 and x64 platforms.
Note that the Win2008 target is used for both Windows Vista and Windows Server 2008
To be able to build the WinXP and Win2003 targets you need the VSS SDK 7.2 installed available from
. The projects assume that it is installed in its default location "C:\Program Files\Microsoft\VSSSDK72". If it is not, you will have
to change this in the project settings for the WinXP and Win2003 targets of AlphaVSS.Platform.
To build the Win2008 targets you need Windows SDK 6.1 installed. It is available at
. This should integrate with your build environment, so no specific directories should have to be set.
Delay Signing and Strong Names
The projects are set to use delay signing of the assemblies using the included public key (AlphaVSS.pub.snk). This means that they will not be usable until signed with the proper private key, which is not available to the public. You can use the sn.exe tool
to enable the loading of those assemblies on your local machine by running "sn.exe -Vr
,3033cf2dbd31cad3". This will enable all assemblies with the specified public token to be loaded on your machine. (To remove this permission run "sn.exe -Vu
,3033cf2dbd31cad3" If you don't want to do this you will need to either disable signing the assemblies with a strong name in the project files and perform the loading of the assemblies yourself. This because VssUtils.LoadImplementation relies on
the strong names of the assemblies to load them. Another option is to sign them with your own private/public key pair and modify the public key token in VssUtils.cs to your new public key token. (A better option would be to file a work item in the issue tracker,
providing your suggested changes and have them included in the next release though).
For more information about strong names, signing of assemblies and delay signing in general, refer to the MSDN documentation on the subject or Google.
If you have any questions, please use the Discussion board here at CodePlex.