First of all, I have to say this is both simple and excellent at the same time. Why haven’t I thought of it first? ;P
I started pondering whether this method had any flaws that would keep me from using it on my tests. Then I remembered that through my experience with NUnit, I had found that it used to create one instance of every TestFixture I had, probably to see whether it could be instantiated. I don’t know if this also happens with the current version. Back in the day, this caused me lots of grief over code I put in the constructor to call the SetUp method, so that I wouldn’t have to call it manually when calling a test from driver code.
I started to think what would happen, in theory, if NUnit created an instance of the class, thus creating the COM+ Application and starting the transaction, but just released it without the writer being able to manually commit or abort the transaction. What would happen to that transaction? Rolled back? Aborted? Committed?
I asked Roy this question and he gave me the old “Try it out and tell me what happened *wink* *wink*”, so I decided I’d go for it.
I wrote a little class inheriting from ServicedComponent, requiring a transaction and called it from some other assembly. The transaction wasn’t manually closed at any point.
Each time the transaction was started, it committed. Yes, committed.
Now, this proves that the code Roy explained can not be hurt by this, but think of the consequences of this affecting your application. If the action you did was unsuccessful and you don’t do ContextUtil.SetAbort, the transaction will get committed.
…and then we talked about this.