J'ai trouvé dans "Projet -> Propriété -> Général -> Ensemble d'outils de plateforme" : Visual Studio 2017 (v141).

Donc il le supporte. Super

-
Edité par VincentL10 5 mars 2021 à 15:40:25

Oui.

Ces "détails" de configuration doivent bien être mis quelque part, dans une documentation, etc...

C'est le genre d'emmerde que pose les export à la C++ et que j'essayais d'éviter avec mes questions précédentes.

Pour MD :

https://docs.microsoft.com/fr-fr/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-160

Pouvez-vous vérifier que votre projet utilise /MD ?

Comment puis-je vérifier cela ? (Je vais chercher en parallèle)

https://stackoverflow.com/questions/19487465/how-to-tell-if-a-lib-was-compiled-with-mt-or-md

Bonjour,

Veuillez m'excuser de cette longue période sans réponse. Ma charge de travail du mois dernier, était plus important que prévus, m'empêchant d'avancer.

Je suis passer par dumpbin /directives, mais j'obtiens juste le sommaire:

Summary:

               C6 .debug$S

               14 .idata$2

               14 .idata$3

                 8 .idata$4

                 8 .idata$5

                 E .idata$6

Quand je rajoute "| find /i "lib", il me rajoute: File Type: LIBRARY, le msvcr, libcmt et msvr... ne fait rien.

-
Edité par VincentL10 6 avril 2021 à 11:00:03

Super, réglage incohérent selon les .obj et .lib qui ont servi à l'édition de lien, le niveau d'amateurisme monte encore d'un niveau.

Pouvez-vous vérifier que votre projet utilise /MD ? (BIS)

Pour savoir si vous compilez avec des options compatible avec le .lib :

"Propriétés du projet -> C/C++ -> Génération de code -> Bibliothèque Runtime", elle doit être à "DLL multithread (/MD)".

Adieu une version Debug simple à utiliser.

-
Edité par bacelar 6 avril 2021 à 19:48:36

Visual studio est bien en Dll de débogage multithread (/MDd).

Si le projet correspond, entre autres, aux fichiers du fournisseur, la seul chose qui indique MD ce trouve dans leur nom. (Exemple : Log_MD_VC....lib), par Dumpin le /DEFAULTLIB ne s'affiche pas.

-
Edité par VincentL10 6 avril 2021 à 16:39:44

Ce n'est pas "Visual Studio" qui est en "Dll de débogage multithread (/MDd)", c'est un projet.

Chaque projet peut avoir un réglage différent sur ce sujet.

De plus, c'est "MD" et non "MDd" qu'il faut choisir.

Ce sont des C-Runtime différentes, et comme l'API ne semble pas étanche d'un point de vue mémoire, vous êtes "baisé". Même dans une configuration Debug, vous devez utiliser une C-Runtime Release, vous pouvez dire merci à votre fournisseur, ou gueuler pour qu'ils vous fournissent une version MDd et pas qu'une version MD toute miteuse.

>MD ce trouve dans leur nom

Non, Dumpbin fait correctement son travail et vous avez mal lu les réponses (mais c'est vrai que pas mal de commentaire aux réponses sont un peu à côté de la plaque). Il ne faut pas confondre Dumpbin et "strings.exe".

Après relecture, effectivement, même les réponses font un peu l'amalgame, et ce que vous pensiez voir de manière si explicite : "/DEFAULTLIB" n'est possible qu'avec certains réglages spécifiques, que votre fournisseur n'a pas déniés suivre.

Dumpbin montre que la gestion de la C-Runtime est très vraisemblablement aux fraises et que vous devrez serrer les fesses pour que cela ne vous pète pas à la gueule.

Même si on peut avoir des doutes sur la qualité des développement ; ou plus probablement sur le professionnalisme du collègue qui vous a refourgué ce bâton merdeux (ce projet) en vous donnant bien trop peu d'information et très vraisemblablement des trucs fait sur un coin de table après un repas d'affaire bien trop arrosée, sans rien comprendre au bidule. Il faut pas les prendre pour des psychopathes, s'ils suivent une règle de nommage cohérente, c'est très probablement ce qu'ils ont tenté de faire (ou fait réellement, car sans les sources (configuration des projets comprises), je ne fais que des conjectures).

Donc, en résumé, sélectionnez la bonne option de "Bibliothèque Runtime" (/MD) dans le projet du wrapper, ajoutez le bon .lib à la liste des .lib que l'éditeur de lien devra prendre en compte, DANS LE PROJET du WRAPPER, ajoutez un nouveau fichier .cpp DANS LE PROJET du WRAPPER, faites y un "#include" du fichier d'en-tête contenant l'une des primitives qui vous seront nécessaire, et ajoutez dans ce même fichier .cpp un appel à cette primitives.

On verra après ce que donnent comme erreur/warning la compilation et l'édition de lien de la Dll du projet du wrapper.

J'ai réglé la bibliothèque runtime en MD sur une application console C++ (pour faire des essais) et j'y est inclus une librairie. (J'ai essayé de prendre la plus simple)

#include <iostream>
#include "_GCVersion.h"

using namespace std;

int main()
{
	int a = GC_VERSION_MAJOR;
	int b = GC_VERSION_MINOR;
	int d = GC_SVN_REVISION;

	cout << "MajorVersion = " << a << endl;
	cout << "MinorVersion = " << b << endl;
	cout << "SVN Revision = " << d << endl;
}

En espérant, avoir compris ce que vous demandiez.

Est-ce que si j'arrive a trouver la librairie qui importe les dll, est ce que je pourrais les exploiter en C# après avoir wrapper la librairie concernée ? 

-
Edité par VincentL10 7 avril 2021 à 9:30:04

>J'ai réglé la bibliothèque runtime en MD sur une application console C++ (pour faire des essais)

Très bien

>et j'y est inclus une librairie. (J'ai essayé de prendre la plus simple)

Qu'entendez-vous précisément pas "inclure", SVP ?

Inclure une librairie, c'est, à minima:

1 - ajouter le répertoire contenant le ou les fichiers d'en-tête (.h ou .hpp) de la librairie dans la liste des répertoires d'en-tête du projet. Préférez n'utiliser que la racine des répertoires contenant des fichiers d'en-tête de la librairie s'ils sont (les fichiers d'en-tête) répartis dans une arborescence de répertoires. (Cela rendre le point 2, ci-après plus "propre").

"Propriétés du projet -> Répertoires VC++ -> Répertoires Include ", elle doit contenir le ou les chemins vers le ou les répertoires contenant les fichiers d'en-tête de la librairie.

2 - ajouter un '#include<...>' et non un '#include"..."' car ce n'est pas un include "local" (ça peut fonctionner avec des guillemets mais c'est pas optimal en terme de performance et cela peut poser des problèmes en cas d'architecture d'inclusion complexe, autant ne pas chercher les emmerdes). Si vous n'avez bien enregistré que la racine des répertoires contenant les fichiers d'en-tête (.h ou .hpp) de la librairie, au point 1, pensez à bien spécifier le chemin entre la racine et le répertoire contenant effectivement le fichier d'en-tête dans le #include.

3- ajouter le répertoire contenant le ou les fichiers .lib (librairie statique de Dll sic!) de la librairie dans la liste des répertoires de bibliothèques du projet.

"Propriétés du projet -> Répertoires VC++ -> Répertoires de bibliothèques", elle doit contenir le ou les chemins vers le ou les répertoires contenant les fichiers .lib de la librairie.

4- ajouter le nom du ou des fichiers .lib qui contiennent l'implémentation (juste un appel à une primitive dans la Dll, en fait) dans "Propriétés du projet -> Éditeur de liens -> entrée -> Dépendances supplémentaires".

Il faut faire, au minimum, ces 4 actions pour utiliser "simplement" une librairie.

A la tête des appels dans votre code, il y a des chances que ces primitives "GC_...." ne soient que des MACRO et qu'elles ne soient qu'"header_only". C'est à dire qu'elles n'utilisent pas de .lib et que toute l'implémentation soit dans le .h. C'est un cas très "dégénéré" et donc peu pertinent pour vérifier que votre configuration de projet est "d'équerre". De plus, un fichier d'en-tête commençant pat un "_" a peu de chances d'être un fichier d'en-tête "public" : les rares fichiers d'en-tête qu'un utilisateur de la librairie est sensé inclure dans son code (cf. RTFM). Très souvent, il n'y a qu'un seul fichier d'en-tête "public" ayant comme nom : le nom de la librairie/"projet de la librairie" (voir un fichier d'en-tête "public" par module indépendant, pour les gros bibliothèques).

J'espère que le terme "GC" dans "votre code/code de la librairie" n'a rien à voir avec "Garbage Collection", car, sinon, on sera fasse à des gros problèmes.

Si vous avez fait correctement les 2 premières étapes de "l'inclusion d'une librairie" et que le fichier d'en-tête que vous utilisez n'est pas trop dépendant des autres fichiers d'en-tête (c'est le risque de ne pas prendre un fichier d'en-tête "public"), le code qui été posté devrait compiler, être "linké" et générer un exécutable qui affichera les informations.

>En espérant, avoir compris ce que vous demandiez.

Oui ! Mais vous manquez un peu de "réflexes" Cplusplussiens. 

>est ce que je pourrais les exploiter en C# après avoir wrapper la librairie concernée ?

Oui oui, c'est l'objectif. Et avec des wrappers C++/CLI, vous avez le plus d'outils possibles pour contrer des problèmes de compatibilité qui pourraient apparaître lors de l'utilisation de la librairie native.

P.S.: Dégagez moi cet horrible "using namespace std;" de votre code, qui n'avait un sens qu'avec du code plus vieux que le premier standard du C++ (1998, donc depuis 23 ans bordel!)

J'ai réussis à faire un wrapper sur un fichier .h fourni (Version majeur, mineur, submineur) et réussis à les ressortir.

Le seul inconvénient que je rencontre est que je dois appeler les valeurs de la librairie une part une.

J'ai créé 2 programmes, un .cpp  (avec son .h) et un .cs.

https://drthitirat.wordpress.com/2013/06/03/use-c-codes-in-a-c-project-wrapping-native-c-with-a-managed-clr-wrapper/

Je me suis appuyer sur la vidéo de ce lien pour le faire et l'ai adapté à mon besoin. (J'ai remplacé son premier programme avec le header, body et main pour la librairie donnée.)

-
Edité par VincentL10 7 avril 2021 à 13:57:47

>J'ai réussis à faire un wrapper sur un fichier .h fourni (Version majeur, mineur, submineur) et réussis à les ressortir.

Comme déjà indiqué, c'est un usage un peu "dégénéré" si c'est des MACRO.

Cela permet de vérifier que les 2 premiers points sont OK (sur 4).

>Le seul inconvénient que je rencontre est que je dois appeler les valeurs de la librairie une part une.

Si c'est bien des MACRO, ce n'est même pas des "appels" qui sont réalisés, c'est juste le pré-processeur qui fera le remplacement au moment de la pré-compilation (et pas à l'exécution). Donc aucun usage de la Dll à l'exécution ou même du .lib au moment de l'édition de lien.

Donc, si vous récupérez une nouvelle version de la Dll mais que vous ne recompilez pas votre application avec les nouveaux .h + .lib, vous aurez toujours les anciennes valeurs, même en utilisant la nouvelle Dll (si elle est encore rétro-compatible, sinon, crash aléatoire).

>J'ai créé 2 programmes

Vous voulez dire 2 projets, non ? Un en C++/CLI contenant un .cpp (avec éventuellement un ou des .h ) et un autre projet C#/.NET contenant un .cs, non ?

L'exemple me semble assez complet et le fait de remplacer "son premier programme"(projet?) par l'usage direct du ou des .h de la bibliothèque ainsi que du .lib de la bibliothèque dans le "second projet" est très pertinent.

Mais pensez à tester le wrapping de chose plus pertinent que ces numéro de version qui peuvent ne pas valider complètement la bonne "importation de la librairie" dans le projet C++/CLI de wrapping.

Oui, deux projets. Et il s'agit d'une bibliothèque de classe CLR et d'une application console (.NET Framework), avec un .cs pour le C#.

J'ai essayé quelque chose de simple pour comprendre le wrapping, seule la variable du "MAIN_COMPILER" qui a pour valeur VC141, me procure une erreur (C4700), qui indique une variable non initialisée.

Le reste des .h/.hh sont des codes. J'essaye de voir comment les exploiter.

-
Edité par VincentL10 7 avril 2021 à 16:09:26

Je vous ai déjà signalé que ces valeurs "simples" sont des nids à problème et qu'elles n'ont pas été, très certainement, faites pour être lues depuis l'extérieur de la librairie.

Le Warning "C4700" est un des warnings caractéristiques de l'utilisation de headers qui n'ont pas à être utilisés directement.

Si la librairie n'est pas très grosse et qu'elle est correctement conçue, il n'y a qu'un fichier d'en-tête à inclure pour dispose de toutes les fonctionnalités "publiques" de la librairie.

C'est cet en-tête "chapeau" qui est responsable de l'ordre des inclusions des autres .h/.tlp/.inc/etc... et donc de ne pas "froisser" le compilateur et ces "C4700" (qui sont là pour évitiez de faire des conneries).

Montrez un de ces "codes", qu'on fasse rapidement un POC.

#ifndef _INCLUDE_LOG4CPP_CONFIG_H
#define _INCLUDE_LOG4CPP_CONFIG_H 1
 
/* include/log4cpp/config.h. Generated automatically at end of configure. */
/* include/config.h.  Generated from config.h.in by configure.  */
/* include/config.h.in.  Generated from configure.in by autoheader.  */

/* Define to 1 if you have the <dlfcn.h> header file. */
#ifndef LOG4CPP_HAVE_DLFCN_H 
#define LOG4CPP_HAVE_DLFCN_H  1 
#endif

/* Define to 1 if you have the `ftime' function. */
#if !defined(LOG4CPP_HAVE_FTIME) && !defined(VXWORKS)
#define LOG4CPP_HAVE_FTIME  1
#endif

/* Define to 1 if you have the `gettimeofday' function. */
#if !defined(LOG4CPP_HAVE_GETTIMEOFDAY) && !defined(VXWORKS)
#define LOG4CPP_HAVE_GETTIMEOFDAY  1
#endif

/* define if the compiler has int64_t */
#ifndef LOG4CPP_HAVE_INT64_T 
#define LOG4CPP_HAVE_INT64_T   
#endif

/* Define to 1 if you have the <inttypes.h> header file. */
#ifndef LOG4CPP_HAVE_INTTYPES_H 
#define LOG4CPP_HAVE_INTTYPES_H  1 
#endif

/* Define to 1 if you have the <io.h> header file. */
/* #undef LOG4CPP_HAVE_IO_H */

/* Define to 1 if you have the `idsa' library (-lidsa). */
/* #undef LOG4CPP_HAVE_LIBIDSA */

/* Define to 1 if you have the `localtime_r' function. */
#ifndef LOG4CPP_HAVE_LOCALTIME_R 
#define LOG4CPP_HAVE_LOCALTIME_R  1 
#endif

/* Define to 1 if you have the <memory.h> header file. */
#ifndef LOG4CPP_HAVE_MEMORY_H 
#define LOG4CPP_HAVE_MEMORY_H  1 
#endif

/* define if the compiler implements namespaces */
#ifndef LOG4CPP_HAVE_NAMESPACES 
#define LOG4CPP_HAVE_NAMESPACES   
#endif

/* Define if you have POSIX threads libraries and header files. */
#ifndef LOG4CPP_HAVE_PTHREAD 
#define LOG4CPP_HAVE_PTHREAD  1 
#endif

/* define if the C library has snprintf */
#ifndef LOG4CPP_HAVE_SNPRINTF 
#define LOG4CPP_HAVE_SNPRINTF   
#endif

/* define if the compiler has stringstream */
#ifndef LOG4CPP_HAVE_SSTREAM 
#define LOG4CPP_HAVE_SSTREAM   
#endif

/* define if you have the <stdint.h> header file. */
#ifndef LOG4CPP_HAVE_STDINT_H 
#define LOG4CPP_HAVE_STDINT_H   
#endif

/* Define to 1 if you have the <stdlib.h> header file. */
#ifndef LOG4CPP_HAVE_STDLIB_H 
#define LOG4CPP_HAVE_STDLIB_H  1 
#endif

/* Define to 1 if you have the <strings.h> header file. */
#ifndef LOG4CPP_HAVE_STRINGS_H 
#define LOG4CPP_HAVE_STRINGS_H  1 
#endif

/* Define to 1 if you have the <string.h> header file. */
#ifndef LOG4CPP_HAVE_STRING_H 
#define LOG4CPP_HAVE_STRING_H  1 
#endif

/* Define to 1 if you have the `syslog' function. */
#if !defined(LOG4CPP_HAVE_SYSLOG) && !defined(VXWORKS)
#define LOG4CPP_HAVE_SYSLOG  1
#endif

/* Define to 1 if you have the <sys/stat.h> header file. */
#ifndef LOG4CPP_HAVE_SYS_STAT_H 
#define LOG4CPP_HAVE_SYS_STAT_H  1 
#endif

/* Define to 1 if you have the <sys/types.h> header file. */
#ifndef LOG4CPP_HAVE_SYS_TYPES_H 
#define LOG4CPP_HAVE_SYS_TYPES_H  1 
#endif

/* define if threading is enabled */
#ifndef LOG4CPP_HAVE_THREADING 
#define LOG4CPP_HAVE_THREADING  1 
#endif

/* Define to 1 if you have the <unistd.h> header file. */
#ifndef LOG4CPP_HAVE_UNISTD_H 
#define LOG4CPP_HAVE_UNISTD_H  1 
#endif

/* Name of package */
#ifndef LOG4CPP_PACKAGE 
#define LOG4CPP_PACKAGE  "log4cpp" 
#endif

/* Define to the address where bug reports for this package should be sent. */
#ifndef LOG4CPP_PACKAGE_BUGREPORT 
#define LOG4CPP_PACKAGE_BUGREPORT  "" 
#endif

/* Define to the full name of this package. */
#ifndef LOG4CPP_PACKAGE_NAME 
#define LOG4CPP_PACKAGE_NAME  "log4cpp" 
#endif

/* Define to the full name and version of this package. */
#ifndef LOG4CPP_PACKAGE_STRING 
#define LOG4CPP_PACKAGE_STRING  "log4cpp 1.0" 
#endif

/* Define to the one symbol short name of this package. */
#ifndef LOG4CPP_PACKAGE_TARNAME 
#define LOG4CPP_PACKAGE_TARNAME  "log4cpp" 
#endif

/* Define to the version of this package. */
#ifndef LOG4CPP_PACKAGE_VERSION 
#define LOG4CPP_PACKAGE_VERSION  "1.0" 
#endif

/* Define to necessary symbol if this constant uses a non-standard name on
   your system. */
/* #undef LOG4CPP_PTHREAD_CREATE_JOINABLE */

/* Define to 1 if you have the ANSI C header files. */
#ifndef LOG4CPP_STDC_HEADERS 
#define LOG4CPP_STDC_HEADERS  1 
#endif

/* define if pthread library is available */
#ifndef LOG4CPP_USE_PTHREADS 
#define LOG4CPP_USE_PTHREADS  1 
#endif

/* Version number of package */
#ifndef LOG4CPP_VERSION 
#define LOG4CPP_VERSION  "1.0" 
#endif
 
/* _INCLUDE_LOG4CPP_CONFIG_H */
#endif

Voici un des code (.h) fourni

Ce truc, c'est de la popote interne à la librairie, vous n'avez pas à rendre ces machins disponibles hors de la librairie.

Je le répète, focalisez vous sur le ou les headers "public".

Peut-être que je vais vous faire répétez (veuillez m'en excusez), qu'est ce qui caractérise un header "public" ?

En ajoutant toutes les librairies (173), j'ai obtenu 271 erreurs (problème de chemin, juste long a tout résoudre).

Généralement, c'est qu'il est à la racine des répertoires contenant les header et à pour nom de fichier : "le nom de la librairie".h. (voir dans un répertoire "public" si ceux qui vous ont fourni les bidules ont fait ça comme des porcs).

(Et la documentation, c'est pas fait pour la décoration)

Un .h, c'est un fichier d'en-tête, PAS UNE "LIBRAIRIE", bordel.

Les problèmes de "chemin", comme je l'ai déjà signalé, c'est très probablement que vous essayez d'inclure des fichiers d'en-tête qui n'ont pas vocation à être directement inclus dans le code client mais uniquement via le ou les headers "public".

Ca marche, je ne sais plus si on cela a déjà été évoqué. Les fichiers .hh, à quoi correspondent-elles ?

Est- ce que les inclurent dans le dossiers d'en-tête est une erreur ?

A oui, et en modifiant les chemin des #includes, je suis tombé sur certains où "Header" est mentionné.

-
Edité par VincentL10 8 avril 2021 à 10:41:48

>Les fichiers .hh, à quoi correspondent-elles ?

C'est juste une convention pour ne pas confondre les header censés être utilisés uniquement lors de compilation C++ et non lors d'une compilation C, mais c'est juste une convention.

https://stackoverflow.com/questions/10354321/c-reason-why-using-hh-as-extension-for-c-header-files

>Est- ce que les inclurent dans le dossiers d'en-tête est une erreur ?

Non, ce qui est une erreur, c'est d'inclure des header "non public", qui ne sont pas censés être directement utilisés par le code "client".(BIS-TER-...  )

>A oui, et en modifiant les chemin des #includes,

Heu, j'espère qu'on ne parle que de votre code et pas des .h fournis ? J'espère.

On en revient toujours au même, si vous utilisez que le ou les headers "public", vous ne devriez pas avoir de véritable chemin dans le ou les #include, car il ou ils devraient être à la racine de l'arborescence des headers de la bibliothèque.

C'est pas parce qu'inclure un .h donne accès à des centaines de classes que vous devez toutes les wrapper.

J'ai tous recommencer en créant un nouveau projet dans le dossier avec toutes les headers (.dll et autre). Ce qui fait que les seules modifications à apporter sont celles de mon projet.

Pour essayer de mieux comprendre, j'ai tous réunis dans un seul et même dossier.

J'espère, à ne pas devoir tous les wrapper, mais la plus grosse partie dépendent des un et des autres.

-
Edité par VincentL10 8 avril 2021 à 12:33:18

Vous avez donc fait une grosse erreur.

Vous ne devez pas modifier ces .h.

C'est votre configuration de projet qui doit s'adapter et pas "adapter" les fichiers.

La manière de faire concrètement est fonction de comment votre société gère les dépendances externes (dépôt Maven commun, des repositories dédiés, etc...)

Vous ne devez surtout pas changer l'arborescence de répertoire des fichiers.

Revenez aux versions "originales", arborescence de fichiers comprise.

Si vous voulez tous avoir dans votre arborescence de projet, copiez tous (les includes, les lib etc...) dans un sous répertoire de votre projet en donnant au répertoire le nom de la librairie. Mais vous ne devez pas changer arborescence de fichier initiale.

Vous n'aurez ensuite qu'à faire correctement les 4 points déjà mentionnés ici:

https://openclassrooms.com/forum/sujet/probleme-de-dll?page=2#message-94057982

Et pour faire cela correctement, vous devez avoir déterminé où est ou sont le ou les headers "public".

Si vous galérez à déterminer ce ou ces headers "public", donnez-nous le nom de votre librairie et la liste des noms de fichiers d'en-tête à la racine du répertoire les contenant.

EDIT : Ne modifiez pas vos message, éditez les via des "EDIT :", sinon cela devient incompréhensible pour les éventuels autres lecteurs, SVP.

-
Edité par bacelar 8 avril 2021 à 12:38:45

Quelles sont les conditions pour utiliser le #include<> ?

Aucune, la seul différence entre #include<...> et #include"...", c'est que le second essaye de trouver le fichier de l'en-tête en commençant par le répertoire qui contient le fichier "qui fait l'include". Le premier ne regarde qu'a partir de la liste des répertoires que vous lui avez donné dans la configuration du projet. Le second ne regarde cette liste qu'après une recherche infructueuse de "à partir du fichier 'qui fait l'include'".

Donc, vous devez mettre la racine des header de la librairie dans la liste des répertoires d'en-tête du projet et faire un "#include<leNomDuFichierDEnTetePublicDeLaBibliotheque>". Si le fichier d'en-tête public est à la racine des répertoires contenant les header de la librairie, vous n'aurez pas besoin de spécifier le moindre chemin.

Dans mon dossier, j'ai deux projet, l'application console C# (nommé "Program") et la bibliothèque CLR (nommé "WrapperCpp").

Mon programme CLR a été placé dans (pour réduire les chemin, tout en gardant tout les chemin possible pour les accès):

Learning_Wrapper/WrapperCpp/WrapperCpp

Le chemin aux headers donne:

Learning_Wrapper/WrapperCpp/WrapperCpp/library/include

Dans le dossier /include, je possède 4 .h, ensuite il s'agit d'autres dossiers pour d'autres .h/.hh.

Quand j'essaye avec les crochets (<>), il me mets en erreur les chemin en émettant l'erreur:

E1696 : impossible d'ouvrir le ficher source

En revanche avec les guillemets ("") cela fonctionne. Mais j'obtiens toujours la même erreur sur les fichiers que j'appelle, car eux-mêmes en appelle d'autres.

Je suis passé par l'explorateur de solution, j'ai clic-droit sur "fichiers d'en-tête, cliqué sur ajouter, "Élément existant" et sélectionner les premières. Lorsque j'essaye de le mettre dans l'#include (<>), il ne le trouve pas.

Je pense avoir loupé un quelque chose qui m'échappe.

>Dans mon dossier

???

Dans votre solution Visual Studio, vous voulez dire ?

>Mon programme CLR a été placé

Qu'entendez-vous par "programme" ???

Le résultat de la compilation (qui est un assembly donc un .dll) ? (pour le wrapper)

Le fichier projet Visual Studio ?

Le répertoire contenant les sources de ce projet ?

>pour réduire les chemin

Ok, mais alors pourquoi avoir "WrapperCpp" répété inutilement ???

>/WrapperCpp/library/include

Avec un chemin pareil, vous allez être potentiellement bloqué dès la seconde librairie, et ça vient vite en C++.

Essayez plutôt :

Learning_Wrapper/WrapperCpp/libraries/{le_nom_de_la_bibliotheque}/include

Il faudra juste corriger quelques éléments de configuration, que vous n'avez toujours pas corrigé (ou pas fait correctement) aux vues des erreurs de compilation.
Learning_Wrapper : nom de la solution.

WrapperCpp: nom du projet C++/CLI.

>Dans le dossier /include, je possède 4 .h

Il est donc très probable que l'un de ces .h soit le fichier d'en-tête "public" de la librairie.

Donnez-nous le nom et les 50 à 100 première lignes de chacun de ces 4 fichiers .h, SVP. (et, si possible la liste des répertoires contenus dans "/include").

Qu'on voit un peu comment ce machin est architecturé.

>Quand j'essaye avec les crochets (<>), il me mets en erreur les chemin

Parce que vous n'avez pas correctement fait le point 1 de 

https://openclassrooms.com/forum/sujet/probleme-de-dll?page=2#message-94057982

Ou que vous incluez un fichier d'en-tête qui n'a pas été conçu pour être inclus dans le code client.

(Faudrait quand même commencer à écouter ce qu'on vous dit depuis un bon moment maintenance, non ? )

>En revanche avec les guillemets ("") cela fonctionne

Vous êtes juste en train de "blouser" le système archaïque d'include du C++, hérité du C des années 1970.

Ca va vous péter à la gueule. Suivez nos conseils et arrêtez de vous prendre des râteaux : inclure qu'un seul fichier d'en-tête, mais le bon, et correctement.

>car eux-mêmes en appelle d'autres.

Je crois que j'ai déjà répondu au moins 3 fois à cette interrogation avant ce post : Vous incluez des en-têtes qui n'ont pas à être inclus dans le code client (votre wrapper ici) et/ou que vous n'avez pas suivi (ou pas correctement) le point 1 de  ... vous devez savoir depuis le temps le chemin vers ce post.

>Je suis passé par l'explorateur de solution ...

En espérant que c'est bien juste une insertion de fichiers d'en-tête et pas d'autre chose (sinon, on n'est pas dans la merde), l'insertion de ce type de fichier n'a strictement aucun impact sur la chaîne de compilation (pré-processing (là où vous bloquez à force de ne pas nous écouter), la compilation ou encore l'édition de lien). Ajouter les en-têtes dans les fichiers d'un projet dans l'explorateur de solution n'a pour seule utilité que de faciliter leur recherche, quand on veut les modifier dans l'éditeur de fichier de Visual Studio. Chose que vous ne devriez JAMAIS faire pour des fichiers d'en-tête d'une bibliothèque.

>Lorsque j'essaye de le mettre dans l'#include (<>), il ne le trouve pas.

Normal, car cela n'a rien à voir avec la choucroute. Encore une fois, c'est le "point 1 ..." qu'il faut faire, rien d'autres.

>Je pense avoir loupé un quelque chose qui m'échappe.

Oui, clairement, à peu près tout ce qu'on vous indique depuis une demi-douzaine de posts réponses.

Bon, on va faire simple, vous nous le nom et les 50 à 100 première lignes de chacun de ces 4 fichiers .h (+ la liste des répertoires contenus dans /include, si possible) et on vous indiquera LA SEULE ET UNIQUE LIGNE de "include à ajouter à votre .cpp.

Et, en attendant, appliquez les points 1,2,3 ET 4, SVP !!!

> Qu'entendez-vous par "programme" ???

La bibliothèque CLR qui génère la dll.

>Ok, mais alors pourquoi avoir "WrapperCpp" répété inutilement ???

Cela s'est fait à la création du projet.

>Parce que vous n'avez pas correctement fait le point 1 de 

Si la liste du répertoire, n'est pas celle de l'explorateur de solution, laquelle est-ce ? (Désolé si la question peut paraitre bête)

>Oui, clairement, à peu près tout ce qu'on vous indique depuis une demi-douzaine de posts réponses.

J'aimerai comprendre tout de suite et le faire mais malheureusement non ()

>Bon, on va faire simple, vous nous le nom et les 50 à 100 première lignes de chacun de ces 4 fichiers .h (+ la liste des répertoires contenus dans /include, si possible)

Alors dans le dossier include j'ai aussi un dossier "Base", "CLProtocol", "FirmwareUpdate", "Api", "CP", "Log", "log4cpp".

Le _GCVersion.h :

//  This file is generated automatically. Do not modify! 
#define GC_VERSION_MAJOR 3 
#define GC_VERSION_MINOR 2 
#define GENICAM_VERSION_SUBMINOR 0

#define GC_MAIN_COMPILER VC141

/* #undef GC_COMPANY_SUFFIX */
#define GC_SVN_REVISION 6095

Le GCVersion.h :

/*!
\file
\brief    central versioning counters
*/

#ifndef GC_VERSION_H
#define GC_VERSION_H

// The following symbols are defined in a cmake generated include file
//#define GC_VERSION_MAJOR 3 
//#define GC_VERSION_MINOR 0 
//#define GC_VERSION_SUBMINOR 0
//#define GC_MAIN_COMPILER VC120 / gcc421
#include <_GenICamVersion.h>

// The Build is not supported any more
#define GC_VERSION_BUILD 0 

// Normally GC_COMPILER is fed via cmake; however in pure library mode it is not
#ifndef GC_COMPILER
#  define GC_COMPILER GC_MAIN_COMPILER
#endif 

// Don't ask...
#define STRINGIFY(x) #x
#define TOSTRING(x) STRINGIFY(x)
#define GC_RAW_UNDERSCORE(a, b, c) a ## _ ## b ## _ ## c 
#define GC_SEP_UNDERSCORE(a, b, c) GC_RAW_UNDERSCORE(a, b, c)
#define GC_RAW_UNDERSCORE_COMPANY(a, b, c, d) a ## _ ## b ## _ ## c ## _ ## d
#define GC_SEP_UNDERSCORE_COMPANY(a, b, c, d) GC_RAW_UNDERSCORE_COMPANY(a, b, c, d)

// String versions of the version numbers
#define GC_VERSION_MAJOR_STR           TOSTRING( GC_VERSION_MAJOR )
#define GC_VERSION_MINOR_STR           TOSTRING( GC_VERSION_MINOR )
#define GC_VERSION_SUBMINOR_STR        TOSTRING( GC_VERSION_SUBMINOR )
#define GC_VERSION_BUILD_STR           TOSTRING( GC_VERSION_BUILD )
#define GC_COMPILER_STR                TOSTRING( GC_COMPILER )
#define GC_ROOT                        "GC_ROOT"
#define GC_CACHE_VERSION               "GC_CACHE_V" GC_VERSION_MAJOR_STR "_" GC_VERSION_MINOR_STR
#define GC_LOG_CONFIG_VERSION          "GC_LOG_CONFIG_V" GC_VERSION_MAJOR_STR "_" GC_VERSION_MINOR_STR
#define GC_CLPROTOCOL                  "GC_CLPROTOCOL"

#endif // GC_VERSION_H

Le GC.h :

 /// \file     $Source$
 /// \brief    Common GC include file.
 /// \version  $Revision$
 /// \date     $Date$


#ifndef GC_OVERALL_H
#define GC_OVERALL_H

#if defined (_WIN32) || (defined (__GNUC__) && (defined (__linux__) || defined (__APPLE__)) || defined(VXWORKS))
#   include <Base/GCBase.h>
#   include <GenApi/GenApi.h>
#else
#   error Unknown/unsupported platform
#endif

#endif // GC_OVERALL_H

Le GCFwd.h :

/// \file GenICamFwd.h
/// \brief Forward declarations for GenICam types.
/// \ingroup Base_PublicUtilities

#ifndef GENICAM_FWD_H
#define GENICAM_FWD_H

#ifdef _WIN32
#   include <objbase.h> // interface
#else
#   define interface struct
#endif
#include <Base/GCNamespace.h>
#include <GenApi/GenApiNamespace.h>

// GCBase
namespace GC_NAMESPACE
{
    class gcstring;
    class gcstring_vector;
}

// GenApi
namespace GENAPI_NAMESPACE
{
    interface IBase;
    interface IBoolean;
    interface ICategory;
    interface IChunkPort;
    interface ICommand;
    interface IDeviceInfo;
    interface IEnumEntry;
    interface IEnumeration;
    interface IFloat;
    interface IInteger;
    interface INode;
    interface INodeMap;
    interface IPort;
    interface IPortConstruct;
    interface IPortStackedConstruct;
    interface IPortRecorder;
    interface IPortReplay;
    interface IPortWriteList;
    interface IRegister;
    interface ISelector;
    interface IString;
    interface IUserData;
    interface IValue;

    class CLock;
}

#endif // GC_FWD_H

(dans le dossier library, j'ai donc le dossier include, mais aussi le dossier lib)

Pour les includes, c'est bon, j'ai réussis (désolé pour le temps pour trouver ca, la honte), je continue les quatre étapes.

(Je sais que je ne dois pas modifier, mais je préférais vous avertir afin)

-
Edité par VincentL10 9 avril 2021 à 10:30:33

>La bibliothèque CLR qui génère la dll.

CLR n'est pas une bibliothèque mais un framework et il ne génère rien.

On va dire que c'est le fichier projet du projet C++/CLI, OK ?

>Cela s'est fait à la création du projet.

Vraisemblablement parce que vous n'avez pas décoché la case à cocher "créer un répertoire pour le projet"(ou approchant) lors de sa création. Mais c'est pas grave (si les longueurs de chemins ne sont pas "énormes")

>Si la liste du répertoire, n'est pas celle de l'explorateur de solution, laquelle est-ce ?

Il ne faut pas confondre l'explorateur de solution, qui n'est qu'une aide à l'édition des sources d'un ou plusieurs projets et la configuration des dits projets. Mais l'avant dernière ligne de votre post semble indiquer que vous avez enfin compris la différence. 

>J'aimerai comprendre tout de suite et le faire mais malheureusement non (:()

Pas de problème, faut juste dire où vous ne comprenez pas. C'est normal de ne pas tout saisir, mais c'est agaçant quand on a l'impression que vous ne suivez pas les conseils. Posez des questions sur les choses que vous ne comprenez pas plutôt que de passer cela sous silence.

"GCVersion.h" et encore plus "_GCVersion.h", c'est de la popote interne pour la compilation de la librairie, ça n'a rien à foutre dans les header "livrées" au client de la librairie (à moins que ça serve de vieux tricks, mais alors ça devrait être planqué dans un sous-répertoire). N'y touchez pas mais ne les incluez pas dans vos classes de wrapping (pas de #include de ces machins).

C'est bizarre les espaces entre le "#" et les "define" ou les "include". Tellement bizarre que j'ai l'impression que c'est des séquelles de vos modifications "intempestives". Si c'est le cas, mettez ces espaces AVANT le "#".

Le "GC.h" semble le header "public" chapeau qu'il faut inclure dans vos classes de wrapping via un #include (uniquement dans les .cpp normalement). C'est celui-ci qu'il faut inclure (voire include en premier si l'architecture de la bibliothèque vous oblige à en inclure d'autres). Il vérifie que vous êtes dans un environnement de compilation compatible avec la bibliothèque.

Le GCFwd.h serait utile si vous comptez utiliser les types déclarées par la bibliothèque à l'extérieur des classes de wrapping, ce que je ne vous conseille pas, au moins dans un premier temps.

Donc enlever ces espaces qui se baladent entre "#" et un define ou un include, si c'est vos manipulations.

Supprimez tout #include vers autre chose que '#include<GC.h>' dans votre code et essayez de compiler.

En regarde après comment faire le premier wrapper.

P.S.:

>j'ai donc le dossier include, mais aussi le dossier lib

Ca, c'est pour les points 3 et 4. 

-
Edité par bacelar 9 avril 2021 à 12:57:37

>Vraisemblablement parce que vous n'avez pas décoché la case à cocher "créer un répertoire pour le projet"(ou approchant) lors de sa création. Mais c'est pas grave (si les longueurs de chemins ne sont pas "énormes")

J'ai fait en sorte de les réduire au maximum.

>C'est bizarre les espaces entre le "#" et les "define" ou les "include". Tellement bizarre que j'ai l'impression que c'est des séquelles de vos modifications "intempestives". Si c'est le cas, mettez ces espaces AVANT le "#".

J'ai supprimé toutes celles que j'ai modifié et ressorti les originaux.

>Ca, c'est pour les points 3 et 4. 

Oui et je les ai fait.

Voici ce que comporte mon WrapperCpp.cpp

#include "pcg.h"
#include "WrapperCpp.h"
#include "GC.h"

Lorsque je compile, il m'indique l'erreur:

Erreur (active)	E0266	"IServiceProvider" est ambigu	44	
Erreur (active)	E0266	"IServiceProvider" est ambigu	91	
Erreur (active)	E0266	"IServiceProvider" est ambigu	115	
Erreur (active)	E0266	"IServiceProvider" est ambigu	239	
Erreur (active)	E0266	"IServiceProvider" est ambigu	249	
Erreur (active)	E0266	"IServiceProvider" est ambigu	6869	
Erreur (active)	E0266	"IServiceProvider" est ambigu	6871	
Erreur	C3699	'*' : impossible d'utiliser cette indirection sur le type 'IServiceProvider'	91	
Erreur	C2371	'IServiceProvider' : redéfinition ; types de base différents	98	
Erreur	C2872	'IServiceProvider' : symbole ambigu	115	
Erreur	C2872	'IServiceProvider' : symbole ambigu	239	
Erreur	C2872	'IServiceProvider' : symbole ambigu	249	
Erreur	C2872	'IServiceProvider' : symbole ambigu	6869	
Erreur	C2872	'IServiceProvider' : symbole ambigu	6871	

Et lorque je rajoute dans le WrapperCpp.h

#pragma once

//Include GC
#include <GC.h>

using namespace System;

namespace WrapperCpp {
	public ref class _GCVersion
	{
	
	};
}

J'obtiens 3 avertissements (Même erreur 3 fois, sur différentes lignes):

C4793 'GC_3_2::ExceptionReporter<GC_3_2::AccessException>::Report':fonction compilée en tant que code natif : gcexception.h

Et 1 erreur :

LNK1104 impossible d'ouvrir le fichier 'GCBase_MDd_VC141_v3_2.lib' LINK

Sachant que je ne possède pas cette libraire, mais j'ai:

GCBase_MD_VC141_v3_2.lib

Je vais revérifier


 

-
Edité par VincentL10 9 avril 2021 à 14:02:07

>J'ai supprimé toutes celles que j'ai modifié et ressorti les originaux.

Ok, si c'est dans l'original, pas de soucis, c'est assez peu standard mais tant que cela ne pose pas de problème de compilation, c'est OK.

Les problèmes que vous indiquez ne semblent pas venir des ces espaces post #.

>Oui et je les ai fait.

Ok, les traces que vous donnez n'indiquent plus que vous avez loupé des choses dans la configuration du projet. 

Ligne 3 de WrapperCpp.cpp: ATTENTION '#include <GC.h>' et non '#include "GC.h"'. C'est important, cela peu facilement expliqué des problématiques des redéfinitions/ambiguïtés. Sans le code à la ligne indiquée de l'erreur, difficile d'être formel.

L'ajout de la ligne d'include dans le .h a court-circuité l'erreur de l'usage des guillemets à la place des chevrons (<>), et si cela a fait disparaître les redéfinitions/ambiguïtés, c'est que mon hypothèse était juste.

Évitez d'ajouter des #include non indispensable dans les .h, et réservez les #include dans les .cpp pour faciliter leur gestion.

Donc retirez la ligne ajoutée dans le .h pour la mettre en remplacement de celle que vous avez ajouté dans le cpp (ou remplacez les guillemets pas des chevrons dans l'include du cpp, c'est pareil).

Pour le warning "C4793", c'est vraisemblablement du code source qui est dans les .h (inliné dans le jargon C++), ce qui ne devrait pas arriver dans une librairie native standard. (essayez de donner les messages d'erreurs complets, SVP)

Montrez-nous le code qui pose problème pour qu'on vous trouve une parade à ce codage de cochon. C'est peut-être du code qui n'a aucune utilité dans votre cas et que quelques constante de compilation devraient rendre muet.

>LNK1104

Cool, une erreur d'édition de lien, ça veut dire que la compilation s'est bien achevée, malgré les quelques warnings.

Celle-là elle est un peu tricky, même pour un habitué du C++. Mais pas de panique, rien d'insurmontable. 

Cela explique la présence des fichiers "GCVersion.h" et "_GCVersion.h" qui servent à monte cette petite bidouille qui suit.

La directive "#pragma(comment,lib)..." permet de ne plus faire le point 4 de ma procédure et de gérer plus facilement la présence de multiple versions compilés de la dll et des .lib de celle-ci dans un même répertoire (/lib vraisemblablement). En connaissant les constantes de compilation définies dans les fichiers "GCVersion.h" et "_GCVersion.h" (via les #define) et celles définies au niveau du projet et du compilateur, le code est capable de générer le nom probable de la ou des .lib qui auraient dû être ajoutés au point 4.

Sachant cela, il serait plus prudent de supprimer ce qui a été ajouté au point 4 (mais pas au point 3), dans un premier temps.

"GCBase_MD_VC141_v3_2.lib" est une version Release de la lib, le message d'erreur indique que l'éditeur de lien cherche "GCBase_MDd_VC141_v3_2.lib". Ce "d" supplémentaire est très probablement la marque que c'est une version DEBUG que l'éditeur de lien cherche.

Ce problème devrait donc disparaître si vous compilez en Release. C'est pas top, mais tant que vos managers ne vous fournissent pas les bons outils pour travailler confortablement, et votre manque d'expérience en C++, je vous conseille de vous cantonner à la version Release.

Les mélanges de version de Runtime C et C++ (Debug vs Release), c'est tellement casse-gueule qu'on évite au maximum, même avec de l'expérience.

Vos wrapper devraient être assez simple pour ne pas avoir besoin d'utiliser des versions Debug de ces .lib et .dll.