Ceci est une extension d'une question que j'ai précédemment posée ici .
Longue histoire courte, je charge de manière dynamique une DLL et faire un à partir de là, je peux utiliser Je me sens comme si je manque une ligne de code clé ici qui contient le formulaire de Chargement à l'écran. Des idées? type avec le code suivant: type pour référencer pratiquement n'importe quoi dans la catégorie dlltest . La classe par défaut lorsque couramment doit afficher un formulaire (dans ce cas, assez vierge, donc ce n'est pas complexe). dlltest.cs (dans la DLL) est composé de: initializecomonent ( ) configure la mise en page du formulaire, qui est beaucoup trop longue pour coller ici et ne devrait pas faire la différence.
4 Réponses :
Vous devez faire quelque chose avec le formulaire que vous venez de créer:
Assembly assembly = Assembly.LoadFile("C:\\test.dll");
Type type = assembly.GetType("test.dllTest");
Form form = (Form)Activator.CreateInstance(type);
form.ShowDialog(); // Or Application.Run(form)
Oui, vous ne spécifiez pas de code à exécuter à l'extérieur de l'initialisateur de classe. Par exemple, avec des formulaires, vous devez les montrer réellement.
Vous pouvez modifier votre code à ce qui suit ...
J'irais avec:
Assembly assembly = Assembly.LoadFile("C:\\test.dll");
Type type = assembly.GetType("test.dllTest");
object obj = Activator.CreateInstance(type);
Form form = obj as Form;
if (form != null)
form.Show(); //or ShowDilaog() whichever is needed
Si vous voulez simplement faire le chèque NULL, la référence d'objet supplémentaire n'est pas nécessaire, vous pouvez vous débarrasser de l'OBJ et faire la forme directement sur la CreateInstance.
Selon ce que votre plan est en cas de défaillance, vous pouvez certainement le faire et éliminer une ligne de code. Mais si la vérification échoue, vous envisagez de faire / essayer autre chose avec l'objet, il doit être fait dans des lignes distinctes.
D'accord, mais dans le second cas, je pense que vous délégueriez à une approche plus pragmatique plutôt qu'une forme optimiste a été lancée, puis un commutateur de télécommandé en flèche.
Je suppose que mon point principal était de vous assurer que la vérification des erreurs a été traitée quelque part dans cette chaîne de réponse. Évidemment, le code affiché ici ne sera pas la production digne de robuste, mais je le voulais au moins mentionné à un passant à l'avenir que une forme de vérification des erreurs doit être ajoutée. Et de ne pas supposer que le type que vous avez obtenu est le type que vous pensiez que ce serait. Si vous pouvez garantir le type au moment de la compilation, pourquoi ne pas référence à l'assemblage et utiliser l'objet; sauter complètement les reflets.
Comme je l'ai dit avant .. D'accord. Souvent, le texte est si une sincérité informelle est facilement perdue.
Si une classe appartient à aussi la syntaxe doit être aussi: p> formulaire code> alors le assembly.getType () code> retourne null code>.
Si une classe appartient à contrôle de l'utilisateur code>, je peux voir que le type est renvoyé. Type type = assembly.GetType("Assemblytest.clsTest");
Crstest code> sera le nom de la classe (d'un contrôle utilisateur) li>
AssemblyTest code> est le nom de l'assemblage sans l'extension .dll. li>
ul> p>
Ce n'est pas une réponse directe à votre question, mais si vous allez faire beaucoup de ceci, vous voudrez peut-être consulter le bloc d'application composite (CAB). Sa partie de l'usine de logiciels client intelligente et peut être trouvée ici: MSDN.MicRosoft. com / fr-nous / bibliothèque / aa480482.aspx