Concepteur de Vue VisulStudio inaccessibleRésolu

Question

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

cs_coq · Accepted Answer

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) : Form UserControl Component Code (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 */

sebmafate · Answer

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#]

cs_Bidou · Answer

A mon avis, y'a un gros problème dans la conception quand on a 40 projets dans une solution...

 VC# forever

Nikoui · Answer

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...

Nikoui · Answer

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) ?

cs_Bidou · Answer

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

Nikoui · Answer

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...

tservolle · Answer

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

tservolle · Answer

Et oui, elles contiennent tous un Constructeur sans parametres qui appelle uniquement le InitializeComponent() généré par le designer
tservolle

tservolle · Answer

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

tservolle · Answer

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

sebmafate · Answer

tu peux compiler tes dll "release" avec les infos de debuggage.






 






Sébastien FERRAND
 (

blog
)
Consultant Indépendant
[Microsoft MVP Visual C#]

tservolle · Answer

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

sebmafate · Answer

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#]

tservolle · Answer

Merci

tservolle

Concepteur de Vue VisulStudio inaccessible

15 réponses

Votre réponse

Discussions similaires