Concepteur de Vue VisulStudio inaccessible [Résolu]

tservolle 28 Messages postés mardi 7 mars 2006Date d'inscription 22 janvier 2007 Dernière intervention - 23 août 2006 à 11:57 - Dernière réponse : tservolle 28 Messages postés mardi 7 mars 2006Date d'inscription 22 janvier 2007 Dernière intervention
- 24 août 2006 à 09:46
Bonjouur,
Je vous soumets un petit probleme qui m'empoisonne la vie.
Voila je travaile en .Net 1.1 avec Visual Studio 2003
Ma solution comprends environ 40 projets et j'a iun soucis depuis quelques jours, certaines des mes classes WinForms apparaissent uniquement avec l'icone C# dans l'explorateur de solution et je n'ai plus la possibilité de les ouvrirs avec le concepteurs de Vue, Je ne sais absolument pas d'ou ça peut venir, et je ne sais pas comment resoudre le probleme.

Mon code continue a compiler, mon appli fonctionne parfaitement, seulement sans le concepteur de vue je ne me voie pas faire de grosses modifs sur mes Winforms.

Quelques precisions supplémentaire : Les Classes en questions heritent toutes d'une classe qui elle même hérite de System.Windows.Forms.Form

Si quelqu'un sait ce que l'on peut faire pour resoudre ce genre de problème , ce serait super.
Merci d'avance
tservolle
Afficher la suite 

Votre réponse

15 réponses

Meilleure réponse
cs_coq 6366 Messages postés samedi 1 juin 2002Date d'inscription 2 août 2014 Dernière intervention - 23 août 2006 à 22:14
3
Merci
Salut,

L'Enterprise Library en compte 27 et Paint.NET 22 ^^

Sinon pour le problème d'accès au mode design c'est peut être comme le dit Nikoui un problème de classe abstraite quoiqu'il me semblait justement de VS2005 corrigeait ce problème.
Si c'est le cas une solution est d'utiliser des directives de précompilation pour ne pas la déclarer comme abstraite sauf pour la compilation finale avant distribution des libs.

L'autre possibilité est la perte dans le fichier projet de la valeur définissant son type (et si c'est ça il faudrait trouver la cause) :
<Compile Include= "MonForm.cs">
  Form
</Compile>
<Compile Include ="MonUserControl.cs">
  UserControl
</Compile>
<Compile Include= "MonControl.cs">
  Component
</Compile>
<Compile Include ="MaClasseNonGUI.cs">
  Code
</Compile>
(J'en oublie peut être là)

J'avais relayer une astuce pour éditer le fichier projet sous VS : Astuce : Editer les fichiers projets directement sous Visual Studio 2005
Avec un bon backup avant naturellement !

/*
coq
MVP Visual C#
CoqBlog
*/

Merci cs_coq 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 91 internautes ce mois-ci

Commenter la réponse de cs_coq
Meilleure réponse
sebmafate 4947 Messages postés lundi 17 février 2003Date d'inscription 14 février 2014 Dernière intervention - 24 août 2006 à 09:44
3
Merci
mouaip... le mieux est dans ce cas d'utiliser des outils de compilation "avancée" comme par exemple NAnt.

Sébastien FERRAND (
blog)
Consultant Indépendant
[Microsoft MVP Visual C#]

Merci sebmafate 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 91 internautes ce mois-ci

Commenter la réponse de sebmafate
sebmafate 4947 Messages postés lundi 17 février 2003Date d'inscription 14 février 2014 Dernière intervention - 23 août 2006 à 13:48
0
Merci
40 projets dans la même solution

La classe dont hérite tes formulaires est-elle dans la même assembly ? car, il est possible qu'avec autant de projet Visual Studio s'emmèle les pinceaux...

Sébastien FERRAND (
blog)
Consultant Indépendant
[Microsoft MVP Visual C#]
Commenter la réponse de sebmafate
cs_Bidou 5507 Messages postés dimanche 4 août 2002Date d'inscription 20 juin 2013 Dernière intervention - 23 août 2006 à 14:58
0
Merci
A mon avis, y'a un gros problème dans la conception quand on a 40 projets dans une solution...

VC# forever
Commenter la réponse de cs_Bidou
Nikoui 794 Messages postés vendredi 24 septembre 2004Date d'inscription 19 août 2008 Dernière intervention - 23 août 2006 à 15:11
0
Merci
Bidou >> Ca dépend, on ne peut pas forcément faire autrement, non pas pour des raisons de conception, mais à cause des outils :

Le soft sur lequel je bosse est ce qu'on pourrais appeler un "gros" soft, et il tiens actuellement sur une quarantaine de projets lui aussi. Et on a été plus ou moins "obligés" de laisser tout ca dans la même solution, car pour toute la gestion de conf, les nigthly builds, les indicateurs divers et variés, etc, ca marche tout seul avec notre appli de gestion de conf (TFS) si tout est dans la même solution, mais pas si on veux corréler plusieurs solutions....

Cela dit, dès qu'on trouvera comment faire, on se dépechera de splitter ça en plusieurs solutions...
Commenter la réponse de Nikoui
Nikoui 794 Messages postés vendredi 24 septembre 2004Date d'inscription 19 août 2008 Dernière intervention - 23 août 2006 à 15:13
0
Merci
tservolle>> est ce que la classe de base dont dérive toutes tes Forms est abstraite? et est ce que tes Forms, et en particulier cette classe "mère" contiennent une constructeur vide (sans paramètre) ?
Commenter la réponse de Nikoui
cs_Bidou 5507 Messages postés dimanche 4 août 2002Date d'inscription 20 juin 2013 Dernière intervention - 23 août 2006 à 15:17
0
Merci
Hum, je pense que certains projets sont plus avancés que d'autres, et que pour cette raison, on peut les compilés et juste ajouter une référence sur la dll, plutôt que d'importer tout le projet non? On pourrait ainsi baisser le nombre de projet pour avoir quelque chose de conceptuellement plus intéressant.
Dumoins, il me semble...

VC# forever
Commenter la réponse de cs_Bidou
Nikoui 794 Messages postés vendredi 24 septembre 2004Date d'inscription 19 août 2008 Dernière intervention - 23 août 2006 à 15:24
0
Merci
Bidou>> Tu as raison, dans le cas effectivement ou tu réutilise des projets existant (ce qui est le cas général je te l'accorde)... Mais malheureusement pour nous, on part "from scratch", et sur les 40 projets, il doit y en avoir peut 4 ou 5 qui sont plus ou moins figé, le reste est toujours en dev... Par contre c'est sur qu'on use et abuse des "load/unload project" pour alléger la solution, mais c'est au cas par cas...
Commenter la réponse de Nikoui
tservolle 28 Messages postés mardi 7 mars 2006Date d'inscription 22 janvier 2007 Dernière intervention - 24 août 2006 à 09:11
0
Merci
Merci a tous de vos reponses :
Maintenant c'est à moi de donner des détails

1./ La classe dont hérite mes forms n'est pas dans la même assembly, par contre elle est dans la même solution.
2./ Cette classe n'est pas abstraite
3./ Effectivement je sais que 40 projets c'est beaucoup, mais sur les 40 on peut dire que 30 sont vivants, et il est vrai que je n'ai pas pensé à retirer ceux qui sont finalisés à la fin de leur developpement.
L'avantage de mettre beaucoup de projets dans la meme solution est evidemment pour le debug, cela permet de debogguer toutes les couches de l'application.
En fait mon application est client Serveur et j'ai mis dans la meme solution le client et le serveur, car ils partagent certaines assembluys, voila pourquoi il y a autant de projets.
D'autre part, des que l'on veut faitre du MVC, le nombre d'assembly augmente...

4./Je travaile sous VS2003, pas sous VS 2005

5./ Dans la meme assembly, certaines fenetres fronctionne parfaitement alors que d'autres construites sur le meme shema ne fonctionne plus

tservolle
Commenter la réponse de tservolle
tservolle 28 Messages postés mardi 7 mars 2006Date d'inscription 22 janvier 2007 Dernière intervention - 24 août 2006 à 09:14
0
Merci
Et oui, elles contiennent tous un Constructeur sans parametres qui appelle uniquement le InitializeComponent() généré par le designer
tservolle
Commenter la réponse de tservolle
tservolle 28 Messages postés mardi 7 mars 2006Date d'inscription 22 janvier 2007 Dernière intervention - 24 août 2006 à 09:27
0
Merci
Ok ca ya est j'ai trouvé merci a tous et particulierement a Coq,


Voila en fait dans le fichier csproj,  certaines de mes forms etaient définis en SubType Code au lieu de Form,

Par contre, je n'ai aucune idée de la raison pour laquelle ca a ete modifié.

tservolle
Commenter la réponse de tservolle
tservolle 28 Messages postés mardi 7 mars 2006Date d'inscription 22 janvier 2007 Dernière intervention - 24 août 2006 à 09:35
0
Merci
Une autre petite question suite a vos remaques sur la taille de ma solution :
Si je sort de ma solution certaines assemblys, est il tout de meme possible de référencer une DLL debug en modedebug et une DLL release en mode release, sans qu'elle soit dans la solution ? Cela me permettrait d'avoir les infos de deboguage dans le cas ou j'ai un soucis sur une des dls que je n'aurais plus dans ma solution

tservolle
Commenter la réponse de tservolle
sebmafate 4947 Messages postés lundi 17 février 2003Date d'inscription 14 février 2014 Dernière intervention - 24 août 2006 à 09:38
0
Merci
tu peux compiler tes dll "release" avec les infos de debuggage.






 






Sébastien FERRAND
(

blog
)
Consultant Indépendant
[Microsoft MVP Visual C#]
Commenter la réponse de sebmafate
tservolle 28 Messages postés mardi 7 mars 2006Date d'inscription 22 janvier 2007 Dernière intervention - 24 août 2006 à 09:41
0
Merci
Oui d'accord mais dans ce cas, meme quand je suis en release sur mon projet en debug, ma dll possede les infos de deboggage, je souhaiterais ne pas les avoir lorsque je livre une version release a mon client

tservolle
Commenter la réponse de tservolle
tservolle 28 Messages postés mardi 7 mars 2006Date d'inscription 22 janvier 2007 Dernière intervention - 24 août 2006 à 09:46
0
Merci
Merci

tservolle
Commenter la réponse de tservolle

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.