error C1191: 'mscorlib.dll' can only be imported at global scope

Question

Programmation sous VC++2010 WinForm .Net Framework 4.0

Bonjour, je me retrouve coincé dans mon code à cause de cette erreur populaire. Le problème est que je n'appelle pas moi-même le "#using <mscorlib.dll>".

L'importation est appelée par un fichier système. 

Solution MSDN :

/* Remplacer */

namespace sample {
   #using <mscorlib.dll>   // C1191 not at global scope
}

/* Par */

#using <mscorlib.dll>
namespace sample {}

Je ne me vois pas modifier un fichier système et de plus je n'y retrouve pas ce cas :

#if _MSC_VER > 1000
#pragma once
#endif

#if !defined(_INC_VCCLR)
#define _INC_VCCLR
#ifndef RC_INVOKED

#using <mscorlib.dll>

#include <gcroot.h>

#pragma warning(push)
#pragma warning(disable:4400)

Je ne connais pas le /clr, je ne vois donc pas comment contourner le problème.

Merci à toute aide proposée.

Answer 1

/clr correspond à l'utilisation du C++/CLI.

Il ne faut pas contourner le problème mais le résoudre.

Je pense que vous avez une constante de compilation qui pose problème.

Utilisez l'option /P du compilateur pour savoir pourquoi vous passez par la ligne #using, et donc connaître la constante de compilation qui vous fait prendre les instructions C++/CLI.

Je pense que vous avez le problème dans vcclt.h, vous ne devez pas inclure ce .h dans un projet C++ non managé.

 

Si vous "includez" directement ce .h, c'est une erreur sinon, il faut déterminer, avec l'option /P, pourquoi il est inclus.

---

Paul Bacelar, Ex - MVP VC++

Answer 2

J'ai fait du coup quelques recherches sur msdn:

"L'option /P supprime la compilation. Elle ne produit pas un fichier .obj, même si vous utilisez /Fo (Nom de fichier objet)."

Du coup, ma "compilation" se déroule normalement puis j'obtiens une belle LINK: Fatal Error:

1>LINK : fatal error LNK1104: cannot open file 'Debug\BDD.obj'

Mais cela veut-il dire que le problème viens de ma classe BDD, d'une mauvaise utilisation ou déclaration?

Ou alors l'erreur arrive par hasard et je dois creuser? 

PS: Le problème était détecté dans vcclr.h, mais en mettant en commentaire je la retrouvais dans d'autre fichier, probablement vcclt.h.

Answer 3

Le comportement que vous décrivez est complétement normal. ;-)

L'option /P n'est pas une option "miracle".

Elle "stoppe" la compilation en fin de l'étape du pré-processing : "résolution" des includes et expansion en ligne des MACRO.

Vous obtenez, avec cette option, un fichier .i pour chaque .cpp ou .c où l'option est appliquée, contenant ce que le compilateur recevrait en cas de compilation complète.

Dans ce fichier .i, il y a les indications qui justifient le fait qu'un include a été "suivi". Vous saurez donc quelles constantes de compilation vous à conduit à inclure "vcclr.h".

L'include de "vcclr.h" n'est valide qu'en cas de projet C++/CLI, jamais dans le cas d'un projet purement natif.

Sauf énorme boulet dans les .h, je ne vois que deux explications, constantes de compilation fantaisistes ou utilisation de librairies/framework .NET, donc utilisable qu'en environnement managé.

Il faut donc que vous regardiez le contenu de BDD.i pour voir pourquoi vous incluez ce vcclr.h.

---

Paul Bacelar, Ex - MVP VC++