Rocky --
In April there was a thread regarding CSLA, the GAC and BizTalk (http://forums.lhotka.net/forums/thread/13894.aspx).
In that thread, you made the foillowing statement:
"If you put Csla.dll into the GAC then you'll need to use its fully qualified name rather than the short name when setting up your web.config file."
Could you be a bit more specific as to what section of the web.config is being referred to here and what entries are needed?
I have been researching this on the web to the point that I am getting vertigo from all the information about config files in .NET 2.0 - not to mention the changes that came along with .NET 2.0. E.g., ASP.NET prior to 2.0 would not load a signed DLL from a web site's bin directory by design, but that changed in 2.0. Imagine one's confusion as one reads articles on the web about ASP.NET that do not mention the .NET version number and make this statement only to come across another one later that states the new functionality in 2.0. Referring to a post on your blog: Bored? Not! Overwhelmed? Pretty much!
Sorry about the little bit of 'soap box' there. ![Smile [:)]](/emoticons/emotion-1.gif)
BTW, BizTalk requires that the DLLs it loads to be stored in the GAC. If I want to call a CSLA BO from within a BizTalk orchestration (which I am trying to do), then those DLLs (and CSLA.dll) must be in the GAC. Maybe BizTalk 2006 R2 will relax this requirement, but the current version forces it upon you.
David
I was referring to the data portal configuration where you identify the proxy type to use and the assembly it comes from. The assembly it comes from is typically Csla, but if you have Csla.dll in the GAC you'll need to get the strong name from gacutil and use that instead of simply "Csla".
If there are other places where you need to specify the assembly name, the same basic rule would hold true.
Rocky --
Thanks for the help.
Just for future record, when one changes
<add key="CslaDataPortalProxy"
value="Csla.DataPortalClient.WcfProxy, Csla"/>
to
<add key="CslaDataPortalProxy"
value="Csla.DataPortalClient.WcfProxy,
Csla, Version=3.0.0.0, Culture=neutral, PublicKeyToken=93BE5FDC093E4C30"/>
everything starts to work correctly.
I am assuming that this will be the same for everyone using CSLA 3.0 since the CSLA.DLL is built with the CSLAKey.snk key file. Otherwise, one might have to modify the PublicKeyToken value listed here. I would also assume that since CSLA.dll is built with Culture=neutral, this would always be the same - even if one used a different language resouce file.
David Lutz
Copyright (c) Marimer LLC