COM/Csla 2 issue

COM/Csla 2 issue

Old forum URL: forums.lhotka.net/forums/t/713.aspx


razorkai posted on Monday, July 24, 2006

Hi guys.

I have a requirement to be able to automate my application from several non-dotnet applications.  This means that technologies like remoting are not available to use.  It looks as if Com (shudder) is the only option.  It is fairly easy to get Com up and running and I was able to create a simple dotnet class that I could call into from a test VBS script using something like

set o = GetObject("", "MyNamespace.MyClass")

This actually gets a new instance of my class rather than one within my running application. It turns out I needed to create an instance of my class from my application and register it in the running object table.  Then when I run the above VBS it gets a reference to the actual object I created within my dotnet app.  So far so good.  But when I try to call a method on that object to show a form that uses Csla objects I get the good old "Principal must be of type BusinessPrincipal, not System.Security.Principal.GenericPrincipal" error when it tries to call a Csla Factory method.  The application does the standard Logout/Login combo at startup and I have checked that after the app has started up the principal is correct.  It seems like it must be some sort of threading issue i.e. the Com call is running on a different thread that has not had the principal set on it.  Anyone got any suggestions as to how to avoid this problem or even better how to provide automation without Com!

Hope someone can help!

John.

Fintanv replied on Tuesday, July 25, 2006

I had the same issue using CSLA 1.4.  I wanted to make some of the functionality of my application available from within the .net MDI GUI, as well as start up specific forms from within Excel.  Since my code was encapsulated within a dll, there is no way to get the app.config file read.  Since we use windows integrated security in our org, the solution I went with was to modify the DataPortal code so that the default security implementation was windows security rather than CSLA security.  This change allowed me to get up and running.

As a further note, I also ran in to issues with dependancies since my COM invoked dll held a form that inherited from a base in a second dll.  COM could not find the second dll and it was not appropriate to add it to the GAC.  The resolution was to use the /codebase option on regasm (my dll's are all signed).  Now everything is working fine.

Regards, Fintan

Copyright (c) Marimer LLC