Is it "taboo" to programatically create system restore points? I would be doing this before I perform a software update. If there is a better method to create a restore point with just my software's files and data, please let me know.
I would like a means by which I can get the user back to a known working state if everything goes kaput during an update (closes/kills the update app, power goes out, user pulls the plug, etc.)
private void CreateRestorePoint(string description)
{
ManagementScope oScope = new ManagementScope("\\\\localhost\\root\\default");
ManagementPath oPath = new ManagementPath("SystemRestore");
ObjectGetOptions oGetOp = new ObjectGetOptions();
ManagementClass oProcess = new ManagementClass(oScope, oPath, oGetOp);
ManagementBaseObject oInParams = oProcess.GetMethodParameters("CreateRestorePoint");
oInParams["Description"] = description;
oInParams["RestorePointType"] = 12; // MODIFY_SETTINGS
oInParams["EventType"] = 100;
ManagementBaseObject oOutParams = oProcess.InvokeMethod("CreateRestorePoint", oInParams, null);
}
Is it "taboo" to programatically create system restore points?
No. That's why the API is there; so that you can have pseudo-atomic updates of the system.
Whether it's a good idea or not really depends on how much you're doing. A full system restore point is weighty - it takes time to create, disk space to store, and gets added to the interface of restore points, possibly pushing earlier restore points out of storage.
So, if your update is really only changing your application (i.e. the data it stores, the binaries that make it up, the registry entries for it), then it's not really a system level change, and I'd vote for no restore point. You can emulate the functionality by just backing up the parts you're changing, and offering a restore to backup option. My opinion is that System Restore should be to restore the system when global changes are made that might corrupt it (application install, etc).
The counter argument that one should just use the system service doesn't hold water for me; I worry that, if you have to issue a number of updates to your application, the set of system restore points might get so large that important, real "system wide" updates might get pushed out, or lost in the noise.
No, it's not Taboo - in fact, I'd encourage it. The OS manages how much hard drive takes, and I'd put money down on Microsoft spending more money & time testing System Restore than you the money & time you're putting into testing your setup application.
If you are developing an application for Vista you can use Transactional NTFS, which supports a similar feature to what you are looking for.
http://en.wikipedia.org/wiki/Transactional_NTFS
Wouldn't installer packages already include this type of rollback support, though? I'm not terribly familiar with most of them so I am not sure.
Finally, Windows will typically automatically create a restore point anytime you run a setup application.
Take a look at the following link: http://www.calumgrant.net/atomic/
The author described "Transactional Programming". This is analogous to the transactions in data bases.
Example:
Start transaction:
- Step 1
- Step 2
- Encounter error during step 2
- Roll back to before transaction started.
This is a new framework, but you can look at it more as a solution rather then using the framework.
By using transactions, you get the "Restore Points" that you're looking for.
I don't think a complete system restore would be a good plan. Two reasons that quickly come to mind:
- Wasted disk space
- Unintended consequences from a rollback
来源：https://stackoverflow.com/questions/32845/creating-system-restore-points-thoughts