Discussion :

[cboun94]

Bonjour tout le monde,

Mon problème est dans le titre : je veux créer une instance d'un type sans appeler le constructeur.

Il me semble que cela est possible depuis la version 2.0 du framework, mais pas moyen de remetre la main sur cette info ...

Pour info, aucune méthode de la classe Activator ne marche, et les méthode d'Assembly ou AppDomain utilise les même méthode que Activator ...

Bref je suis sûr de l'avoir vu quelque part, mais où ....

Merci d'avance.

[despeludo]

Je ne suis pas sûr de bien comprendre ta question. Que cherches-tu réellement à faire ?
- Utiliser des methodes d'une classe sans appeler de constructeur (méthodes statiques) ?
- Instancier un objet en utilisant la réflexion ?
- Autres ?

[smyley]

Peut être en chargeant l'assembly que pour de la reflection ... au moin là aucun code ne sera exécuté :
http://msdn2.microsoft.com/en-us/library/0et80c7k.aspx

[Thomas Lebrun]

Je doute que ce soit possible et en même temps, c'est normal. En effet, tu eux créer une instance d'un type donné. En .NET, créer une instance d'un type, tu dois passer par un constructeur, même si celui-ci est privé.

[Greybird]

Je doute que ce soit possible et en même temps, c'est normal. En effet, tu eux créer une instance d'un type donné. En .NET, créer une instance d'un type, tu dois passer par un constructeur, même si celui-ci est privé.

Il existe un certain nombre de mécanismes qui créent un type sans appeler le constructeur.
L'exemple le plus évident est sans doute le sérialiseur binaire, ce qui pourrait éventuellement s'expliquer par une implémentation particulière non dépendante des fonctionnalités du framework.
En revanche, le serialiseur DataContract effectue bien une construction d'objet sans appel au constructeur, comme décrit sur la page du MSDN Using Data Contracts

La construction d'un tel objet doit se faire par quelque chose comme ça : http://msdn2.microsoft.com/en-us/lib...zedobject.aspx

[cboun94]

Bonjour à tous,

Merci pour vos réponses !

La méthode "FormatterServices.GetUninitializedObject" donne à peu près ce que je voulais.

Je reste persuadé d'avoir vu dans un webcast une autre façon de faire, mais tant que ça marche ... ça marche

Pour les explications (que je n'ai pas fournies au début ... ), je souhaite avoir un comportement analogue au designer de VS : alors ce n'est peut être pas la méthode utilisée dans VS, mais je pensais
1/ Créer une instance.
2/ Appeler une seule méthode d'initialisation (parmie d'autres)
==> Tester l'effet d'une méthode sur un objet (sachant que toutes les méthodes appelées dans le constructeur ne m'intéresse pas, que je ne peux/veux pas modifier le code, et qu'il n'y a pas de constructeur sans paramètre)

Tout cela "automatiquement" sur pas mal de classe : donc "le banc de test d'objet" de VS 2005 ne m'intéresse pas trop

Merci tout le monde

[Thomas Lebrun]

Il existe un certain nombre de mécanismes qui créent un type sans appeler le constructeur.
L'exemple le plus évident est sans doute le sérialiseur binaire, ce qui pourrait éventuellement s'expliquer par une implémentation particulière non dépendante des fonctionnalités du framework.
En revanche, le serialiseur DataContract effectue bien une construction d'objet sans appel au constructeur, comme décrit sur la page du MSDN Using Data Contracts

La construction d'un tel objet doit se faire par quelque chose comme ça : http://msdn2.microsoft.com/en-us/lib...zedobject.aspx

Certes, mais dans la plupart des cas ordinaires, il faut passer par un constructeur pour instancier un type: cela nous permet d'affecter les valeurs par défaut, etc...

[Louis-Guillaume Morand]

ca ne correspondrait pas à cela:
http://lgmorand.developpez.com/dotnet/framework2/#L2.4
?

edit: bon ca correspond pas à ce que tu veux faire. j'ai rien dit

[Greybird]

Certes, mais dans la plupart des cas ordinaires, il faut passer par un constructeur pour instancier un type: cela nous permet d'affecter les valeurs par défaut, etc...

Je n'ai pas dit le contraire
Je répondais juste à ton affirmation indiquant que la création d'un type imposait le passage dans un constructeur. En l'occurrence, c'est erroné, mais il est évident que passer outre les constructeurs ne doit se faire que dans des cas précis, et en maîtrisant parfaitement les conséquences.