CSLA and COM AddIns

pluc posted on Tuesday, April 24, 2007

Hello All:

I am in the process of creating a COM add-in for MS Excel.  The add-in references an assembly of CSLA-based business objects.  The add-in itself is COM visible and registered, and is located in a different directory than that of Excel.  I have two questions:

1.) How do I handle CSLA configuration for situations where I do not have an application configuration file? In the case of my COM add-in, System.Configuration.ConfigurationManager is looking for C:\Program Files\Microsoft Office\OFFICE11\Excel.exe.config, which does not exist and I do not want to modify the contents of the directory in any way, shape or form.  Class libraries don't recognize App.config files, so I'm looking for suggestions on how to configure CSLA.  Thoughts?

2.) I created a temporary work around for Issue #1 so that CSLA was properly configured.  I am able to successfully make calls to the data portal, and things process properly server-side.  However, upon returning to the client, I get an exception stating that Csla.dll can not be located within C:\Program Files\Microsoft Office\OFFICE11.  Why would this be the case?  The call orginated just fine from a different directory altogether, so why revert back to Excel's install directory.  I have tried placing CSLA in the GAC (something I do not want to do) to no avail; I get the same message.  I have tried adding the correct path to the environment path variable to no avail as well.  Thoughts?

Any feedback would be greatly appreciated.  Thanks in advance.

RockfordLhotka replied on Tuesday, April 24, 2007

I think a solution to #1 is that you can set the AppSettings values through code. System.Configuration.ConfigurationManager.AppSettings is just a dictionary, and you can alter it through code.

The problem you are seeing in #2 is common to any scenario where .NET assemblies are hosted by another program. There's a "feature" (I see it as a bug) where deserialization doesn't check all the loaded assemblies to find the type into which data should be deserialized. So even though the assembly is loaded, it isn't found.

The workaround isn't hard, and can be found in Chapter 4 in the EnterpriseServicesPortal class - because EnterpriseServices (COM+) also hosts .NET and so it has the same issue. So does IE, my NetRun program from .NET 1.x and so forth.

You can literally copy and past the serialization workaround code from Chapter 4 into your code. Then just make sure to call the static workaround method once (and only once) during the lifetime of your AppDomain.

pluc replied on Tuesday, April 24, 2007

Thank you much for the response!  I will give this a shot.  I've been studying and working w/ CSLA since late last year and am loving it!  Thanks again.

Kind Regards,
Paul