为什么 WPF 设计器无法加载调用非托管 DLL 的库?

发布于 2024-11-07 16:45:54 字数 1050 浏览 1 评论 0原文

我正在使用 Visual Studio 2008、.NET 3.5 SP1,并且有一个包含以下模块的测试应用程序:

  1. C++ DLL
  2. 使用 #1 的 C++/CLI DLL
  3. 使用 #2 的 C# WPF 应用程序

当我尝试使用 # 中的类时2 作为 WPF XAML 中的资源,设计器不会让我:

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:lib1="clr-namespace:ClassLibrary1;assembly=ClassLibrary1" <- ERROR 

错误是:“未找到程序集‘ClassLibrary1’。请验证您没有缺少程序集引用。另外,验证您的项目和所有引用的程序集是否已构建。”

但是,当我在应用程序主窗口的代码隐藏中使用 C++/CLI DLL 中的类时,一切正常。 Class1 已创建,并且在其构造函数中调用 C++ DLL,没有问题。

using ClassLibrary1;

...

public partial class Window1 : Window
{
    public Window1()
    {
        InitializeComponent();

        //use in code-behind
        Class1 tmp = new Class1();
        tmp.FirstName = "foo";
        Title = tmp.FirstName;
    }
}

如果我修改 C++/CLI 程序集,删除其对 C++ DLL 的调用并重建所有内容,设计人员将停止抱怨并毫无抱怨地加载 C++/CLI 程序集。

我怀疑这个问题与 WPF 设计器寻找动态库的位置有关。

I am using Visual Studio 2008, .NET 3.5 SP1, and have a test application with the following modules:

  1. a C++ DLL
  2. a C++/CLI DLL that uses #1
  3. a C# WPF application that uses #2

When I try to use classes from #2 as resources in the WPF XAML, the designer won't let me:

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:lib1="clr-namespace:ClassLibrary1;assembly=ClassLibrary1" <- ERROR 

The error is: "Assembly 'ClassLibrary1' was not found. Verify that you are not missing an assembly reference. Also, verify that your project and all referenced assemblies have been built."

But when I use a class from the C++/CLI DLL in the code-behind of the application main window, everything works fine. Class1 is created, and in its constructor it calls into the C++ DLL, no problem.

using ClassLibrary1;

...

public partial class Window1 : Window
{
    public Window1()
    {
        InitializeComponent();

        //use in code-behind
        Class1 tmp = new Class1();
        tmp.FirstName = "foo";
        Title = tmp.FirstName;
    }
}

If I modify the C++/CLI assembly, remove its call into the C++ DLL and rebuild everything, the designer stops complaining and loads the C++/CLI assembly without complaint.

I suspect this problem has something to do with where the WPF designer looks for dynamic libraries.

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

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

发布评论

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

评论(2

梦在夏天 2024-11-14 16:45:54

由于 Visual Studio 设计器将程序集复制到临时位置,但不复制非托管依赖项,因此您可能会遇到此问题。

最简单的解决方案(尽管并不理想)是将包含非托管依赖项的文件夹添加到 PATH 环境变量,然后使用该 PATH 启动 DevEnv.exe

您可以通过以下方式执行此操作:

  • 使用“计算机”->“将文件夹添加到系统环境变量”属性
  • 使用设置路径然后启动 DevEnv 的批处理文件

此解决方案的问题是,当重新构建非托管依赖项时,Visual Studio 往往会“挂起”它们或不使用新的依赖项,因此您最终需要退出并重新构建非托管依赖项。使用设计器正确地完全重建所有内容后重新启动 Visual Studio,这可能有点痛苦。

Because the Visual Studio designer copies your assemblies to a temporary location, but doesn't copy your unmanaged dependencies, you can run into this problem.

The simplest solution, although not ideal, is to add a folder that contains your unmanaged dependencies to the PATH environment variable, and then start DevEnv.exe with that PATH.

You can do this either by:

  • Adding the folder to the System environment variables using Computer -> Properties
  • Using a batch file that sets the path and then starts DevEnv

The problem with this solution is that as the unmanaged dependencies are rebuilt Visual Studio tends to "hang onto" them or not use the new ones and so you end up needing to exit and restart Visual Studio after using the designer to properly totally rebuild everything and this can be a bit of a pain.

冬天旳寂寞 2024-11-14 16:45:54

这不是一个真正的解决方案,但有时它会有所帮助:使用“AnyCPU”(不是“x64”,因为设计器是 32 位进程)进行重建,并在“发布”模式下,关闭并重新打开 Visual Studio。而且,是的:这非常烦人......

Not a real solution, but sometimes it helps: rebuild using "AnyCPU" (not "x64", because the designer is a 32bit process) and in "Release" mode, close and re-open Visual Studio. And, yes: this is very annoying...

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