J'ai un projet composé d'un moteur en C++ Managed et d'une interface
graphique en C# sous forme d'assembly.
Dans Visual Studio 2003, comment faire pour pouvoir appeler les
fonctions de mon interface en C# à partir de mon programme en C++
managed ? Y'a t'il des fichiers à intégrer, une manière de faire ?
Ajoute ton assembly C# comme reference (menu add reference du ton projet). Ensuite tu peux utiliser tous les objets public de ton assembly.
Harkonnen
"Alexis KARTMANN" <alexis(nospam)@kartmann.com> wrote in news::
Ajoute ton assembly C# comme reference (menu add reference du ton projet). Ensuite tu peux utiliser tous les objets public de ton assembly.
Bonjour, et merci pour ta réponse. J'ai effectué cette manipulation, en allant chercher via le menu Add Reference l'assembly concernée (via le bouton "Browse")
Neanmoins, quand je lance l'application, j'ai une FileNotFoundException. Le fichier non trouvé est l'assembly que j'ai pourtant référencée et qui existe bien. De plus, je constate bien en visualisant la ligne de commande de cl.exe, qu'elle a été rajoutée (/FD "C:documents and settingsprojet form1.dll")
As tu une idée du pourquoi ?
"Alexis KARTMANN" <alexis(nospam)@kartmann.com> wrote in
news:ujVamypEFHA.2756@TK2MSFTNGP15.phx.gbl:
Ajoute ton assembly C# comme reference (menu add reference du ton
projet). Ensuite tu peux utiliser tous les objets public de ton
assembly.
Bonjour, et merci pour ta réponse. J'ai effectué cette manipulation, en
allant chercher via le menu Add Reference l'assembly concernée (via le
bouton "Browse")
Neanmoins, quand je lance l'application, j'ai une FileNotFoundException. Le
fichier non trouvé est l'assembly que j'ai pourtant référencée et qui
existe bien. De plus, je constate bien en visualisant la ligne de commande
de cl.exe, qu'elle a été rajoutée (/FD "C:documents and settingsprojet
form1.dll")
"Alexis KARTMANN" <alexis(nospam)@kartmann.com> wrote in news::
Ajoute ton assembly C# comme reference (menu add reference du ton projet). Ensuite tu peux utiliser tous les objets public de ton assembly.
Bonjour, et merci pour ta réponse. J'ai effectué cette manipulation, en allant chercher via le menu Add Reference l'assembly concernée (via le bouton "Browse")
Neanmoins, quand je lance l'application, j'ai une FileNotFoundException. Le fichier non trouvé est l'assembly que j'ai pourtant référencée et qui existe bien. De plus, je constate bien en visualisant la ligne de commande de cl.exe, qu'elle a été rajoutée (/FD "C:documents and settingsprojet form1.dll")
As tu une idée du pourquoi ?
Laura Martignas
> Bonjour, et merci pour ta réponse. J'ai effectué cette manipulation, en allant chercher via le menu Add Reference l'assembly concernée (via le bouton "Browse")
Neanmoins, quand je lance l'application, j'ai une FileNotFoundException. Le fichier non trouvé est l'assembly que j'ai pourtant référencée et qui existe bien. De plus, je constate bien en visualisant la ligne de commande de cl.exe, qu'elle a été rajoutée (/FD "C:documents and settingsprojet form1.dll")
As tu une idée du pourquoi ?
Désolée, j'ai posté avec le compte de mon ami, mais ce message vient bien de moi, Laura :)
En espérant que tu pourras me dépanner
> Bonjour, et merci pour ta réponse. J'ai effectué cette manipulation,
en allant chercher via le menu Add Reference l'assembly concernée (via
le bouton "Browse")
Neanmoins, quand je lance l'application, j'ai une
FileNotFoundException. Le fichier non trouvé est l'assembly que j'ai
pourtant référencée et qui existe bien. De plus, je constate bien en
visualisant la ligne de commande de cl.exe, qu'elle a été rajoutée
(/FD "C:documents and settingsprojet form1.dll")
As tu une idée du pourquoi ?
Désolée, j'ai posté avec le compte de mon ami, mais ce message vient bien
de moi, Laura :)
> Bonjour, et merci pour ta réponse. J'ai effectué cette manipulation, en allant chercher via le menu Add Reference l'assembly concernée (via le bouton "Browse")
Neanmoins, quand je lance l'application, j'ai une FileNotFoundException. Le fichier non trouvé est l'assembly que j'ai pourtant référencée et qui existe bien. De plus, je constate bien en visualisant la ligne de commande de cl.exe, qu'elle a été rajoutée (/FD "C:documents and settingsprojet form1.dll")
As tu une idée du pourquoi ?
Désolée, j'ai posté avec le compte de mon ami, mais ce message vient bien de moi, Laura :)
En espérant que tu pourras me dépanner
Paul Bacelar
Les assembly comme les dll n'ont pas été conçu pour être des librairies statiques mais des modules exécutables réutilisables, et en cela elles doivent garder leur intégrité en tant que modules exécutables autonomes.
Pourquoi vouloir absolument faire disparaître ces malheurs fichiers qui, avec .NET et les msi, peuvent être mis dans le GAC sans que l'utilisateur n'en prenne conscience
Je pense que votre problème est bien en amont, car votre problème exposé semble bien artificiel. -- Paul Bacelar
"Laura Martignas" wrote in message news:
> Bonjour, et merci pour ta réponse. J'ai effectué cette manipulation, > en allant chercher via le menu Add Reference l'assembly concernée (via > le bouton "Browse") > > Neanmoins, quand je lance l'application, j'ai une > FileNotFoundException. Le fichier non trouvé est l'assembly que j'ai > pourtant référencée et qui existe bien. De plus, je constate bien en > visualisant la ligne de commande de cl.exe, qu'elle a été rajoutée > (/FD "C:documents and settingsprojet form1.dll") > > As tu une idée du pourquoi ?
Désolée, j'ai posté avec le compte de mon ami, mais ce message vient bien de moi, Laura :)
En espérant que tu pourras me dépanner
Les assembly comme les dll n'ont pas été conçu pour être des librairies
statiques mais des modules exécutables réutilisables, et en cela elles
doivent garder leur intégrité en tant que modules exécutables autonomes.
Pourquoi vouloir absolument faire disparaître ces malheurs fichiers qui,
avec .NET et les msi, peuvent être mis dans le GAC sans que l'utilisateur
n'en prenne conscience
Je pense que votre problème est bien en amont, car votre problème exposé
semble bien artificiel.
--
Paul Bacelar
"Laura Martignas" <lauramarty@libertysurf.fr> wrote in message
news:Xns95FE24CDE580lauraliberty@193.252.117.183...
> Bonjour, et merci pour ta réponse. J'ai effectué cette manipulation,
> en allant chercher via le menu Add Reference l'assembly concernée (via
> le bouton "Browse")
>
> Neanmoins, quand je lance l'application, j'ai une
> FileNotFoundException. Le fichier non trouvé est l'assembly que j'ai
> pourtant référencée et qui existe bien. De plus, je constate bien en
> visualisant la ligne de commande de cl.exe, qu'elle a été rajoutée
> (/FD "C:documents and settingsprojet form1.dll")
>
> As tu une idée du pourquoi ?
Désolée, j'ai posté avec le compte de mon ami, mais ce message vient bien
de moi, Laura :)
Les assembly comme les dll n'ont pas été conçu pour être des librairies statiques mais des modules exécutables réutilisables, et en cela elles doivent garder leur intégrité en tant que modules exécutables autonomes.
Pourquoi vouloir absolument faire disparaître ces malheurs fichiers qui, avec .NET et les msi, peuvent être mis dans le GAC sans que l'utilisateur n'en prenne conscience
Je pense que votre problème est bien en amont, car votre problème exposé semble bien artificiel. -- Paul Bacelar
"Laura Martignas" wrote in message news:
> Bonjour, et merci pour ta réponse. J'ai effectué cette manipulation, > en allant chercher via le menu Add Reference l'assembly concernée (via > le bouton "Browse") > > Neanmoins, quand je lance l'application, j'ai une > FileNotFoundException. Le fichier non trouvé est l'assembly que j'ai > pourtant référencée et qui existe bien. De plus, je constate bien en > visualisant la ligne de commande de cl.exe, qu'elle a été rajoutée > (/FD "C:documents and settingsprojet form1.dll") > > As tu une idée du pourquoi ?
Désolée, j'ai posté avec le compte de mon ami, mais ce message vient bien de moi, Laura :)
En espérant que tu pourras me dépanner
Laura Martignas
"Paul Bacelar" wrote in news::
Les assembly comme les dll n'ont pas été conçu pour être des librairies statiques mais des modules exécutables réutilisables, et en cela elles doivent garder leur intégrité en tant que modules exécutables autonomes.
Pourquoi vouloir absolument faire disparaître ces malheurs fichiers qui, avec .NET et les msi, peuvent être mis dans le GAC sans que l'utilisateur n'en prenne conscience
Je pense que votre problème est bien en amont, car votre problème exposé semble bien artificiel.
Bonjour, merci pour votre réponse.
Je comprends bien votre point de vue, placer l'assembly dans le GAC serait surement la solution, mais pourquoi diable ai-je une erreur de fichier non trouvé alors que le chemin spécifié est correct ? Il s'agit d'une assembly qu'un seul programme utilisera, donc je vois pas pourquoi j'encombrerais le GAC des utilisateurs avec une assembly qui ne servira qu'une seule fois.
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> wrote in
news:uBU5dOvEFHA.2608@TK2MSFTNGP10.phx.gbl:
Les assembly comme les dll n'ont pas été conçu pour être des librairies
statiques mais des modules exécutables réutilisables, et en cela elles
doivent garder leur intégrité en tant que modules exécutables autonomes.
Pourquoi vouloir absolument faire disparaître ces malheurs fichiers qui,
avec .NET et les msi, peuvent être mis dans le GAC sans que l'utilisateur
n'en prenne conscience
Je pense que votre problème est bien en amont, car votre problème exposé
semble bien artificiel.
Bonjour, merci pour votre réponse.
Je comprends bien votre point de vue, placer l'assembly dans le GAC serait
surement la solution, mais pourquoi diable ai-je une erreur de fichier non
trouvé alors que le chemin spécifié est correct ?
Il s'agit d'une assembly qu'un seul programme utilisera, donc je vois pas
pourquoi j'encombrerais le GAC des utilisateurs avec une assembly qui ne
servira qu'une seule fois.
Les assembly comme les dll n'ont pas été conçu pour être des librairies statiques mais des modules exécutables réutilisables, et en cela elles doivent garder leur intégrité en tant que modules exécutables autonomes.
Pourquoi vouloir absolument faire disparaître ces malheurs fichiers qui, avec .NET et les msi, peuvent être mis dans le GAC sans que l'utilisateur n'en prenne conscience
Je pense que votre problème est bien en amont, car votre problème exposé semble bien artificiel.
Bonjour, merci pour votre réponse.
Je comprends bien votre point de vue, placer l'assembly dans le GAC serait surement la solution, mais pourquoi diable ai-je une erreur de fichier non trouvé alors que le chemin spécifié est correct ? Il s'agit d'une assembly qu'un seul programme utilisera, donc je vois pas pourquoi j'encombrerais le GAC des utilisateurs avec une assembly qui ne servira qu'une seule fois.
Paul Bacelar
"Laura Martignas" wrote in message news:
"Paul Bacelar" wrote in news::
> Les assembly comme les dll n'ont pas été conçu pour être des librairies > statiques mais des modules exécutables réutilisables, et en cela elles > doivent garder leur intégrité en tant que modules exécutables autonomes. > > Pourquoi vouloir absolument faire disparaître ces malheurs fichiers qui, > avec .NET et les msi, peuvent être mis dans le GAC sans que
l'utilisateur
> n'en prenne conscience > > Je pense que votre problème est bien en amont, car votre problème exposé > semble bien artificiel.
Bonjour, merci pour votre réponse.
Je comprends bien votre point de vue, placer l'assembly dans le GAC serait surement la solution, mais pourquoi diable ai-je une erreur de fichier non trouvé alors que le chemin spécifié est correct ?
Il n'est pas correct car vous chercher un assembly, donc un module exécutable dans les répertoires spécifié à cet effet et non dans une hypothétique ressource incorporée dans votre exécutable.
Il s'agit d'une assembly qu'un seul programme utilisera, donc je vois pas pourquoi j'encombrerais le GAC des utilisateurs avec une assembly qui ne servira qu'une seule fois.
Vous résonnez à très cour terme. Toute dll, assembly, composant a commencé par être utilisé par une application mais leur conception a été menée de telle sorte qu'il était facile de les utiliser dans d'autres cas d'utilisation. Ce n'est pas l'utilisation du code qui fait sa fonction mais sa conception.
Si votre application veut utiliser ces assembly de manière privée, vous n' avez qu'à les mettre dans le même répertoire que l'exécutable ou dans tout autre répertoire que vous spécifierez dans le fichier de configuration
<configuration>
<runtime>
<assemblyBinding>
<probing>
Vous polluez peut-être le disque de l'utilisateur, mais avec les ressources c'est pire car vous ne prenez plus de place sur disque dû à l'encodage des ressources dans l'exécutable et vous ne pourrez plus hotfixer ou upgrader vos assemblies.
Avec le GAC, vous polluez beaucoup moins la machine de l'utilisateur car une seule instance d'une version particulière de chaque assembly est conservée dans le GAC. Sans compter les vérifications et autres prétraitements que vous épargnez à la CLR lors du démarrage de l'application.
-- Paul Bacelar
"Laura Martignas" <lauramarty@libertysurf.fr> wrote in message
news:Xns95FE8B038BBAClauraliberty@193.252.117.183...
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> wrote in
news:uBU5dOvEFHA.2608@TK2MSFTNGP10.phx.gbl:
> Les assembly comme les dll n'ont pas été conçu pour être des librairies
> statiques mais des modules exécutables réutilisables, et en cela elles
> doivent garder leur intégrité en tant que modules exécutables autonomes.
>
> Pourquoi vouloir absolument faire disparaître ces malheurs fichiers qui,
> avec .NET et les msi, peuvent être mis dans le GAC sans que
l'utilisateur
> n'en prenne conscience
>
> Je pense que votre problème est bien en amont, car votre problème exposé
> semble bien artificiel.
Bonjour, merci pour votre réponse.
Je comprends bien votre point de vue, placer l'assembly dans le GAC serait
surement la solution, mais pourquoi diable ai-je une erreur de fichier non
trouvé alors que le chemin spécifié est correct ?
Il n'est pas correct car vous chercher un assembly, donc un module
exécutable dans les répertoires spécifié à cet effet et non dans une
hypothétique ressource incorporée dans votre exécutable.
Il s'agit d'une assembly qu'un seul programme utilisera, donc je vois pas
pourquoi j'encombrerais le GAC des utilisateurs avec une assembly qui ne
servira qu'une seule fois.
Vous résonnez à très cour terme. Toute dll, assembly, composant a commencé
par être utilisé par une application mais leur conception a été menée de
telle sorte qu'il était facile de les utiliser dans d'autres cas
d'utilisation. Ce n'est pas l'utilisation du code qui fait sa fonction mais
sa conception.
Si votre application veut utiliser ces assembly de manière privée, vous n'
avez qu'à les mettre dans le même répertoire que l'exécutable ou dans tout
autre répertoire que vous spécifierez dans le fichier de configuration
<configuration>
<runtime>
<assemblyBinding>
<probing>
Vous polluez peut-être le disque de l'utilisateur, mais avec les ressources
c'est pire car vous ne prenez plus de place sur disque dû à l'encodage des
ressources dans l'exécutable et vous ne pourrez plus hotfixer ou upgrader
vos assemblies.
Avec le GAC, vous polluez beaucoup moins la machine de l'utilisateur car une
seule instance d'une version particulière de chaque assembly est conservée
dans le GAC. Sans compter les vérifications et autres prétraitements que
vous épargnez à la CLR lors du démarrage de l'application.
> Les assembly comme les dll n'ont pas été conçu pour être des librairies > statiques mais des modules exécutables réutilisables, et en cela elles > doivent garder leur intégrité en tant que modules exécutables autonomes. > > Pourquoi vouloir absolument faire disparaître ces malheurs fichiers qui, > avec .NET et les msi, peuvent être mis dans le GAC sans que
l'utilisateur
> n'en prenne conscience > > Je pense que votre problème est bien en amont, car votre problème exposé > semble bien artificiel.
Bonjour, merci pour votre réponse.
Je comprends bien votre point de vue, placer l'assembly dans le GAC serait surement la solution, mais pourquoi diable ai-je une erreur de fichier non trouvé alors que le chemin spécifié est correct ?
Il n'est pas correct car vous chercher un assembly, donc un module exécutable dans les répertoires spécifié à cet effet et non dans une hypothétique ressource incorporée dans votre exécutable.
Il s'agit d'une assembly qu'un seul programme utilisera, donc je vois pas pourquoi j'encombrerais le GAC des utilisateurs avec une assembly qui ne servira qu'une seule fois.
Vous résonnez à très cour terme. Toute dll, assembly, composant a commencé par être utilisé par une application mais leur conception a été menée de telle sorte qu'il était facile de les utiliser dans d'autres cas d'utilisation. Ce n'est pas l'utilisation du code qui fait sa fonction mais sa conception.
Si votre application veut utiliser ces assembly de manière privée, vous n' avez qu'à les mettre dans le même répertoire que l'exécutable ou dans tout autre répertoire que vous spécifierez dans le fichier de configuration
<configuration>
<runtime>
<assemblyBinding>
<probing>
Vous polluez peut-être le disque de l'utilisateur, mais avec les ressources c'est pire car vous ne prenez plus de place sur disque dû à l'encodage des ressources dans l'exécutable et vous ne pourrez plus hotfixer ou upgrader vos assemblies.
Avec le GAC, vous polluez beaucoup moins la machine de l'utilisateur car une seule instance d'une version particulière de chaque assembly est conservée dans le GAC. Sans compter les vérifications et autres prétraitements que vous épargnez à la CLR lors du démarrage de l'application.
