Comments on: Testing your deferred and rollback custom actions

By: Bob Arnson

Bob Arnson — Sat, 21 Jun 2008 14:38:59 +0000

Like any advanced option, it’s potentially dangerous.

By: Christopher Painter

Christopher Painter — Fri, 20 Jun 2008 18:57:23 +0000

I would think a better solution would be to either block the package as suggested by MSDN doco or have a conditionalized alternative custom action that schedules as Deferred execution instead of Commit execution in the event rollback is disabled by policy.

Your suggestion that you don’t need to test for rollback policy and it’s the admins fault for doing it would lead to a very poor user experience IMO.

http://msdn.microsoft.com/en-us/library/aa367991(VS.85).aspx

“Rollback and commit custom actions do not run when rollback is disabled. If a package author requires these types of custom actions for proper installation, they should use the RollbackDisabled Property in a condition that prevents the installation from continuing when rollback is disabled.”

By: Christopher Painter

Christopher Painter — Fri, 20 Jun 2008 15:29:32 +0000

Are you basically saying the disabling rollback should no longer be supported?

By: Bob Arnson

Bob Arnson — Fri, 20 Jun 2008 14:41:26 +0000

If rollback is disabled, there’s nothing to test. It’s up to the admin to live with the consequences.

By: Christopher Painter

Christopher Painter — Thu, 19 Jun 2008 14:04:09 +0000

Your missing a test case: Rollback disabled by policy. That’s going to break a lot of CA’s where people have been choosing Commit execution because the underlying API doesn’t support transactional changes.

The problem is, this isn’t really what Commit was meant for. It was meant for cleaning up rollback data.