设置用C ++ / CLI编写的自定义接口为null可能会导致程序崩溃

Question

我有一个在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

.

如果我删除null分配，则代码将在计算机中运行：

private IBackgroundExtractor extractor;

. 但是，我在纯C＃中进行了另一个接口。将接口设置为null不会使程序崩溃：

interface IAnotherInterface
{
}
private IAnotherInterface test = null;

.

我的C ++ / CLI接口有什么问题？

[备注]

我创建了两个'Clean'的测试项目，是第一个是C ++ / CLI类库（新项目 - > Visual C ++ - > CLR - >类库）。将以下行添加到库的.h文件中：

public interface class ITest {
};

. 然后

然后创建一个Windows表单应用程序项目（NET项目 - > Visual C＃ - > Windows - > Windows窗体应用程序）并在主要功能中声明一个IT最令人瞩目：

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。

Answer 1

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

Answer 2

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.