Permission Denied - Cross process UI using .NET Remoting and FrameworkElementAdapters

My question is very similar, if not a replica of this one. Irritatingly, the 'answer' doesn't give me a whole lot to work with and frankly I'm at a loose end.

The probl开发者_如何学编程em should be fairly obvious. I want to pass WPF elements between processes for a pluggable application framework without having to use Managed AddIn Framework. I deploy to an environment where caching files to disk out of my control is unacceptable due to highly restrictive permissions. The are workarounds - putting the addin root in appdata - but the enforced directory structure is undesirable and that is not what that folder is for as far as I'm aware.

The excepting method is as follows with the excepting lines highlighted in bold:

delegate void AddUIElementDelegate(Client client, System.AddIn.Contract.INativeHandleContract handle);
        private void AddUIElement(Client client, System.AddIn.Contract.INativeHandleContract handle)
        {
            if (this.Dispatcher.CheckAccess())
            {
                var element = System.AddIn.Pipeline.FrameworkElementAdapters.ContractToViewAdapter(handle);
                m_UIElements[client] = element;
                StackPanel_PluginUIHost.Children.Add(m_UIElements[client]);
            }
            else
            {
                this.Dispatcher.BeginInvoke(new AddUIElementDelegate(AddUIElement), client, handle);
            }
        }

Experimentation seemed to required that the handle is unmarshaled through FrameworkElementAdapters.ContractToViewAdapter() on an STA thread, hence the invoking. It should be noted that client is a callback MarshalByRefObject and is accessed in this method through a proxy. handle was also created remotely with a call to FrameworkElementAdapters.ViewToContractAdapter() and passed into this Application Domain as the return value of a remoted method.

The exception I recieve is RemotingException occured - Permission denied: cannot call non-public or static methods remotely.

Any feedback is welcome folks.

---

The message you're getting includes the possibility that you're calling into a non-visible method. Checking out another assembly's privates (... that just sounded wrong) is not a "type-safe" operation, and performing non-type-safe operations requires your assembly to have the highest trust the CLR can give: SkipVerification. Not only will the CLR not verify permissions for normal "sandbox" tasks, it will let your code out of the sandbox unsupervised, and if the OS cops shut you down for breaking the rules, it's your problem. Since you mentioned the code executes in a highly restrictive permission space, I doubt this is an option.

Perhaps you should review the checks that Dispatcher.CheckAccess() is performing. Sounds like you're getting a false positive from it about your ability to work with the callback delegate.