Réglage de l'interface personnalisée écrite dans C ++ / CLI à NULL peut causer un programme de programme

Question

J'ai une interface personnalisée .NET écrite en C ++ / CLI:

public interface class IBackgroundExtractor
{
};

Dans mon application C #, l'interface est utilisée par:

private IBackgroundExtractor extractor = null;

Le code ci-dessus s'exécute en douceur dans mon ordinateur (qui a installé Visual Studio) mais il s'est écrasé dans un autre (sans installer Visual Studio):

AppName: speedtest.exe   AppVer: 1.0.0.0     ModName: kernel32.dll
ModVer: 5.1.2600.5512    Offset: 00012aeb

Si je supprimais la mission nulle, le code s'exécutera dans les deux ordinateurs:

private IBackgroundExtractor extractor;

Cependant, j'ai fait une autre interface dans Pure C #. Réglage de l'interface sur NULL ne fera pas le programme de crash:

interface IAnotherInterface
{
}
private IAnotherInterface test = null;

Qu'est-ce qui ne va pas dans mon interface C ++ / CLI?

[remarques]

J'ai créé deux nouveaux projets "propres" pour tester, la première est une bibliothèque de classe C ++ / CLI (nouveau projet -> Visual C ++ -> CLR -> Bibliothèque de classe). Ajoutez les lignes suivantes dans le fichier .h de la bibliothèque:

public interface class ITest {
};

Créez ensuite un projet d'application Formulaire Windows (Projet net -> Visual C # -> Windows -> Formulaires Windows) et déclare une variable itest dans la fonction principale:

static void Main()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new Form1());

    ITest xxx = null;
}

Le programme s'exécutera dans l'ordinateur de développement (installé Visual Studio) mais se bloque dans deux autres ordinateurs. L'un des ordinateurs crashs est la machine physique et l'autre est une machine virtuelle.

J'utilise Windows XP Pro SP3, Visual Studio 2010 et .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.