[C#] Problème de compilation

Bonjour,

J'étais venu poster il y a une semaine et demi sur un problème de compilation. J'ai depuis cherché sans grand succès... Je vais donc vous reposer mon problème en espérant que quelqu'un puisse m'aider :)

J'ai en ma possession un fichier solution .sln qui contient dix projets. Ce que je souhaite, c'est que lors de la compilation de cette solution, tous mes projets excepté l'exécutable aillent dans un sous-dossier nommé "Common". Pour faire ça, je n'ai aucun souci, le problème intervient lors du lancement de mon exécutable qui ne se lance simplement pas.

Du coup je me demande si le problème vient réellement de ma compilation ou plutôt de mon fichier .exe qui n'arrive pas à localiser les .dll correspondantes.

En effet, j'arrive à mettre dans mon dossier "Common" deux projets, les seuls deux projets non liés (totalement libres) et dès que je passe un troisième projet (dans l'ordre de compilation) dans le dossier "Common", mon exécutable ne fonctionne plus.

Je soupçonne donc les différentes liaisons d'être l'origine de mes problèmes mais j'ignore totalement comment y remédier.

En réalité je me doute bien qu'il doit falloir spécifier quelque part sur les projets liés "Va chercher les .dll là" mais je ne sais pas comment faire. Si quelqu'un pouvait m'éclairer ce serait top :) Merci !

Olivier.

Bonjour,

Si j'ai bien compris, dans les options Générate, tu as mis la sortie dans ..\Common.
Ensuite tu as un exécutable qui utilise les librairies se trouvant dans Common. As tu bien référencer tes librairies? Vérifie dans l'explorateur de projet, dans l'onglet Référence si tes librairies ont bien le bon chemin d'accès.
Maintenant as tu des erreurs de compilation dans ta zone de sortie?
As tu fait un pas à pas pour voir où plante le logiciel?

Cdl

Citation:

---

Envoyé par Masmeta

Bonjour,

Si j'ai bien compris, dans les options Générate, tu as mis la sortie dans ..\Common.
Ensuite tu as un exécutable qui utilise les librairies se trouvant dans Common. As tu bien référencer tes librairies? Vérifie dans l'explorateur de projet, dans l'onglet Référence si tes librairies ont bien le bon chemin d'accès.
Maintenant as tu des erreurs de compilation dans ta zone de sortie?
As tu fait un pas à pas pour voir où plante le logiciel?

Cdl

---

Tout à fait. J'ai bien référencé mes librairies et elles sont le bon chemin d'accès. Je n'ai aucune erreur de compilation, seulement des avertissements. Oui, il plante au moment où je dois utiliser ma première librairie qui me définit le contexte.

Depuis mon problème a évolué et ne traite que sur un seul fichier (BOL), j'ai pu mettre toutes mes autres .dll dans Common sans aucun souci...

J'ai vraiment du mal à voir où se situe le problème.

Peux tu mettre un bout de code que l'on puisse l'analyser?

C'est quoi un fichier BOL?

Lance ton exécutable depuis la console pour avoir plus d'infos ou consulte les logs de probing du CLR (alias fusion logs).
La recherche des dépendances par le CLR suit un processus très strict et ton dossier "Common" brise ce workflow.
La solution est de spécifier dans l'app.config de ton exécutable principal un "privatePath" où ira chercher le CLR en complément des chemins standards.

Bonjour,

J'ai ajouté le probing avec le bon privatePath (donc Common) mais j'ai toujours BOL qui résiste... À peine j'y touche qu'il râle qu'il ne le trouve pas (non pas lors de la compilation hein, mais lors de l'exécution dans Visual Studio ou via le .exe). Donc je continue de chercher pourquoi.

Le BOL contient mes objets, mes collections ainsi que les classes/méthode de validation.. BOL représente une couche au sein de mon application si tu veux.

Merci pour vos réponses. :)

Ne serait-ce pas parce que BOL lui-même aurait une dépendance pas au bon endroit (pê une lib native...) ?

Dans tous les cas tu devrais avoir des logs de probing qui donneront plus d'infos, pourrais-tu les poster s'il te plait ?

Je pense que c'est parce que BOL a effectivement un problème de dépendance (mais où... ?).

Comment puis-je récupérer les logs de probing ? J'suis un nouveau-né dans le monde de C#. :3

Merci.

Pour récupérer les logs tu peux débugger et regarder l'InnerException quand ça pète parce qu'il ne trouve pas la dépendance.
Tu devrais aussi voir qch en lançant ton exécutable via la console (cmd).
Sinon tu peux activer les fusion logs, le viewer étant livré avec le SDK Windows
Enfin si c'est un souci de dépendance native tu as l'outil Dependency Walker (alias depends)

L'exception levée ici est TypeInitializationException : "Une exception a été levée par l'initialiseur de type pour 'BOL.Model.ContexteSession'." Mais j'ai bien un InnerException juste derrière...

Grosso modo il ne trouve pas la .dll que je viens de bouger manuellement dans le dossier Common.

Du coup je pense également de plus en plus à devoir changer le code mais je ne verrais pas pourquoi, et ça me dérange.

Autre souci, je dois effectuer cette opération pour les trois autres modules du programme u_u Et je rencontrerais surement le même problème.

Voilà le détail :

L'exception System.TypeInitializationException n'a pas été gérée
HResult=-2146233036
Message=Une exception a été levée par l'initialiseur de type pour 'BOL.Model.ContexteSession'.
Source=BOL
TypeName=BOL.Model.ContexteSession
StackTrace:
à BOL.Model.ContexteSession.set_Application(String value)
à GRCPLUS.App.OnStartup(StartupEventArgs e) dans F:\DEV_BE\GRC.NET_8\ERP\GRCPLUS\GRCPLUS\App.xaml.cs:ligne 36
à System.Windows.Application.<.ctor>b__1(Object unused)
à System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
à MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
à System.Windows.Threading.DispatcherOperation.InvokeImpl()
à System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
à System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
à System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
à System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
à System.Windows.Threading.DispatcherOperation.Invoke()
à System.Windows.Threading.Dispatcher.ProcessQueue()
à System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
à MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
à MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
à System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
à MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
à System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
à MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
à MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
à System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
à System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
à System.Windows.Threading.Dispatcher.Run()
à System.Windows.Application.RunDispatcher(Object ignore)
à System.Windows.Application.RunInternal(Window window)
à System.Windows.Application.Run(Window window)
à System.Windows.Application.Run()
à GRCPLUS.App.Main() dans F:\DEV_BE\GRC.NET_8\ERP\GRCPLUS\GRCPLUS\obj\x86\DebugSTWPF\App.g.cs:ligne 0
à System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
à System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
à Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
à System.Threading.ThreadHelper.ThreadStart_Context(Object state)
à System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
à System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
à System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
à System.Threading.ThreadHelper.ThreadStart()
InnerException: System.IO.FileNotFoundException
HResult=-2147024894
Message=Fichier introuvable.
Source=Microsoft.VisualBasic
StackTrace:
à Microsoft.VisualBasic.Interaction.Shell(String PathName, AppWinStyle Style, Boolean Wait, Int32 Timeout)
à BOL.Model.ContexteSession..cctor() dans F:\DEV_BE\GRC.NET_8\BOL\BOL\Model\ContexteSession.cs:ligne 271
InnerException:


Désolé pour la pavé ^^

Ah ce n'est pas forcément une dépendance binaire mais peut être une autre ressource (e.g. un fichier de conf).
Que fait le code dans le constructeur static de ta classe ContexteSession ?
Note que si tu as des initialiseurs de membres static ça fait aussi partie au final du constructeur static.

Il doit y avoir un chemin relatif pointant à côté de la DLL vers une ressource qui n'a pas été copiée dans "Common".

Que fait le code dans le constructeur static de ta classe ContexteSession ?

Principalement des initialisations de variables :
- Contexte = new Contracts.ContexteSession();
- Un try/catch
- Et toute une série de "Dossier = "XXXXXX""...

Note que si tu as des initialiseurs de membres static ça fait aussi partie au final du constructeur static.
Il doit y avoir un chemin relatif pointant à côté de la DLL vers une ressource qui n'a pas été copiée dans "Common".

Yup je cherche, je cherche mais toujours sans succès...

Merci.

Haha ! J'ai trouvé. Pour les suivants, si jamais un problème du même genre vous arrive...

J'ai simplement un System.Reflection.Assembly.GetExecutingAssembly().Location qui me prenait en compte le dossier Common que j'ai crée et donc mon chemin n'était pas bon. Je l'ai donc modifié en System.Reflection.Assembly.GetEntryAssembly().Location.

Un grand merci à Pragmateek pour ta patience et tes réponses car c'est grâce à toi que j'ai pu trouver, tu m'as mis sur la bonne piste. ;)

En effet le GetExecutingAssembly revient à être relatif à l'assembly courant et GetEntryAssembly te donne la "racine", i.e. l'assembly contenant le point d'entrée de ton application.

Content d'avoir pu t'aider. :)