6
votes

Y compris une DLL en tant que ressource intégrée dans un projet WPF

Je suis http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-from-clr-via-c- troisième édition.aspx

J'ai ajouté wpfoolkit.extend.dll à ma solution et définir son action de construction sur la ressource intégrée. p>

in app.onstartup (startupeventargs e) i avoir le code suivant: p> xxx pré>

Le débogueur frappe deux fois ce bloc de code. p>

première fois: P>

resourceName is "AssemblyLoadingAndReflection.WPFToolkit.Extended.resources.dll"
assemblyName is "StatusUtil, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
stream is null


0 commentaires

5 Réponses :


8
votes

Vous devez modifier la chaîne "assemblageyloxadingandreflet" code> au nom de votre assemblage d'application.

Une chose que vous pouvez faire pour rendre ce code plus générique en utilisant une nouvelle réflexion: P >

Assembly.GetExecutingAssembly().FullName.Split(',').First()


11 commentaires

Avez-vous placé la DLL dans un dossier?


Non, c'est à la base du projet.


Je ne comprends pas votre réponse. Je fais String ResourceName = Assembly.getexecutingAssemblage (). Fullname.split (','). Premier () + "." + nouveau nom de montage (arguments) .name + ".dll"; qui me fait "statu quair.wftoolkit.extend.resources.dll", mêmes symptômes. Que devrait-il réellement être uname, dans son intégralité?


Ce chemin regarde correctement, mais le fichier de vos ressources doit être adapté à cela, c'est-à-dire que c'est le nom de ce nom devrait être wpfoolkit.extend.resources.dll .


Renommer la DLL semble fonctionner dans ce bloc de code, mais provoque des problèmes ailleurs. XMLNS: ExtToolKit = "Espace CLR-NAMES: Microsoft.Windows.Controls; Un ssembly = wpfoolkit.e xtuded" utilisé pour fonctionner dans MAINWINDOW.XAML, mais pas maintenant, et non plus, et non plus < Code> XMLNS: ExtToolKit = "Espace CLR-NAMPS: Microsoft.Windows.Controls; Un SSEMBLY = WPFOOLKIT.E XTELD.RESOURCES"


En essayant cela moi-même, dans l'exception interne, la propriété FusionLog est la querelle sur la nécessité du nom pleinement qualifié de l'Assemblée. Comme c'est tard et je suis fatigué, je ne suis pas sûr que je suis sur la bonne voie du tout, mais vous pouvez peut-être faire quelque chose avec cette information.


@ePalm: Ensuite, vous devez nettoyer ces endroits, le fichier doit avoir le nom de l'assemblage qu'il contient.


C'est ce que je dis que je dis, assembly = wpfoolkit.extendé utilisé pour fonctionner, et non non plus assemblage = wpfoolkit.extendued.resources . Je ne suis pas sûr de quoi mettre d'autre à cet attribut XMLNS.


Je viens de mangler la corde dans AppDomain.CurrentDomaine.assemblyResolve's Lambda pour correspondre au nom de la DLL. Je ne sais pas pourquoi Ags.Name contient / ajoute ".Resources" à l'Assemblée qu'il souhaite charger. Cela semble fonctionner: assemblage de montage = assemblage.getexecutingassemblage (); String AssemblyName = assemblage.fulname.split (','). Premier (); String ResourceName = nouveau nom de montage (arg.name) .name.replace (". Ressources", ""); Chemin de chaîne = string.format ("{0}. {1} .dll", montageName, Resourcename);


Je n'ai pas eu de problèmes avec cela, mais si cela peut toujours localiser le dossier, je suppose, même si je le ferais l'inverse.


Les problèmes apparaissent dès qu'il y a un fichier "resources "dans les manifestresourcefiles. Je ne peux pas régler ceux-ci à compiletype = IncréddedResource, je ne peux pas trouver ceux de la liste des getManifestresourcensames, changeant le nom sur .dll.resources ne m'aida pas non plus à lire dans ceux-ci. Aussi l'App.Main.Namespace est quelque chose que je ne peux pas gérer.



2
votes

La réponse de h.B. n'est en fait pas tout à fait juste. Le préfixe dont nous avons besoin n'est pas le nom de l'Assemblée, mais l'espace de noms par défaut du projet. Ceci est probablement impossible d'obtenir toutement de manière fiable, mais le code suivant serait beaucoup plus fiable que de supposer que le nom de l'Assemblée est identique à celui de l'Assemblée.

Assembly thisAssembly = Assembly.GetEntryAssembly();
String resourceName = string.Format("{0}.{1}.dll",
    thisAssembly.EntryPoint.DeclaringType.Namespace,
    new AssemblyName(args.Name).Name);


0 commentaires

2
votes

La réponse de Nathan Philip a travaillé comme un charme pour moi ..

C'est toute la méthode qui a fonctionné pour moi (et cela fonctionne pour plusieurs dlls également) xxx


0 commentaires

0
votes

J'ai essayé toutes les réponses ci-dessus et ils n'ont pas travaillé pour moi. J'ai trouvé ce post et ça a fonctionné comme un charme.

POST: http://www.digitallyCreated.net/blog/61/communication-Multiple-assemples-into-a-single-exe-for-a-wpf-application

J'ai trouvé que le fichier .csproj doit également être édité. Le poteau explique comment tout faire.


0 commentaires

0
votes

J'ai une explication complète de la manière de charger dynamiquement des assemblages intégrés dans Stackoverflow Question VB.NET DLL intégré dans une autre DLL sous forme de ressource intégrée?


0 commentaires