权限被拒绝 - 使用 .NET Remoting 和 FrameworkElementAdapters 的跨进程 UI

发布于 2024-09-25 13:45:05 字数 1373 浏览 4 评论 0原文

我的问题非常相似,即使不是这个问题的副本。令人恼火的是,这个“答案”并没有给我太多的帮助,坦率地说,我处于无所事事的状态。

问题应该是相当明显的。我想在可插入应用程序框架的进程之间传递 WPF 元素,而无需使用托管外接程序框架。我部署到的环境中,由于权限严格限制,将文件缓存到不受我控制的磁盘是不可接受的。有解决方法 - 将插件根目录放在 appdata 中 - 但强制的目录结构是不可取的,据我所知,这不是该文件夹的用途。

排除方法如下,排除行以粗体突出显示:

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);
            }
        }

实验似乎要求在 STA 线程上通过 FrameworkElementAdapters.ContractToViewAdapter() 解组句柄,从而进行调用。应该注意的是,client 是一个回调 MarshalByRefObject,并在此方法中通过代理进行访问。 handle 也是通过调用 FrameworkElementAdapters.ViewToContractAdapter() 远程创建的,并作为远程方法的返回值传递到此应用程序域中。

我收到的异常是发生RemotingException - 权限被拒绝:无法远程调用非公共或静态方法。

欢迎大家提供任何反馈。

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 problem 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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

久光 2024-10-02 13:45:05

您收到的消息包括您正在调用不可见方法的可能性。检查另一个程序集的私有(...这听起来是错误的)不是“类型安全”操作,并且执行非类型安全操作需要您的程序集具有 CLR 可以给予的最高信任:SkipVerification。 CLR 不仅不会验证正常“沙箱”任务的权限,还会让您的代码不受监督地脱离沙箱,如果操作系统警察因违反规则而将您关闭,那就是您的问题了。由于您提到代码在高度限制的权限空间中执行,我怀疑这是一个选项。

也许您应该检查 Dispatcher.CheckAccess() 正在执行的检查。听起来您似乎从中得到了关于您使用回调委托的能力的误报。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文