将 C++/CLI 编写的自定义接口设置为 null 可能会导致程序崩溃
我有一个用 C++/CLI 编写的自定义 .Net 接口:
public interface class IBackgroundExtractor
{
};
在我的 C# 应用程序中,该接口的用途是:
private IBackgroundExtractor extractor = null;
上面的代码在我的计算机(安装了 Visual Studio)中运行顺利,但在另一台计算机(未安装 Visual Studio)中崩溃了:
AppName: speedtest.exe AppVer: 1.0.0.0 ModName: kernel32.dll
ModVer: 5.1.2600.5512 Offset: 00012aeb
如果我删除空分配,代码将在两台计算机上运行:
private IBackgroundExtractor extractor;
但是,我用纯 C# 制作了另一个界面。将接口设置为 null 不会使程序崩溃:
interface IAnotherInterface
{
}
private IAnotherInterface test = null;
我的 C++/CLI 接口出了什么问题?
[备注]
我创建了两个“干净”的新项目用于测试,第一个是 C++/CLI 类库(新项目 -> Visual C++ -> CLR -> 类库)。将以下行添加到库的 .h 文件中:
public interface class ITest {
};
然后创建一个 Windows 窗体应用程序项目(Net Project -> Visual C# -> Windows -> Windows Forms Application)并在 main 函数中声明一个 ITest 变量
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
ITest xxx = null;
}
:程序将在开发计算机(安装了 Visual Studio)中运行,但在另外两台计算机中崩溃。崩溃的计算机其中一台是物理机,另一台是虚拟机。
我使用的是 Windows XP Pro SP3、Visual Studio 2010 和 .Net Framework 4.0。
I have a custom .Net interface written in C++/CLI:
public interface class IBackgroundExtractor
{
};
In my C# application, the interface is used by:
private IBackgroundExtractor extractor = null;
The above code runs smoothly in my computer (which installed visual studio) but it crashed in another one (without installing visual studio):
AppName: speedtest.exe AppVer: 1.0.0.0 ModName: kernel32.dll
ModVer: 5.1.2600.5512 Offset: 00012aeb
If I remove the null assignment, the code will run in both computer:
private IBackgroundExtractor extractor;
However, I made another interface in pure C#. Setting the interface to null will not make the program to crash:
interface IAnotherInterface
{
}
private IAnotherInterface test = null;
What's wrong in my C++/CLI interface?
[Remarks]
I've create two 'clean' new projects for testing, the first one is a C++/CLI Class Library (New Project -> Visual C++ -> CLR -> Class Library). Add the following lines into the .h file of the library:
public interface class ITest {
};
Then create a Windows Form Application project (Net Project -> Visual C# -> Windows -> Windows Forms Application) and declares an ITest variable in the main function:
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
ITest xxx = null;
}
The program will run in the development computer (installed visual studio) but crash in two other computers. One of the crashed computers is physical machine and the other one is an virtual machine.
I am using Windows XP Pro SP3, Visual Studio 2010 and .Net Framework 4.0.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您是否检查过以确保目标计算机上安装了正确版本的 Microsoft Visual C++ Runtime? (您的开发环境已安装此程序,但当前版本的 Windows 默认情况下不包含此运行时)。
如果您将 C++/CLI 项目设置为使用“SAFE”模式,则它根本不会引用 Microsoft Visual c++ 运行时(仅引用 .NET)。请参阅此参考:纯粹且可验证的代码。如果您需要执行本机操作,那么您很有可能需要安装最新的 Visual C++ 运行时。您可以在此处获取可再发行组件: Microsoft Visual C++ 2010 可再发行组件包。
如果您想验证是否是这个问题,可以使用
sxstrace
工具来诊断这些问题(有用的教程)。Have you checked to make sure the right version of the Microsoft Visual C++ Runtime is installed on the target machines? (Your development environment will already have this installed, but no current version of Windows includes this runtime by default).
If you set up your C++/CLI project to use "SAFE" mode, it will not reference the Microsoft Visual c++ runtime at all (just .NET). See this for reference: Pure and Verifiable Code. If you need to do native stuff, then there's a very high chance that you need to have the latest Visual C++ runtime installed. You can pick up the redistributable here: Microsoft Visual C++ 2010 Redistributable Package.
If you want to verify that this is the problem, you can use the
sxstrace
tool to diagnose these issues (helpful tutorial).空分配可能不是错误,而是错误的触发因素。对 null 的赋值可能是访问 C++/CLI 程序集的第一行代码。因此,在执行 null 分配之前,C++/CLI 程序集的非托管部分已初始化。这可能就是发生错误的地方。
The null assigment is probably not the error but the trigger for the error. This assigment to null is probably first line of code that accesses that the C++/CLI assembly. So before the that null assigment is even executed, the unmanaged part of C++/CLI assembly is initialized. That is probably where the error is occuring.