legacyCasModel="true" and dynamic data/operations

17,856

I haven't used much DLR stuff but I just tried a quick test. In a console application the equivalent of your command fails ...

        dynamic d = new object();
        d.test = "jason";
        Console.WriteLine(d.test);

But this succeeds ...

        dynamic d = new ExpandoObject();
        d.test = "jason";
        Console.WriteLine(d.test);

When using dynamic objects you may need to use ExpandoObject rather than plain old object.

In cases where ExpandoObject doesn't meet your needs something more powerful like http://clay.codeplex.com/

=== EDIT ===

Helps if I read the question fully ...

Adding in <trust legacyCasModel="true" level="Full" /> to the mix causes both to fail with the error provided.

"legacyCasModel" forces a non-homogeneous domain as it is the pre-.net4 way of doing things. This means that dynamic objects and your older CAS library are incompatible.

The only valid workaround that I can see would be to abstract that older CAS library to run in a seperate application domain.

Share:
17,856
Jason Kealey
Author by

Jason Kealey

Founder, LavaBlast Software - software for the franchise industry.

Updated on June 04, 2022

Comments

  • Jason Kealey
    Jason Kealey almost 2 years

    This is similar to Odd Exception in MVC 3 Project.

    We have an ASP.NET 4.0 application running in full trust. We need to have the following line in our web.config, otherwise one of the libraries we are using does not function. (As it explicitly uses the now obsolete CAS model from previous versions of .NET).

    <trust legacyCasModel="true" />
    

    Given this setting, we are unable to use the dynamic keyword or certain features of ASP.NET MVC which rely on it.

    As an example, the following code causes an exception:

    dynamic d = new object();
    d.test = "jason";
    

    The exception is:

    Dynamic operations can only be performed in homogenous AppDomain.
    

    Is there any way I can make the dynamic keyword work if legacyCasModel is set to true? (If set to false, everything works fine, except the library that requires it.)

    Ideas:

    1. Given that I am running in full trust, I assume that one assembly in the AppDomain is utilizing reduced permissions (hence the non-homogeneous). Is there a way I can simply tell it to run in full trust mode, making the AppDomain homogeneous?

    2. Should I be able to refactor my code somehow to load the problematic assembly in another AppDomain? I'm not familiar with typical ways of doing this, but it appears complex.

    3. Is there some other magical configuration setting I can enable to make it work?