CSLA .NET

I have spent the last several years on a team developing an application using CSLA.  When we started, CSLA 1.3 was the latest (and .NET Framework 1.1) and we are still using these versions (it would be a major undertaking to upgrade to the latest versions at this point, though we intent to do it eventually).  Early on, we did some tests using the remote data portal with good results, however, when I got a round to trying it again over the last couple of days, I am running into a remoting error.  I thought it might make sense to ask if anyone has seen this one before.

I configure the remote data portal just as described in Rocky's book with no problems, and I am able to generate the wsdl results using a browser.  However, when I try to access the DB from the client, I receive the following error...

1) Exception Information
*********************************************
Exception Type: System.Runtime.Serialization.SerializationException
Message: Because of security restrictions, the type CSLA.Server.DataPortalContext cannot be accessed.
TargetSite: System.Object GetSafeUninitializedObject(System.Type)
HelpLink: NULL
Source: mscorlib

StackTrace Information
*********************************************

Server stack trace:
   at System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type type)
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord pr)
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord pr)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, IMethodCallMessage methodCallMessage)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, IMethodCallMessage methodCallMessage)
   at System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel)
   at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at CSLA.Server.DataPortal.Fetch(Object Criteria, DataPortalContext context)
   at CSLA.DataPortal.Fetch(Object Criteria)
   at CSLA.Security.BusinessIdentity.LoadIdentity(String UserName, String Password)
   at CSLA.Security.BusinessPrincipal..ctor(String Username, String Password)
   at CSLA.Security.BusinessPrincipal.Login(String Username, String Password)

Both of the CSLA data portal assemblies are strongly named, but I notice that the CSLA.dll assemby is not strongly named.  Could this be the problem?  Can anyone think of anything else I might want to take a look at?

One other question...

Has anyone had good results using remoting over the internet?  From what I am reading, this should not be a problem.

If anyone has seen this before and has any input, I would really appreciate it.  Thanks!!

CSLA Rocks!!
Craig

but I notice that the CSLA.dll assemby is not strongly named.  Could this be the problem?

Yes it could.

In later versions Rocky supplies a .snk file so that people who forget to sign the assembly can at least get started. But you are supopsed to provide your own .snk file as one of the very furst steps, sign and build the Csla.dll and then just include it in yuor projects.

=============================================================

On another note the upgrade from 1.x to 2.x was very difficult. Much more so than I had hoped. We have a large web app and it took 5 developers 5 weeks just to be able to re-compile the app. We found small bugs for months afterwards too.

There are just so many changes (for the better) that need to be accounted for in an upgrade from 1 to 2. Business rules was the biggest issue. Total re-write using new rule methods. Sorting and filtering was another big issue.

The move from 2.x to 3.6 should be completely painless in comparison. I think all I have to fix are the types for AddDependantProperty and it will compile. Then I need to check for breaking changes - like the elimination of GetIdValue and maybe add back the overrides for Equals in my Base classes.

HTH

Joe

 

 

 

Thanks for the input, Joe.

I strongly-named all of the CSLA files in the framework, and then replaced the old CSLA files in my solution with the new CSLA assemblies.  After a few hours of wrestling with some dependency problems in my solution, I was finally able to compile with no errors.

I still get a security error when I attempt to conect to the remote data portal, but a slightly different one.  Originally, I got the error:

"Because of security restrictions, the type CSLA.Server.DataPortalContext cannot be accessed."

Now, I get the error:

"Because of security restrictions, the type CSLA.Security.BusinessIdentity+Criteria cannot be accessed."

This leads me to believe that strongly naming the CSLA files was the right thing to do, but that it wasn't enough.  Do I need to do this to every assembly in my application???  It appears that this might be the case.

Also, thanks for the feedback on upgrading from version 1 to 2.  I suspected that it would be a MAJOR undertaking with so much being different.  If only I had started this app using verison 2 instead of version 1.  Oh well....it is what it is!

Once again, thanks for taking the time to offer some input.  Its really appreciated.

Craig

I think strong naming the Csla.dll file is all you need to do. Your own files do not have to be.

Csla does require that it be run in a full trust environment. So if you are using IIS to host the Dataportal then it must be configured to run as full trust. Review your IIS settings for the dataportal and see if you can change something to make it full trust.

Note: this lack of full trust is the main reason Rocky has been putting so much effort into a Silverlight version of Csla. The Csla community will *really* benefit from that effort down the road when Silverlight takes off!

Joe

 

Thanks again for your input, Joe.  I appreciate it.

After strongly naming all of the assemblies, I did a little research regarding how to set IIS to "Full Trust."  It seems that this can be done by adding the following lines to the system.web section of the Web.Config file on the server:

   <securityPolicy>
        <trustLevel name="Full" policyFile="internal"/>;
   </securityPolicy>

However, this had lead to another error:

[ConfigurationException]: Security level already defined for 'Full'. (c:\inetpub\wwwroot\DataPortal\web.config line 119)

So, the saga continues.  The real problem is that I know very little about Windows/IIS security.  I am not sure what I am going to have to do to get our app running.

If I figure it out, I will post the solution!.

Thanks again,
Craig

We finally got our application to run.  I thought I would post the solution we found so that others might benefit.

The changes we had to make:

1.  Strongly name the CSLA assemblies.

2.  Set IIS to Full Trust.  In the Control Panel/Administrative Tools/Microsoft .NET Framework 1.1 Configuration tool, click on the "Runtime Security Policy" node and then click on "Adjust Zone Security."  Set the Local Intranet zone security level to "Full Trust."

3.  Set the type filter level to "Full" in the web.config file with the following code added to the <application> node:

      <channels>
         <channel ref="http">
            <serverProviders>
               <provider ref="wsdl" />
               <formatter ref="soap" typeFilterLevel="Full" />
               <formatter ref="binary" typeFilterLevel="Full" />
            </serverProviders>
         </channel>
      </channels>

After making these changes, our CSLA 1.3 application seems to work fine using the remote data portal.