I have a question regarding the deployment strategy on a .NET application. In my application, I'm using DSO (decision support objects). It's a COM DLL file that is used to access an Analysis Services server (version 2000).
I've referenced the COM from the solution, and Visual Studio (actually the tool behind) nicely created a .NET assembly that wraps the access to the COM objects and makes its classes available in .NET.
The wrapping uses CLSIDs to map the DSOs COM classes to the generated .NET objects through the use of the Windows registry (when the DSO installer is run, the CLSIDs of all the public COM classes are registered there).
The problem is that when Microsft releases a new version of DSO, and when I install that new version, some, not all CLSID-s are changing in the registry, therefore the mapping of the generated .NET assembly breaks, and the application crashes.
The DSO is redistributed as part of an entire package, named Backward Compatibility Pack. When something changes in this pack, that do not necessarly have to do with DSO, some of the COM classes receive new CLSIDs. It's frustrating, because my application stops working, even if nothing really changes regarding DSO with the new package. They release this package pretty often, the newest one is with the install of SQL Server 2008 I guess, and probably is updated on every service pack.
How do I deal with the deployment in this scenario? Do I really need to create deployment packages for my application on for every DSO version that comes new?
Best Answer
You may not really need the generated RCW files.
It seems like late binding would solve your problems. Creating wrapper classes manually can be time consuming, but it depends on your usage pattern. Here is a link to a document describing late binding in .NET:
link text