Must be written in C# (.NET version 3.5 or 4.0) with exception of parts that may require C++.  If C++ is required, it must be managed C++.

The finished work must be provided as one or more Visual Studio Solutions in VS 2008 or VS 2010.

I must be able to build Release and Debug versions and be able to run debug version in Visual Studio for testing.

The Worker should be designed to work within a Windows service or within a client application.  The Worker and UI should communicate using Windows Communications Foundation (WCF), probably using .NET Remoting, but that decision can be made at a later time.  In order for me to make sure that you read all of the requirements, you must have the word “pineapple” somewhere in your bid for me to consider your bid. The UI should be able to manage a Worker by connecting to a machine that has a Worker running.  For now, authentication is not necessary.   All request needed to populate  the UI should go to the Worker and not directly to the local system since the local system would not have the correct information for a Worker on a remote system.

 

If you are not familiar with VSS, I would highly recommend you read through the documentation provided by Microsoft before you make a bid.

The UI should be able to present appropriately at least the following types of special backup situations:

• Microsoft Exchange 2000 and up

• Windows System State (registry, etc.)

• Active Directory

For backup:

1. A button on the UI should request from the Worker all available writers from VSS on the system that the Worker is on. In addition, get a list of all local volumes to the Worker.

2. Each application that has a writer should be presented in a TreeView that can be selected (or partially selected, for example: we should be able to select only one complete set of multiple exchange data stores, but not part of a data store) for backup. Also a file selection for the volumes should be displayed to backup files that are not VSS aware (no VSS writer).

3. The file list should not be loaded all at once, the user should be presented with a list of drives and as the user expands the tree for that volume, files and folders should be requested from the Worker and presented to the user.  This list should be cached on the UI side so that redundant requests are not made to the Worker.  The cache should expire based on time (maybe around 1 minute).

4. Selections should work similar to the selection tree in ntbackup.

5. The UI should have a Browse button to select a target path where the backups will be written to (this could be a local volume or a UNC path), again, the target path browse function should go through the Worker and not be directly from the UI.  

6. The UI will have options to select backup type (Full, Differential or Incremental) for writers that support those options.

7. The UI will have a start backup button that will send all the information required to the Worker to run the backup job, and show the progress of the backup. Typically progress is done by the UI registering to an event published within the component dll.  I do not want it that way.  I want the UI to poll the Worker on a periodic basis (once every second).  If you need to use events within the Worker itself, that is acceptable. 

8. The progress should contain at least the following information: Filename, file x of y files, file size, current file progress (either in bytes or percent), total bytes of all files, total progress (either bytes or percent).

9. The backup copies should preserve all NTFS ACLs and attributes (probably within the manifest for the file, see item below on manifest, it may be possible that the target volume may not be NTFS), they should also have all Alternate Data Streams (ADS) if any exist. Alternate Data Streams should be stored as normal files with modified files names that make it clear that they are part of another file. We would need to make sure we have a naming system that would not potentially have a collision with other file names.

10. Very long file paths should also be supported.  Windows has a limit of 260 characters, while NTFS does not.  It is easy to exceed the 260 char limit on a file server with a share where the share has a short path to the client system, but ends up exceeding 260 char when on the server.

11. Since most of the special backup situations have multiple files that are part of a set that get backed up, the target location should also contain some sort of manifest file with a list of the files that are part of the set. We would probably need to have the complete location of the file in addition to the name, file size, last modified date, a file hash (for validation) and Alternate Data Stream information.  This would be important for the restore process. This manifest should probably be an xml file or a flat text file but I’m open to other suggestions.

For Restore:

1. Browse and select a source path/file (through the Worker)

2. Depending on the type of file set that was selected as the source, there may or may not be an option given for a target path.  For example, Active Directory requires the system be Directory Services Recovery mode and you would then use VSS to do the restore. System State requires steps as shown here: http://msdn.microsoft.com/en-us/library/aa381498(VS.85).aspx

3. Standard files should refer to the manifest to make and restore appropriate ACLs and attributes.

4. Button Restore – runs the restore process and shows the progress using the same constraints on events as backup

While I gave examples and a link above on what different situations are required, by no means is that a comprehensive list.  You need to make sure that you have read through the VSS documentation and understand the correct way to backup and restore the types that I have listed and provide the correct methods and document manual procedures that may be required.

Backup and Restore UI should each be written so that it would be very simple to separate them into two independent applications if required.  

The UI should be simple and should not have any changes from the default Visual Studio Styles/Colors/etc.  Don’t change background and foreground colors or styles to try and make it look fancy.  

All code that you write must be very well commented. 

You must provide clear documentation of the required steps to completely build the application.  For example, AlphaVSS requires strong names and signing to work correctly. I would need the complete steps in creating/obtaining our own private/public key and applying it to the assemblies that need it. 

It is possible that I have neglected to mention important requirements, I will rely on you to make sure that this application works as intended (to reliably back up and restore files and special type of databases as specified above) even if I missed to specify something important. 

If something is not clear, please ask before bidding.