Bonjour,
Je suis en train de realiser un proto d'un wrapper d'un lib C++.
J'utilise le managed C++ pour realiser mon assemblie .NET et appeler mes
methodes natives.
Mais je suis face a un pb de namespace.
* Ma classe native s'appelle ClassA et je veux que la classe dotnet
pareil car ma lib est un SDK.
* dans mon managed C++, je met ma nouvelle classe manage dans un
je fait reference a ma classe native en specifiant ::ClassA. Jusque la
va bien, je genere mon assemblie.
* Maintenant, je veux appeler les methodes de ma ClassA managee depuis une
appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
* Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference a ma
methode native (erreur a la compil) alors que si j'ecris
mon_namespace::ClassA::myMethod() ca compile.
C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
Bonjour,
Je suis en train de realiser un proto d'un wrapper d'un lib C++.
J'utilise le managed C++ pour realiser mon assemblie .NET et appeler mes
methodes natives.
Mais je suis face a un pb de namespace.
* Ma classe native s'appelle ClassA et je veux que la classe dotnet
pareil car ma lib est un SDK.
* dans mon managed C++, je met ma nouvelle classe manage dans un
je fait reference a ma classe native en specifiant ::ClassA. Jusque la
va bien, je genere mon assemblie.
* Maintenant, je veux appeler les methodes de ma ClassA managee depuis une
appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
* Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference a ma
methode native (erreur a la compil) alors que si j'ecris
mon_namespace::ClassA::myMethod() ca compile.
C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
Bonjour,
Je suis en train de realiser un proto d'un wrapper d'un lib C++.
J'utilise le managed C++ pour realiser mon assemblie .NET et appeler mes
methodes natives.
Mais je suis face a un pb de namespace.
* Ma classe native s'appelle ClassA et je veux que la classe dotnet
pareil car ma lib est un SDK.
* dans mon managed C++, je met ma nouvelle classe manage dans un
je fait reference a ma classe native en specifiant ::ClassA. Jusque la
va bien, je genere mon assemblie.
* Maintenant, je veux appeler les methodes de ma ClassA managee depuis une
appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
* Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference a ma
methode native (erreur a la compil) alors que si j'ecris
mon_namespace::ClassA::myMethod() ca compile.
C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
"Jerome" wrote in message
news:
> Bonjour,
>
> Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> J'utilise le managed C++ pour realiser mon assemblie .NET et appeler mes
> methodes natives.
> Mais je suis face a un pb de namespace.
> * Ma classe native s'appelle ClassA et je veux que la classe dotnet
s'apelle
> pareil car ma lib est un SDK.
> * dans mon managed C++, je met ma nouvelle classe manage dans un
namespace,
> je fait reference a ma classe native en specifiant ::ClassA. Jusque la
tout
> va bien, je genere mon assemblie.
> * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
> appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference a
> methode native (erreur a la compil) alors que si j'ecris
> mon_namespace::ClassA::myMethod() ca compile.
>
> C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
>
>
Il y a plusieurs erreurs.
- Ne jamais mettre de classe dans le namespace racine (ou anonyme). Cela
évitera les collisions de nom que vous subissez.
- Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas la
rendre utilisable par d'autres clients que la classe managée ClassA.
Internal à la place de Public serait, à première vue, un bien meilleur
choix.
- etc... a suivre ;-)
--
Paul Bacelar
"Jerome" <jlague@mc.com> wrote in message
news:eR0ORKaSFHA.3156@TK2MSFTNGP15.phx.gbl...
> Bonjour,
>
> Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> J'utilise le managed C++ pour realiser mon assemblie .NET et appeler mes
> methodes natives.
> Mais je suis face a un pb de namespace.
> * Ma classe native s'appelle ClassA et je veux que la classe dotnet
s'apelle
> pareil car ma lib est un SDK.
> * dans mon managed C++, je met ma nouvelle classe manage dans un
namespace,
> je fait reference a ma classe native en specifiant ::ClassA. Jusque la
tout
> va bien, je genere mon assemblie.
> * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
> appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference a
> methode native (erreur a la compil) alors que si j'ecris
> mon_namespace::ClassA::myMethod() ca compile.
>
> C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
>
>
Il y a plusieurs erreurs.
- Ne jamais mettre de classe dans le namespace racine (ou anonyme). Cela
évitera les collisions de nom que vous subissez.
- Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas la
rendre utilisable par d'autres clients que la classe managée ClassA.
Internal à la place de Public serait, à première vue, un bien meilleur
choix.
- etc... a suivre ;-)
--
Paul Bacelar
"Jerome" wrote in message
news:
> Bonjour,
>
> Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> J'utilise le managed C++ pour realiser mon assemblie .NET et appeler mes
> methodes natives.
> Mais je suis face a un pb de namespace.
> * Ma classe native s'appelle ClassA et je veux que la classe dotnet
s'apelle
> pareil car ma lib est un SDK.
> * dans mon managed C++, je met ma nouvelle classe manage dans un
namespace,
> je fait reference a ma classe native en specifiant ::ClassA. Jusque la
tout
> va bien, je genere mon assemblie.
> * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
> appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference a
> methode native (erreur a la compil) alors que si j'ecris
> mon_namespace::ClassA::myMethod() ca compile.
>
> C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
>
>
Il y a plusieurs erreurs.
- Ne jamais mettre de classe dans le namespace racine (ou anonyme). Cela
évitera les collisions de nom que vous subissez.
- Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas la
rendre utilisable par d'autres clients que la classe managée ClassA.
Internal à la place de Public serait, à première vue, un bien meilleur
choix.
- etc... a suivre ;-)
--
Paul Bacelar
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" a écrit dans le message
de news:d4k1o0$e4e$
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news:d4k1o0$e4e$1@apollon.grec.isp.9tel.net...
> "Jerome" <jlague@mc.com> wrote in message
> news:eR0ORKaSFHA.3156@TK2MSFTNGP15.phx.gbl...
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" a écrit dans le message
de news:d4k1o0$e4e$
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" a écrit dans le message
de news:d4k1o0$e4e$
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news:d4k1o0$e4e$1@apollon.grec.isp.9tel.net...
> "Jerome" <jlague@mc.com> wrote in message
> news:eR0ORKaSFHA.3156@TK2MSFTNGP15.phx.gbl...
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" a écrit dans le message
de news:d4k1o0$e4e$
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" a écrit dans le message
de news:d4k1o0$e4e$
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news:d4k1o0$e4e$1@apollon.grec.isp.9tel.net...
> "Jerome" <jlague@mc.com> wrote in message
> news:eR0ORKaSFHA.3156@TK2MSFTNGP15.phx.gbl...
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" a écrit dans le message
de news:d4k1o0$e4e$
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" a écrit dans le message
de news:d4k1o0$e4e$
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news:d4k1o0$e4e$1@apollon.grec.isp.9tel.net...
> "Jerome" <jlague@mc.com> wrote in message
> news:eR0ORKaSFHA.3156@TK2MSFTNGP15.phx.gbl...
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Bonjour,
- Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le probleme
c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
plein d'appli.
- Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
En fait c des que j'utilise :: que les problemes apparaissent (cf. exemple
ci dessous). C'est un comportement plutot bizarre.
// unmanaged.cpp
class __declspec(dllexport) Native
{
public:
void foo() {printf("native foo calledn")};
};
// managed.cpp
class __declspec(dllimport) Native {
public:
void foo();
}
namespace managedDll
{
public __gc class Native {
protected:
// Put the line below in comment and everything works fine
::Native __nogc *unmanagedNativePtr;
public:
void foo() { Console::WriteLine("N::Native::foo");}
};
}
// Class1.cs
using System;
using System.IO;
using managedDll;
namespace ConsoleApplication1
{
class Test
{
static void Main()
{
Native obj = new Native();
obj.foo();
}
}
}
"Paul Bacelar" a écrit dans le message
de news:d4k1o0$e4e$
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
> > methodes natives.
> > Mais je suis face a un pb de namespace.
> > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> s'apelle
> > pareil car ma lib est un SDK.
> > * dans mon managed C++, je met ma nouvelle classe manage dans un
> namespace,
> > je fait reference a ma classe native en specifiant ::ClassA. Jusque la
> tout
> > va bien, je genere mon assemblie.
> > * Maintenant, je veux appeler les methodes de ma ClassA managee depuis
une
> > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait reference
ma
> > methode native (erreur a la compil) alors que si j'ecris
> > mon_namespace::ClassA::myMethod() ca compile.
> >
> > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> >
> >
>
> Il y a plusieurs erreurs.
>
>
>
> - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> évitera les collisions de nom que vous subissez.
>
> - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
> rendre utilisable par d'autres clients que la classe managée ClassA.
> Internal à la place de Public serait, à première vue, un bien meilleur
> choix.
>
> - etc... a suivre ;-)
>
>
> --
> Paul Bacelar
>
>
Primo : ne jamais exporter de class.
Secondo : si vous avez correctement architecturé votre projet, vous avez
dll non managée pour votre SDK et un assembly comme wrapper.
Votre assembly ne doit pas rendre public les classes natives qu'il wrappe,
sinon il perd sa fonction de wrapper.
Pour rendre les classes natives invisibles aux utilisateurs du wrapper, il
faut ajouter " /d1PrivateNativeTypes" dans l'editBox "Options
supplémentaires" de la rubrique "Ligne de commande" de la section "C/C++"
dans les propriétés du projet de la dll managée contenant le wrapper.
Manipe testée avec VS.NET 2003.
J'ai appris un truc moi, aujourd'hui ;-).
--
Paul Bacelar
"Jerome" wrote in message
news:
> Bonjour,
>
> - Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le
> c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
par
> plein d'appli.
> - Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
>
> En fait c des que j'utilise :: que les problemes apparaissent (cf.
> ci dessous). C'est un comportement plutot bizarre.
>
> // unmanaged.cpp
> class __declspec(dllexport) Native
>
> {
>
> public:
>
> void foo() {printf("native foo calledn")};
>
> };
>
> // managed.cpp
>
> class __declspec(dllimport) Native {
>
> public:
> void foo();
> }
>
> namespace managedDll
>
> {
>
> public __gc class Native {
>
> protected:
>
> // Put the line below in comment and everything works fine
>
> ::Native __nogc *unmanagedNativePtr;
>
> public:
>
> void foo() { Console::WriteLine("N::Native::foo");}
>
> };
>
> }
>
> // Class1.cs
>
> using System;
>
> using System.IO;
>
> using managedDll;
>
> namespace ConsoleApplication1
>
> {
>
> class Test
>
> {
>
> static void Main()
>
> {
>
> Native obj = new Native();
>
> obj.foo();
>
> }
>
> }
>
> }
>
> "Paul Bacelar" a écrit dans le
> de news:d4k1o0$e4e$
> > "Jerome" wrote in message
> > news:
> > > Bonjour,
> > >
> > > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
mes
> > > methodes natives.
> > > Mais je suis face a un pb de namespace.
> > > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> > s'apelle
> > > pareil car ma lib est un SDK.
> > > * dans mon managed C++, je met ma nouvelle classe manage dans un
> > namespace,
> > > je fait reference a ma classe native en specifiant ::ClassA. Jusque
> > tout
> > > va bien, je genere mon assemblie.
> > > * Maintenant, je veux appeler les methodes de ma ClassA managee
> une
> > > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait
a
> ma
> > > methode native (erreur a la compil) alors que si j'ecris
> > > mon_namespace::ClassA::myMethod() ca compile.
> > >
> > > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> > >
> > >
> >
> > Il y a plusieurs erreurs.
> >
> >
> >
> > - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
Cela
> > évitera les collisions de nom que vous subissez.
> >
> > - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
la
> > rendre utilisable par d'autres clients que la classe managée ClassA.
> > Internal à la place de Public serait, à première vue, un bien meilleur
> > choix.
> >
> > - etc... a suivre ;-)
> >
> >
> > --
> > Paul Bacelar
> >
> >
>
>
Primo : ne jamais exporter de class.
Secondo : si vous avez correctement architecturé votre projet, vous avez
dll non managée pour votre SDK et un assembly comme wrapper.
Votre assembly ne doit pas rendre public les classes natives qu'il wrappe,
sinon il perd sa fonction de wrapper.
Pour rendre les classes natives invisibles aux utilisateurs du wrapper, il
faut ajouter " /d1PrivateNativeTypes" dans l'editBox "Options
supplémentaires" de la rubrique "Ligne de commande" de la section "C/C++"
dans les propriétés du projet de la dll managée contenant le wrapper.
Manipe testée avec VS.NET 2003.
J'ai appris un truc moi, aujourd'hui ;-).
--
Paul Bacelar
"Jerome" <jlague@mc.com> wrote in message
news:uLW1JKkSFHA.1404@TK2MSFTNGP09.phx.gbl...
> Bonjour,
>
> - Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le
> c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
par
> plein d'appli.
> - Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
>
> En fait c des que j'utilise :: que les problemes apparaissent (cf.
> ci dessous). C'est un comportement plutot bizarre.
>
> // unmanaged.cpp
> class __declspec(dllexport) Native
>
> {
>
> public:
>
> void foo() {printf("native foo calledn")};
>
> };
>
> // managed.cpp
>
> class __declspec(dllimport) Native {
>
> public:
> void foo();
> }
>
> namespace managedDll
>
> {
>
> public __gc class Native {
>
> protected:
>
> // Put the line below in comment and everything works fine
>
> ::Native __nogc *unmanagedNativePtr;
>
> public:
>
> void foo() { Console::WriteLine("N::Native::foo");}
>
> };
>
> }
>
> // Class1.cs
>
> using System;
>
> using System.IO;
>
> using managedDll;
>
> namespace ConsoleApplication1
>
> {
>
> class Test
>
> {
>
> static void Main()
>
> {
>
> Native obj = new Native();
>
> obj.foo();
>
> }
>
> }
>
> }
>
> "Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le
> de news:d4k1o0$e4e$1@apollon.grec.isp.9tel.net...
> > "Jerome" <jlague@mc.com> wrote in message
> > news:eR0ORKaSFHA.3156@TK2MSFTNGP15.phx.gbl...
> > > Bonjour,
> > >
> > > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
mes
> > > methodes natives.
> > > Mais je suis face a un pb de namespace.
> > > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> > s'apelle
> > > pareil car ma lib est un SDK.
> > > * dans mon managed C++, je met ma nouvelle classe manage dans un
> > namespace,
> > > je fait reference a ma classe native en specifiant ::ClassA. Jusque
> > tout
> > > va bien, je genere mon assemblie.
> > > * Maintenant, je veux appeler les methodes de ma ClassA managee
> une
> > > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait
a
> ma
> > > methode native (erreur a la compil) alors que si j'ecris
> > > mon_namespace::ClassA::myMethod() ca compile.
> > >
> > > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> > >
> > >
> >
> > Il y a plusieurs erreurs.
> >
> >
> >
> > - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
Cela
> > évitera les collisions de nom que vous subissez.
> >
> > - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
la
> > rendre utilisable par d'autres clients que la classe managée ClassA.
> > Internal à la place de Public serait, à première vue, un bien meilleur
> > choix.
> >
> > - etc... a suivre ;-)
> >
> >
> > --
> > Paul Bacelar
> >
> >
>
>
Primo : ne jamais exporter de class.
Secondo : si vous avez correctement architecturé votre projet, vous avez
dll non managée pour votre SDK et un assembly comme wrapper.
Votre assembly ne doit pas rendre public les classes natives qu'il wrappe,
sinon il perd sa fonction de wrapper.
Pour rendre les classes natives invisibles aux utilisateurs du wrapper, il
faut ajouter " /d1PrivateNativeTypes" dans l'editBox "Options
supplémentaires" de la rubrique "Ligne de commande" de la section "C/C++"
dans les propriétés du projet de la dll managée contenant le wrapper.
Manipe testée avec VS.NET 2003.
J'ai appris un truc moi, aujourd'hui ;-).
--
Paul Bacelar
"Jerome" wrote in message
news:
> Bonjour,
>
> - Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le
> c'est que je ne peut pas modifier mon SDK natif car il est deja utiliser
par
> plein d'appli.
> - Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
>
> En fait c des que j'utilise :: que les problemes apparaissent (cf.
> ci dessous). C'est un comportement plutot bizarre.
>
> // unmanaged.cpp
> class __declspec(dllexport) Native
>
> {
>
> public:
>
> void foo() {printf("native foo calledn")};
>
> };
>
> // managed.cpp
>
> class __declspec(dllimport) Native {
>
> public:
> void foo();
> }
>
> namespace managedDll
>
> {
>
> public __gc class Native {
>
> protected:
>
> // Put the line below in comment and everything works fine
>
> ::Native __nogc *unmanagedNativePtr;
>
> public:
>
> void foo() { Console::WriteLine("N::Native::foo");}
>
> };
>
> }
>
> // Class1.cs
>
> using System;
>
> using System.IO;
>
> using managedDll;
>
> namespace ConsoleApplication1
>
> {
>
> class Test
>
> {
>
> static void Main()
>
> {
>
> Native obj = new Native();
>
> obj.foo();
>
> }
>
> }
>
> }
>
> "Paul Bacelar" a écrit dans le
> de news:d4k1o0$e4e$
> > "Jerome" wrote in message
> > news:
> > > Bonjour,
> > >
> > > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > > J'utilise le managed C++ pour realiser mon assemblie .NET et appeler
mes
> > > methodes natives.
> > > Mais je suis face a un pb de namespace.
> > > * Ma classe native s'appelle ClassA et je veux que la classe dotnet
> > s'apelle
> > > pareil car ma lib est un SDK.
> > > * dans mon managed C++, je met ma nouvelle classe manage dans un
> > namespace,
> > > je fait reference a ma classe native en specifiant ::ClassA. Jusque
> > tout
> > > va bien, je genere mon assemblie.
> > > * Maintenant, je veux appeler les methodes de ma ClassA managee
> une
> > > appli C#. Je lui dis d'utiliser le namespace que je viens de creer.
> > > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait
a
> ma
> > > methode native (erreur a la compil) alors que si j'ecris
> > > mon_namespace::ClassA::myMethod() ca compile.
> > >
> > > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution ;-)
> > > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> > >
> > >
> >
> > Il y a plusieurs erreurs.
> >
> >
> >
> > - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
Cela
> > évitera les collisions de nom que vous subissez.
> >
> > - Ne pas déclarer "public" la ClassA non managé si vous ne comptez pas
la
> > rendre utilisable par d'autres clients que la classe managée ClassA.
> > Internal à la place de Public serait, à première vue, un bien meilleur
> > choix.
> >
> > - etc... a suivre ;-)
> >
> >
> > --
> > Paul Bacelar
> >
> >
>
>
Great Thanks !
Vous me sortez une grosse epine du pied !!!!
J'ai teste et ca marche.
Sinon je ne comprend pas le primo.
Est-ce que l'on ne doit pas exporter une classe dans une lib en utilisant
__declspec(dllexport) ?
Jerome.
"Paul Bacelar" a écrit dans le message
de news:
> Primo : ne jamais exporter de class.
>
>
>
> Secondo : si vous avez correctement architecturé votre projet, vous avez
une
> dll non managée pour votre SDK et un assembly comme wrapper.
>
> Votre assembly ne doit pas rendre public les classes natives qu'il
> sinon il perd sa fonction de wrapper.
>
> Pour rendre les classes natives invisibles aux utilisateurs du wrapper,
> faut ajouter " /d1PrivateNativeTypes" dans l'editBox "Options
> supplémentaires" de la rubrique "Ligne de commande" de la section
> dans les propriétés du projet de la dll managée contenant le wrapper.
>
> Manipe testée avec VS.NET 2003.
>
> J'ai appris un truc moi, aujourd'hui ;-).
>
> --
> Paul Bacelar
>
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > - Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le
probleme
> > c'est que je ne peut pas modifier mon SDK natif car il est deja
> par
> > plein d'appli.
> > - Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
> >
> > En fait c des que j'utilise :: que les problemes apparaissent (cf.
exemple
> > ci dessous). C'est un comportement plutot bizarre.
> >
> > // unmanaged.cpp
> > class __declspec(dllexport) Native
> >
> > {
> >
> > public:
> >
> > void foo() {printf("native foo calledn")};
> >
> > };
> >
> > // managed.cpp
> >
> > class __declspec(dllimport) Native {
> >
> > public:
> > void foo();
> > }
> >
> > namespace managedDll
> >
> > {
> >
> > public __gc class Native {
> >
> > protected:
> >
> > // Put the line below in comment and everything works fine
> >
> > ::Native __nogc *unmanagedNativePtr;
> >
> > public:
> >
> > void foo() { Console::WriteLine("N::Native::foo");}
> >
> > };
> >
> > }
> >
> > // Class1.cs
> >
> > using System;
> >
> > using System.IO;
> >
> > using managedDll;
> >
> > namespace ConsoleApplication1
> >
> > {
> >
> > class Test
> >
> > {
> >
> > static void Main()
> >
> > {
> >
> > Native obj = new Native();
> >
> > obj.foo();
> >
> > }
> >
> > }
> >
> > }
> >
> > "Paul Bacelar" a écrit dans le
message
> > de news:d4k1o0$e4e$
> > > "Jerome" wrote in message
> > > news:
> > > > Bonjour,
> > > >
> > > > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > > > J'utilise le managed C++ pour realiser mon assemblie .NET et
> mes
> > > > methodes natives.
> > > > Mais je suis face a un pb de namespace.
> > > > * Ma classe native s'appelle ClassA et je veux que la classe
> > > s'apelle
> > > > pareil car ma lib est un SDK.
> > > > * dans mon managed C++, je met ma nouvelle classe manage dans un
> > > namespace,
> > > > je fait reference a ma classe native en specifiant ::ClassA.
la
> > > tout
> > > > va bien, je genere mon assemblie.
> > > > * Maintenant, je veux appeler les methodes de ma ClassA managee
depuis
> > une
> > > > appli C#. Je lui dis d'utiliser le namespace que je viens de
> > > > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait
reference
> a
> > ma
> > > > methode native (erreur a la compil) alors que si j'ecris
> > > > mon_namespace::ClassA::myMethod() ca compile.
> > > >
> > > > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution
> > > > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> > > >
> > > >
> > >
> > > Il y a plusieurs erreurs.
> > >
> > >
> > >
> > > - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> Cela
> > > évitera les collisions de nom que vous subissez.
> > >
> > > - Ne pas déclarer "public" la ClassA non managé si vous ne comptez
> la
> > > rendre utilisable par d'autres clients que la classe managée ClassA.
> > > Internal à la place de Public serait, à première vue, un bien
> > > choix.
> > >
> > > - etc... a suivre ;-)
> > >
> > >
> > > --
> > > Paul Bacelar
> > >
> > >
> >
> >
>
>
Great Thanks !
Vous me sortez une grosse epine du pied !!!!
J'ai teste et ca marche.
Sinon je ne comprend pas le primo.
Est-ce que l'on ne doit pas exporter une classe dans une lib en utilisant
__declspec(dllexport) ?
Jerome.
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news:uSO4aPvSFHA.3244@TK2MSFTNGP15.phx.gbl...
> Primo : ne jamais exporter de class.
>
>
>
> Secondo : si vous avez correctement architecturé votre projet, vous avez
une
> dll non managée pour votre SDK et un assembly comme wrapper.
>
> Votre assembly ne doit pas rendre public les classes natives qu'il
> sinon il perd sa fonction de wrapper.
>
> Pour rendre les classes natives invisibles aux utilisateurs du wrapper,
> faut ajouter " /d1PrivateNativeTypes" dans l'editBox "Options
> supplémentaires" de la rubrique "Ligne de commande" de la section
> dans les propriétés du projet de la dll managée contenant le wrapper.
>
> Manipe testée avec VS.NET 2003.
>
> J'ai appris un truc moi, aujourd'hui ;-).
>
> --
> Paul Bacelar
>
> "Jerome" <jlague@mc.com> wrote in message
> news:uLW1JKkSFHA.1404@TK2MSFTNGP09.phx.gbl...
> > Bonjour,
> >
> > - Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le
probleme
> > c'est que je ne peut pas modifier mon SDK natif car il est deja
> par
> > plein d'appli.
> > - Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
> >
> > En fait c des que j'utilise :: que les problemes apparaissent (cf.
exemple
> > ci dessous). C'est un comportement plutot bizarre.
> >
> > // unmanaged.cpp
> > class __declspec(dllexport) Native
> >
> > {
> >
> > public:
> >
> > void foo() {printf("native foo calledn")};
> >
> > };
> >
> > // managed.cpp
> >
> > class __declspec(dllimport) Native {
> >
> > public:
> > void foo();
> > }
> >
> > namespace managedDll
> >
> > {
> >
> > public __gc class Native {
> >
> > protected:
> >
> > // Put the line below in comment and everything works fine
> >
> > ::Native __nogc *unmanagedNativePtr;
> >
> > public:
> >
> > void foo() { Console::WriteLine("N::Native::foo");}
> >
> > };
> >
> > }
> >
> > // Class1.cs
> >
> > using System;
> >
> > using System.IO;
> >
> > using managedDll;
> >
> > namespace ConsoleApplication1
> >
> > {
> >
> > class Test
> >
> > {
> >
> > static void Main()
> >
> > {
> >
> > Native obj = new Native();
> >
> > obj.foo();
> >
> > }
> >
> > }
> >
> > }
> >
> > "Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le
message
> > de news:d4k1o0$e4e$1@apollon.grec.isp.9tel.net...
> > > "Jerome" <jlague@mc.com> wrote in message
> > > news:eR0ORKaSFHA.3156@TK2MSFTNGP15.phx.gbl...
> > > > Bonjour,
> > > >
> > > > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > > > J'utilise le managed C++ pour realiser mon assemblie .NET et
> mes
> > > > methodes natives.
> > > > Mais je suis face a un pb de namespace.
> > > > * Ma classe native s'appelle ClassA et je veux que la classe
> > > s'apelle
> > > > pareil car ma lib est un SDK.
> > > > * dans mon managed C++, je met ma nouvelle classe manage dans un
> > > namespace,
> > > > je fait reference a ma classe native en specifiant ::ClassA.
la
> > > tout
> > > > va bien, je genere mon assemblie.
> > > > * Maintenant, je veux appeler les methodes de ma ClassA managee
depuis
> > une
> > > > appli C#. Je lui dis d'utiliser le namespace que je viens de
> > > > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait
reference
> a
> > ma
> > > > methode native (erreur a la compil) alors que si j'ecris
> > > > mon_namespace::ClassA::myMethod() ca compile.
> > > >
> > > > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution
> > > > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> > > >
> > > >
> > >
> > > Il y a plusieurs erreurs.
> > >
> > >
> > >
> > > - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> Cela
> > > évitera les collisions de nom que vous subissez.
> > >
> > > - Ne pas déclarer "public" la ClassA non managé si vous ne comptez
> la
> > > rendre utilisable par d'autres clients que la classe managée ClassA.
> > > Internal à la place de Public serait, à première vue, un bien
> > > choix.
> > >
> > > - etc... a suivre ;-)
> > >
> > >
> > > --
> > > Paul Bacelar
> > >
> > >
> >
> >
>
>
Great Thanks !
Vous me sortez une grosse epine du pied !!!!
J'ai teste et ca marche.
Sinon je ne comprend pas le primo.
Est-ce que l'on ne doit pas exporter une classe dans une lib en utilisant
__declspec(dllexport) ?
Jerome.
"Paul Bacelar" a écrit dans le message
de news:
> Primo : ne jamais exporter de class.
>
>
>
> Secondo : si vous avez correctement architecturé votre projet, vous avez
une
> dll non managée pour votre SDK et un assembly comme wrapper.
>
> Votre assembly ne doit pas rendre public les classes natives qu'il
> sinon il perd sa fonction de wrapper.
>
> Pour rendre les classes natives invisibles aux utilisateurs du wrapper,
> faut ajouter " /d1PrivateNativeTypes" dans l'editBox "Options
> supplémentaires" de la rubrique "Ligne de commande" de la section
> dans les propriétés du projet de la dll managée contenant le wrapper.
>
> Manipe testée avec VS.NET 2003.
>
> J'ai appris un truc moi, aujourd'hui ;-).
>
> --
> Paul Bacelar
>
> "Jerome" wrote in message
> news:
> > Bonjour,
> >
> > - Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le
probleme
> > c'est que je ne peut pas modifier mon SDK natif car il est deja
> par
> > plein d'appli.
> > - Mes classes natives doivent etre publiques (cf. remarque ci-dessus).
> >
> > En fait c des que j'utilise :: que les problemes apparaissent (cf.
exemple
> > ci dessous). C'est un comportement plutot bizarre.
> >
> > // unmanaged.cpp
> > class __declspec(dllexport) Native
> >
> > {
> >
> > public:
> >
> > void foo() {printf("native foo calledn")};
> >
> > };
> >
> > // managed.cpp
> >
> > class __declspec(dllimport) Native {
> >
> > public:
> > void foo();
> > }
> >
> > namespace managedDll
> >
> > {
> >
> > public __gc class Native {
> >
> > protected:
> >
> > // Put the line below in comment and everything works fine
> >
> > ::Native __nogc *unmanagedNativePtr;
> >
> > public:
> >
> > void foo() { Console::WriteLine("N::Native::foo");}
> >
> > };
> >
> > }
> >
> > // Class1.cs
> >
> > using System;
> >
> > using System.IO;
> >
> > using managedDll;
> >
> > namespace ConsoleApplication1
> >
> > {
> >
> > class Test
> >
> > {
> >
> > static void Main()
> >
> > {
> >
> > Native obj = new Native();
> >
> > obj.foo();
> >
> > }
> >
> > }
> >
> > }
> >
> > "Paul Bacelar" a écrit dans le
message
> > de news:d4k1o0$e4e$
> > > "Jerome" wrote in message
> > > news:
> > > > Bonjour,
> > > >
> > > > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > > > J'utilise le managed C++ pour realiser mon assemblie .NET et
> mes
> > > > methodes natives.
> > > > Mais je suis face a un pb de namespace.
> > > > * Ma classe native s'appelle ClassA et je veux que la classe
> > > s'apelle
> > > > pareil car ma lib est un SDK.
> > > > * dans mon managed C++, je met ma nouvelle classe manage dans un
> > > namespace,
> > > > je fait reference a ma classe native en specifiant ::ClassA.
la
> > > tout
> > > > va bien, je genere mon assemblie.
> > > > * Maintenant, je veux appeler les methodes de ma ClassA managee
depuis
> > une
> > > > appli C#. Je lui dis d'utiliser le namespace que je viens de
> > > > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait
reference
> a
> > ma
> > > > methode native (erreur a la compil) alors que si j'ecris
> > > > mon_namespace::ClassA::myMethod() ca compile.
> > > >
> > > > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution
> > > > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> > > >
> > > >
> > >
> > > Il y a plusieurs erreurs.
> > >
> > >
> > >
> > > - Ne jamais mettre de classe dans le namespace racine (ou anonyme).
> Cela
> > > évitera les collisions de nom que vous subissez.
> > >
> > > - Ne pas déclarer "public" la ClassA non managé si vous ne comptez
> la
> > > rendre utilisable par d'autres clients que la classe managée ClassA.
> > > Internal à la place de Public serait, à première vue, un bien
> > > choix.
> > >
> > > - etc... a suivre ;-)
> > >
> > >
> > > --
> > > Paul Bacelar
> > >
> > >
> >
> >
>
>
Exporter une classe, c'est faire un export en C++ et pas en C, donc pas de
<CODE>extern "C"{...}</CODE> et donc utilisation de la décoration C++ qui
n'est pas standardisée. On ne peut donc pas utiliser n'import quel
compilateur ou version de compilateur pour utiliser la dll générée mais
seulement les compilateurs qui utilisent la même décoration que le
compilateur qui a servi à générer la dll.
Avoir une dll inutilisable car elle a été compilée il y a longtemps avec
compilateur de l'époque, ou parce que l'on n'a pas plus les options
nécessaires pour utiliser les mêmes décorations dans les nouvelles
du compilateur; cela est particulièrement frustrant.
De plus, la structuration habituelle d'un .h contenant la définition d'une
classe, mélange l'interface que doit utiliser les utilisateurs de la dll
les définitions nécessaires au compilateur. L'exemple le plus frappant est
la déclaration des membres privés à une classe dans d'un fichier d'en-tête
qui sera utilisé par l'utilisateur final de la dll, qui lui n'a pas à
connaître l'existence de ces champs privés.
Un autre cas, très rigolo : vous définissez un membre privé qui sera
par une méthode défini dans le fichier d'en-tête (pas déclarer, mais en
inline). Le résultat, c'est que le code de la méthode est dans le client
la dll mais que ce client ne peut pas accéder aux membres privés de la
classe, donc vous vous retrouvez avec une dll compilable mais inutilisable
par les clients.
Il est envisageable de contourner tous les écueils, mais le travail et les
compétences nécessaires seront bien mieux exploités en utilisant des
technologies qui ciblent les problématiques d'interopérabilité objet comme
COM, ATL, CORBA, .NET.
Si vous ne voulez pas d'emmerdes, ne faite pas d'export en C++ donc pas
d'export de classes.
--
Paul Bacelar
"Jerome" wrote in message
news:
> Great Thanks !
> Vous me sortez une grosse epine du pied !!!!
> J'ai teste et ca marche.
>
> Sinon je ne comprend pas le primo.
> Est-ce que l'on ne doit pas exporter une classe dans une lib en
> __declspec(dllexport) ?
>
> Jerome.
>
> "Paul Bacelar" a écrit dans le
> de news:
> > Primo : ne jamais exporter de class.
> >
> >
> >
> > Secondo : si vous avez correctement architecturé votre projet, vous
> une
> > dll non managée pour votre SDK et un assembly comme wrapper.
> >
> > Votre assembly ne doit pas rendre public les classes natives qu'il
wrappe,
> > sinon il perd sa fonction de wrapper.
> >
> > Pour rendre les classes natives invisibles aux utilisateurs du
il
> > faut ajouter " /d1PrivateNativeTypes" dans l'editBox "Options
> > supplémentaires" de la rubrique "Ligne de commande" de la section
"C/C++"
> > dans les propriétés du projet de la dll managée contenant le wrapper.
> >
> > Manipe testée avec VS.NET 2003.
> >
> > J'ai appris un truc moi, aujourd'hui ;-).
> >
> > --
> > Paul Bacelar
> >
> > "Jerome" wrote in message
> > news:
> > > Bonjour,
> > >
> > > - Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le
> probleme
> > > c'est que je ne peut pas modifier mon SDK natif car il est deja
utiliser
> > par
> > > plein d'appli.
> > > - Mes classes natives doivent etre publiques (cf. remarque
> > >
> > > En fait c des que j'utilise :: que les problemes apparaissent (cf.
> exemple
> > > ci dessous). C'est un comportement plutot bizarre.
> > >
> > > // unmanaged.cpp
> > > class __declspec(dllexport) Native
> > >
> > > {
> > >
> > > public:
> > >
> > > void foo() {printf("native foo calledn")};
> > >
> > > };
> > >
> > > // managed.cpp
> > >
> > > class __declspec(dllimport) Native {
> > >
> > > public:
> > > void foo();
> > > }
> > >
> > > namespace managedDll
> > >
> > > {
> > >
> > > public __gc class Native {
> > >
> > > protected:
> > >
> > > // Put the line below in comment and everything works fine
> > >
> > > ::Native __nogc *unmanagedNativePtr;
> > >
> > > public:
> > >
> > > void foo() { Console::WriteLine("N::Native::foo");}
> > >
> > > };
> > >
> > > }
> > >
> > > // Class1.cs
> > >
> > > using System;
> > >
> > > using System.IO;
> > >
> > > using managedDll;
> > >
> > > namespace ConsoleApplication1
> > >
> > > {
> > >
> > > class Test
> > >
> > > {
> > >
> > > static void Main()
> > >
> > > {
> > >
> > > Native obj = new Native();
> > >
> > > obj.foo();
> > >
> > > }
> > >
> > > }
> > >
> > > }
> > >
> > > "Paul Bacelar" a écrit dans le
> message
> > > de news:d4k1o0$e4e$
> > > > "Jerome" wrote in message
> > > > news:
> > > > > Bonjour,
> > > > >
> > > > > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > > > > J'utilise le managed C++ pour realiser mon assemblie .NET et
appeler
> > mes
> > > > > methodes natives.
> > > > > Mais je suis face a un pb de namespace.
> > > > > * Ma classe native s'appelle ClassA et je veux que la classe
dotnet
> > > > s'apelle
> > > > > pareil car ma lib est un SDK.
> > > > > * dans mon managed C++, je met ma nouvelle classe manage dans un
> > > > namespace,
> > > > > je fait reference a ma classe native en specifiant ::ClassA.
Jusque
> la
> > > > tout
> > > > > va bien, je genere mon assemblie.
> > > > > * Maintenant, je veux appeler les methodes de ma ClassA managee
> depuis
> > > une
> > > > > appli C#. Je lui dis d'utiliser le namespace que je viens de
creer.
> > > > > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait
> reference
> > a
> > > ma
> > > > > methode native (erreur a la compil) alors que si j'ecris
> > > > > mon_namespace::ClassA::myMethod() ca compile.
> > > > >
> > > > > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution
;-)
> > > > > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> > > > >
> > > > >
> > > >
> > > > Il y a plusieurs erreurs.
> > > >
> > > >
> > > >
> > > > - Ne jamais mettre de classe dans le namespace racine (ou
> > Cela
> > > > évitera les collisions de nom que vous subissez.
> > > >
> > > > - Ne pas déclarer "public" la ClassA non managé si vous ne comptez
pas
> > la
> > > > rendre utilisable par d'autres clients que la classe managée
> > > > Internal à la place de Public serait, à première vue, un bien
meilleur
> > > > choix.
> > > >
> > > > - etc... a suivre ;-)
> > > >
> > > >
> > > > --
> > > > Paul Bacelar
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Exporter une classe, c'est faire un export en C++ et pas en C, donc pas de
<CODE>extern "C"{...}</CODE> et donc utilisation de la décoration C++ qui
n'est pas standardisée. On ne peut donc pas utiliser n'import quel
compilateur ou version de compilateur pour utiliser la dll générée mais
seulement les compilateurs qui utilisent la même décoration que le
compilateur qui a servi à générer la dll.
Avoir une dll inutilisable car elle a été compilée il y a longtemps avec
compilateur de l'époque, ou parce que l'on n'a pas plus les options
nécessaires pour utiliser les mêmes décorations dans les nouvelles
du compilateur; cela est particulièrement frustrant.
De plus, la structuration habituelle d'un .h contenant la définition d'une
classe, mélange l'interface que doit utiliser les utilisateurs de la dll
les définitions nécessaires au compilateur. L'exemple le plus frappant est
la déclaration des membres privés à une classe dans d'un fichier d'en-tête
qui sera utilisé par l'utilisateur final de la dll, qui lui n'a pas à
connaître l'existence de ces champs privés.
Un autre cas, très rigolo : vous définissez un membre privé qui sera
par une méthode défini dans le fichier d'en-tête (pas déclarer, mais en
inline). Le résultat, c'est que le code de la méthode est dans le client
la dll mais que ce client ne peut pas accéder aux membres privés de la
classe, donc vous vous retrouvez avec une dll compilable mais inutilisable
par les clients.
Il est envisageable de contourner tous les écueils, mais le travail et les
compétences nécessaires seront bien mieux exploités en utilisant des
technologies qui ciblent les problématiques d'interopérabilité objet comme
COM, ATL, CORBA, .NET.
Si vous ne voulez pas d'emmerdes, ne faite pas d'export en C++ donc pas
d'export de classes.
--
Paul Bacelar
"Jerome" <jlague@mc.com> wrote in message
news:elqIWS1SFHA.3184@TK2MSFTNGP09.phx.gbl...
> Great Thanks !
> Vous me sortez une grosse epine du pied !!!!
> J'ai teste et ca marche.
>
> Sinon je ne comprend pas le primo.
> Est-ce que l'on ne doit pas exporter une classe dans une lib en
> __declspec(dllexport) ?
>
> Jerome.
>
> "Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le
> de news:uSO4aPvSFHA.3244@TK2MSFTNGP15.phx.gbl...
> > Primo : ne jamais exporter de class.
> >
> >
> >
> > Secondo : si vous avez correctement architecturé votre projet, vous
> une
> > dll non managée pour votre SDK et un assembly comme wrapper.
> >
> > Votre assembly ne doit pas rendre public les classes natives qu'il
wrappe,
> > sinon il perd sa fonction de wrapper.
> >
> > Pour rendre les classes natives invisibles aux utilisateurs du
il
> > faut ajouter " /d1PrivateNativeTypes" dans l'editBox "Options
> > supplémentaires" de la rubrique "Ligne de commande" de la section
"C/C++"
> > dans les propriétés du projet de la dll managée contenant le wrapper.
> >
> > Manipe testée avec VS.NET 2003.
> >
> > J'ai appris un truc moi, aujourd'hui ;-).
> >
> > --
> > Paul Bacelar
> >
> > "Jerome" <jlague@mc.com> wrote in message
> > news:uLW1JKkSFHA.1404@TK2MSFTNGP09.phx.gbl...
> > > Bonjour,
> > >
> > > - Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le
> probleme
> > > c'est que je ne peut pas modifier mon SDK natif car il est deja
utiliser
> > par
> > > plein d'appli.
> > > - Mes classes natives doivent etre publiques (cf. remarque
> > >
> > > En fait c des que j'utilise :: que les problemes apparaissent (cf.
> exemple
> > > ci dessous). C'est un comportement plutot bizarre.
> > >
> > > // unmanaged.cpp
> > > class __declspec(dllexport) Native
> > >
> > > {
> > >
> > > public:
> > >
> > > void foo() {printf("native foo calledn")};
> > >
> > > };
> > >
> > > // managed.cpp
> > >
> > > class __declspec(dllimport) Native {
> > >
> > > public:
> > > void foo();
> > > }
> > >
> > > namespace managedDll
> > >
> > > {
> > >
> > > public __gc class Native {
> > >
> > > protected:
> > >
> > > // Put the line below in comment and everything works fine
> > >
> > > ::Native __nogc *unmanagedNativePtr;
> > >
> > > public:
> > >
> > > void foo() { Console::WriteLine("N::Native::foo");}
> > >
> > > };
> > >
> > > }
> > >
> > > // Class1.cs
> > >
> > > using System;
> > >
> > > using System.IO;
> > >
> > > using managedDll;
> > >
> > > namespace ConsoleApplication1
> > >
> > > {
> > >
> > > class Test
> > >
> > > {
> > >
> > > static void Main()
> > >
> > > {
> > >
> > > Native obj = new Native();
> > >
> > > obj.foo();
> > >
> > > }
> > >
> > > }
> > >
> > > }
> > >
> > > "Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le
> message
> > > de news:d4k1o0$e4e$1@apollon.grec.isp.9tel.net...
> > > > "Jerome" <jlague@mc.com> wrote in message
> > > > news:eR0ORKaSFHA.3156@TK2MSFTNGP15.phx.gbl...
> > > > > Bonjour,
> > > > >
> > > > > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > > > > J'utilise le managed C++ pour realiser mon assemblie .NET et
appeler
> > mes
> > > > > methodes natives.
> > > > > Mais je suis face a un pb de namespace.
> > > > > * Ma classe native s'appelle ClassA et je veux que la classe
dotnet
> > > > s'apelle
> > > > > pareil car ma lib est un SDK.
> > > > > * dans mon managed C++, je met ma nouvelle classe manage dans un
> > > > namespace,
> > > > > je fait reference a ma classe native en specifiant ::ClassA.
Jusque
> la
> > > > tout
> > > > > va bien, je genere mon assemblie.
> > > > > * Maintenant, je veux appeler les methodes de ma ClassA managee
> depuis
> > > une
> > > > > appli C#. Je lui dis d'utiliser le namespace que je viens de
creer.
> > > > > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait
> reference
> > a
> > > ma
> > > > > methode native (erreur a la compil) alors que si j'ecris
> > > > > mon_namespace::ClassA::myMethod() ca compile.
> > > > >
> > > > > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution
;-)
> > > > > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> > > > >
> > > > >
> > > >
> > > > Il y a plusieurs erreurs.
> > > >
> > > >
> > > >
> > > > - Ne jamais mettre de classe dans le namespace racine (ou
> > Cela
> > > > évitera les collisions de nom que vous subissez.
> > > >
> > > > - Ne pas déclarer "public" la ClassA non managé si vous ne comptez
pas
> > la
> > > > rendre utilisable par d'autres clients que la classe managée
> > > > Internal à la place de Public serait, à première vue, un bien
meilleur
> > > > choix.
> > > >
> > > > - etc... a suivre ;-)
> > > >
> > > >
> > > > --
> > > > Paul Bacelar
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Exporter une classe, c'est faire un export en C++ et pas en C, donc pas de
<CODE>extern "C"{...}</CODE> et donc utilisation de la décoration C++ qui
n'est pas standardisée. On ne peut donc pas utiliser n'import quel
compilateur ou version de compilateur pour utiliser la dll générée mais
seulement les compilateurs qui utilisent la même décoration que le
compilateur qui a servi à générer la dll.
Avoir une dll inutilisable car elle a été compilée il y a longtemps avec
compilateur de l'époque, ou parce que l'on n'a pas plus les options
nécessaires pour utiliser les mêmes décorations dans les nouvelles
du compilateur; cela est particulièrement frustrant.
De plus, la structuration habituelle d'un .h contenant la définition d'une
classe, mélange l'interface que doit utiliser les utilisateurs de la dll
les définitions nécessaires au compilateur. L'exemple le plus frappant est
la déclaration des membres privés à une classe dans d'un fichier d'en-tête
qui sera utilisé par l'utilisateur final de la dll, qui lui n'a pas à
connaître l'existence de ces champs privés.
Un autre cas, très rigolo : vous définissez un membre privé qui sera
par une méthode défini dans le fichier d'en-tête (pas déclarer, mais en
inline). Le résultat, c'est que le code de la méthode est dans le client
la dll mais que ce client ne peut pas accéder aux membres privés de la
classe, donc vous vous retrouvez avec une dll compilable mais inutilisable
par les clients.
Il est envisageable de contourner tous les écueils, mais le travail et les
compétences nécessaires seront bien mieux exploités en utilisant des
technologies qui ciblent les problématiques d'interopérabilité objet comme
COM, ATL, CORBA, .NET.
Si vous ne voulez pas d'emmerdes, ne faite pas d'export en C++ donc pas
d'export de classes.
--
Paul Bacelar
"Jerome" wrote in message
news:
> Great Thanks !
> Vous me sortez une grosse epine du pied !!!!
> J'ai teste et ca marche.
>
> Sinon je ne comprend pas le primo.
> Est-ce que l'on ne doit pas exporter une classe dans une lib en
> __declspec(dllexport) ?
>
> Jerome.
>
> "Paul Bacelar" a écrit dans le
> de news:
> > Primo : ne jamais exporter de class.
> >
> >
> >
> > Secondo : si vous avez correctement architecturé votre projet, vous
> une
> > dll non managée pour votre SDK et un assembly comme wrapper.
> >
> > Votre assembly ne doit pas rendre public les classes natives qu'il
wrappe,
> > sinon il perd sa fonction de wrapper.
> >
> > Pour rendre les classes natives invisibles aux utilisateurs du
il
> > faut ajouter " /d1PrivateNativeTypes" dans l'editBox "Options
> > supplémentaires" de la rubrique "Ligne de commande" de la section
"C/C++"
> > dans les propriétés du projet de la dll managée contenant le wrapper.
> >
> > Manipe testée avec VS.NET 2003.
> >
> > J'ai appris un truc moi, aujourd'hui ;-).
> >
> > --
> > Paul Bacelar
> >
> > "Jerome" wrote in message
> > news:
> > > Bonjour,
> > >
> > > - Effectivement mon SDK C++ n'utilise pas les namespaces. Mais Le
> probleme
> > > c'est que je ne peut pas modifier mon SDK natif car il est deja
utiliser
> > par
> > > plein d'appli.
> > > - Mes classes natives doivent etre publiques (cf. remarque
> > >
> > > En fait c des que j'utilise :: que les problemes apparaissent (cf.
> exemple
> > > ci dessous). C'est un comportement plutot bizarre.
> > >
> > > // unmanaged.cpp
> > > class __declspec(dllexport) Native
> > >
> > > {
> > >
> > > public:
> > >
> > > void foo() {printf("native foo calledn")};
> > >
> > > };
> > >
> > > // managed.cpp
> > >
> > > class __declspec(dllimport) Native {
> > >
> > > public:
> > > void foo();
> > > }
> > >
> > > namespace managedDll
> > >
> > > {
> > >
> > > public __gc class Native {
> > >
> > > protected:
> > >
> > > // Put the line below in comment and everything works fine
> > >
> > > ::Native __nogc *unmanagedNativePtr;
> > >
> > > public:
> > >
> > > void foo() { Console::WriteLine("N::Native::foo");}
> > >
> > > };
> > >
> > > }
> > >
> > > // Class1.cs
> > >
> > > using System;
> > >
> > > using System.IO;
> > >
> > > using managedDll;
> > >
> > > namespace ConsoleApplication1
> > >
> > > {
> > >
> > > class Test
> > >
> > > {
> > >
> > > static void Main()
> > >
> > > {
> > >
> > > Native obj = new Native();
> > >
> > > obj.foo();
> > >
> > > }
> > >
> > > }
> > >
> > > }
> > >
> > > "Paul Bacelar" a écrit dans le
> message
> > > de news:d4k1o0$e4e$
> > > > "Jerome" wrote in message
> > > > news:
> > > > > Bonjour,
> > > > >
> > > > > Je suis en train de realiser un proto d'un wrapper d'un lib C++.
> > > > > J'utilise le managed C++ pour realiser mon assemblie .NET et
appeler
> > mes
> > > > > methodes natives.
> > > > > Mais je suis face a un pb de namespace.
> > > > > * Ma classe native s'appelle ClassA et je veux que la classe
dotnet
> > > > s'apelle
> > > > > pareil car ma lib est un SDK.
> > > > > * dans mon managed C++, je met ma nouvelle classe manage dans un
> > > > namespace,
> > > > > je fait reference a ma classe native en specifiant ::ClassA.
Jusque
> la
> > > > tout
> > > > > va bien, je genere mon assemblie.
> > > > > * Maintenant, je veux appeler les methodes de ma ClassA managee
> depuis
> > > une
> > > > > appli C#. Je lui dis d'utiliser le namespace que je viens de
creer.
> > > > > * Et la surprise, quand j'ecris ClassA::myMethod(), il fait
> reference
> > a
> > > ma
> > > > > methode native (erreur a la compil) alors que si j'ecris
> > > > > mon_namespace::ClassA::myMethod() ca compile.
> > > > >
> > > > > C un cas d'ecole mais j'ai pas trouver l'exercise et sa solution
;-)
> > > > > Quelqu'un a t'il ca dans son manuel du petit wrapper dotnet ?
> > > > >
> > > > >
> > > >
> > > > Il y a plusieurs erreurs.
> > > >
> > > >
> > > >
> > > > - Ne jamais mettre de classe dans le namespace racine (ou
> > Cela
> > > > évitera les collisions de nom que vous subissez.
> > > >
> > > > - Ne pas déclarer "public" la ClassA non managé si vous ne comptez
pas
> > la
> > > > rendre utilisable par d'autres clients que la classe managée
> > > > Internal à la place de Public serait, à première vue, un bien
meilleur
> > > > choix.
> > > >
> > > > - etc... a suivre ;-)
> > > >
> > > >
> > > > --
> > > > Paul Bacelar
> > > >
> > > >
> > >
> > >
> >
> >
>
>
