Impossible de charger le type "nom du control" partir de l'assembly '"nom de l'Résolu

Question

Bonjour à tous,

j'ai un petit soucis avec une solution multi projet.

ma solution possède 40 projets distinct. Jusque là, aucun problème.

tout le projet compile parfaitement, avec aucune erreur et très peu de warning, mais rien de critique.

Par contre lors de l'exécution, j'appel un userControl qui se situe dans une DLL et à chaque fois, ça m'affiche:
Impossible de charger le type 'LanguageStudio.cboChangeLangue' à partir de l'assembly 'LanguageStudio, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

Si je fait un rebuild du projet LanguageStudio, aucun problème à la prochane exécution.

Par contre, j'encripte mes EXE avec .Net Reactor pour éviter la décompilation et pour me faire chier, le message d'erreur reviens de nouveau, mais là, plus aucun moyen de recompiler le language studio.

J'ai essayé de monter la priorité de compilation, de supprimer la référence et la recréer, mais ça n'a rien changé.

Quelqu'un aurait une idée de la raison que la DLL a de la misère a charger le premier coup si on ne la compile pas séparément ???

Merci 
------------------------------------------------- 
Dragon alias aussi Waxime mais bon, pas le gout de refaire un nouveau profil lol 
-------------------------------------------------

cs_dragon · Accepted Answer

voici la solution
deleter le projet défectueux
rebuild
ajouter un nouveau projet existant
refaire les référence

ça devrait être bon, j,ai fais des comparaisons de fichier, les fichiers de a solution sont identique, juste l'ajout du projet qui n'est plus situé au même endroit dans le sln

le bug est transmit à microsoft

------------------------------------------------- 
Dragon alias aussi Waxime mais bon, pas le gout de refaire un nouveau profil lol 
-------------------------------------------------

gillardg · Answer

bizare autant qu'étrange en effet as tu essayé de modifier l'ordre dans lequel le build se fait ??

Bonjour chez vous !

cs_dragon · Answer

oui j,ai essayé de le devancé, ça a rien changé

voici un bout du stacktrace
   à Solution_Intégree_Softicket_SIS.frmAuthentification.InitializeComponent()
   à Solution_Intégree_Softicket_SIS.frmAuthentification..ctor() dans C:\Programmation\Logiciel\SofticketV4.0\softicketSIS\InterfaceAdministrationSofticket\FormulaireAuthentification\frmAuthentification.vb:ligne 12

------------------------------------------------- 
Dragon alias aussi Waxime mais bon, pas le gout de refaire un nouveau profil lol 
-------------------------------------------------

cs_dragon · Answer

je viens d'effectuer un autre test, si ça peut aider
j'ai mis un break point au InitializeComponent()

en suivant les indications du stacktrace. Je me rend jusque là, mais si je fais aller à la ligne suivante, là j'ai l'erreur, j'ai bien sur désactivé le DebuggerStepThrough

Donc je ne rentre même pas dans le InitializeComponent()

------------------------------------------------- 
Dragon alias aussi Waxime mais bon, pas le gout de refaire un nouveau profil lol 
-------------------------------------------------

gillardg · Answer

et si tu le compile à part ça fonctionne  
60 prj dans une solution il est possible que visual studio s'emmele les pinceaux

Bonjour chez vous !

cs_dragon · Answer

pas 60 mais 40, dont 10 de déchargé qui n'ont aucun lien

lol on va rire là
j'ai fais une cherche sur la variable my.Application.Info.LoadedAssemblies
Voici ce que j'ai trouvé


<hr />
(40) {System.Reflection.Assembly} System.Reflection.AssemblyCodeBase "[file:///C:/Programmation/Logiciel/SofticketV4.0/Build/LanguageStudio.DLL file:///C:/Programmation/Logiciel/SofticketV4.0/Build/LanguageStudio.DLL]"
EntryPoint Nothing System.Reflection.MethodInfo
EscapedCodeBase "[file:///C:/Programmation/Logiciel/SofticketV4.0/Build/LanguageStudio.DLL file:///C:/Programmation/Logiciel/SofticketV4.0/Build/LanguageStudio.DLL]"
Evidence {System.Security.Policy.Evidence} System.Security.Policy.Evidence
FullName "LanguageStudio, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
GlobalAssemblyCache False
HostContext 0
ImageRuntimeVersion "v2.0.50727"
Location "C:\Programmation\Logiciel\SofticketV4.0\Build\LanguageStudio.dll"
ManifestModule {System.Reflection.Module} System.Reflection.Module
ReflectionOnly False

------------------------------------------------- 
Dragon alias aussi Waxime mais bon, pas le gout de refaire un nouveau profil lol 
-------------------------------------------------

cs_dragon · Answer

ouin, je crois que je vais aller poster ça sur Microsoft Connect

------------------------------------------------- 
Dragon alias aussi Waxime mais bon, pas le gout de refaire un nouveau profil lol 
-------------------------------------------------

gillardg · Answer

bonne idée mais tu paux aussi avoir de laide de pas mal de monde sur 

microsoft.public.fr.dotnet.vb   ( français )
microsoft.public.dotnet.languages.vb   ( english )
qui se trouve sur le serveur NNTP       msnews.microsoft.com

Bonjour chez vous !

Kevin.Ory · Answer

Salut,
40 projets dans une solution, c'est pas mal :-)

"très peu de warning, mais rien de critique."
Mouais... pas besoin d'avoir un "warning critique" pour avoir un gros problème par la suite... je te conseil de tous les éliminer pour éviter les mauvaises surprises. Ce ne devrait pas être difficile, le compilateur VB.NET est assez débrouillard pour ne pas trop nous emmerder ^^

D'après tes tests, il semblerait donc que le problème surviennent dans InitializeComponent, autrement dis lors de l'initialisation de tes contrôles.
La 1ère chose à faire est de cerner le problème. Créé un nouveau projet vide, mets-y ton LanguageStudio.cboChangeLangue et debug, car une erreur ne vient pas "juste pour faire chier" :-D

"Donc je ne rentre même pas dans le InitializeComponent()"
J'en doute fort. Si tu bug sur un appel de procédure, c'est pas un problème de code mais de PC ;p

J'ai pas très bien compris quand ton prog bug et quand il fonctionne, mais ce que je peux dire c'est que dans une solution multi-projet, il faut toujours refaire une compilation/génération complète avant de lancer en mode debug. J'ai plusieurs fois constaté que les changements ne sont pas pris en compte si on ne le fait pas.

Il n'est pas difficile de faire un contrôle qui provoque une exception lors de l'initialisation. Il n'y a pas que la Sub New du contrôle qui est appelé dans InitializeComponent(), mais il y a aussi les valeurs appliquées aux propriétés du contrôle qui lance du code. 
Par exemple: 
- Tu fais un contrôle qui accède à une base de donnée lorsque son texte change. 
- Dans InitializeComponent() le designer fait :
MonControl.Text = ""
MonControl.Dataset Me.MonDataset
> Bug, car la base de données n'est pas encore accessible lorsque le texte du contrôle change la 1ère fois. (il faut faire un If Me.Dataset IsNot Nothing dans TextChanged)

Fais un pas à pas dans le code d'initialisation de ton contrôle qui bug et trouve la ligne exacte qui provoque une erreur.


Ben bon voilà en gros, sans plus d'infos je ne sais quoi ajouter d'autre :-)

Bonne chance

Kevin.Ory · Answer

Mmh... un bug de VS?
Si les fichiers sont identique, je crains que ça ne change rien à ton problême. A moins que le problème vienne de ton sln lui-même...

Impossible de charger le type "nom du control" partir de l'assembly '"nom de l'

10 réponses

Votre réponse

Discussions similaires