Get Rid of COM+ Application after Migrating to Framework 2.0
Get Rid of COM+ Application after Migrating to Framework 2.0
Scenario: Let's say that you went to work on an already-in-production system
which started on the old ages on Framework 1.1 (or lower). Back then,
transaction management could only be via COM+ application.
Beside it's advantage (back then...) in transaction management using COM Plus
is a burden for developers and has performance penalty because of inter process
communication between the main process and the DLLHost.exe that runs
the COM Plus.
Moreover, this architecture suffers from maintenance difficulties because you
have to keep at least two .config files, maybe share Dll files, and many other
error possibilities.
Therefore, altohugh COM+ has alot more to offer than only transaction management
(and because we have used nothing but transaction management) after migrating our
system to .Net Framework 2.0 we've decided to use the TransactionScope of
System.Transaction rather than the ContextUtil of System.EnterpriseServices and let
our COM+ application go
The Process:
The code, before the process should look this way:
Class decleration:
[Transaction(TransactionOption.Required)]
public class YourClass : ServicedComponent
Your methods may look like this:
public void UpdateSomething()
{
try
{
//Your code here
ContextUtil.SetComplete();
}
catch(Exception ex)
{
ContextUtil.SetAbort();
}
}
Or, with an AutoComplete attribute, like that:
[AutoComplete]
public void UpdateSomething()
{
//Your code here
}
1. Loose the reference to System.EnterpriseServices (unless you need it
not only for transaction management)
If you do need this reference besides transaction management matters,
you may temporarily loose it and correct only the transaction-related
compilation errors to come.
2. Add reference to System.Transactions
3. Loose the ServicedComponent inheritances and Transaction
attribute for your class.
4. On every method, Insert the using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required))
block to cover all transaction activities area.
After doing so, your method should be looking like that:
public void UpdateSomething()
{
try
{
using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required))
{
//Your code here
ts.Complete();
}
}
catch(Exception ex)
{
//Do something with the exception
}
}
5. If your transaction managing methods uses ContextUtil.SetComplete() /
ContextUtil.SetAbort() methods you might replace the ContextUtil.SetComplete()
call by ts.Complete() call and erase the ContextUtil.SetAbort() call.
If your method is decorated by an AutoComplete attribute you might
place the ts.Complete call at the end of your TransactionScope block.
6. After your transaction managing assembly is compiled, all calling assemblies
project probably have compilation error, that is because your classes
won't implement IDisposable (implemented by ServicedComponent) anymore,
and therefore you cannot use them in a using(...) block.
Here you have two options:
A. Implement IDisposable yourself.
B. Remove the using(...) block and call them regularly.
Because from now on, these classes will be used on the same process,
you don't have to use the using(...) block and therefore I'd recommend
removing the using(...) block and call them regularly.
This process might take long but it can be done in steps. You can remove
the System.EnterpriseServices reference deal with several classes,
add it back on, deal with calling assemblies compilation errors and so on...
Summary:
If you've used COM+ for transaction management solly Loosing the dependency
on COM+ application is worthwhile, although it is a long process and must be
done with extreme caution. The transaction managing assembly is most of
the times the business layer assembly and needless to say how harmful reckless
changes can be there.
However, If there is one thing my colleges thank me for, loosing the COM+
application it is.
