Assembleurs .NET Designer, erreur C++ \ C#

Question

Je travaille sur une application de conception lourde (en utilisant Visual C++ 2.0, mais une solution C# devrait toujours être pertinente). Ma configuration est la suivante:

J'ai un UserControl nommé « hôte » Je tente un UserControl nommé « enfant »

enfant contient une propriété à une classe dont le type est défini dans une dll totalement différent, le nom "mytools.dll"

Enfant fonctionne très bien dans le concepteur. Cependant, quand je vais traîner « enfant » sur « hôte » du concepteur, je reçois l'erreur suivante:

Failed to create component 'Child'. The error message follows: 'System.io.filenotfoundexception: could not load file or assembly MyTools, Version XXXXXX, Culture=neutral 
..... 
{unhelpful callstack} 

Si je commente la propriété « enfant » qui pointe vers la classe mytools.dll , tout dessine juste Peachy. J'ai la propriété marquée par « Browsable (faux), et DesignerSerializable (caché), et il ne vous aide pas.

est-il un moyen pour moi de dire explicitement » Ne pas charger ce dll, vous aurez pas besoin dans le temps de conception », ou d'une façon pour moi de forcer une dll à charger du concepteur programme?

Merci!

Answer 1

Si la propriété est marquée 'public', le UserControl force le concepteur à charger l'assembly externe.

Vous devez retravailler votre contrôle pour renvoyer l'objet au lieu du type incorrect, et faire un typage si vous devez le garder public, sinon, la protection devrait être bonne.

Answer 2

UserControl possède une propriété DesignMode, mais je ne suis pas sûr si .NET veut résoudre le type à l'avance (c'est-à-dire retourner null si DesignMode == true)

Sinon, si vous êtes le seul développeur, vous pouvez gérer le domaine d'application.CurrentD événement omain.AssemblyResolve et chargez un assemblage factice vous-même.

Answer 3

Non, il y a un problème de poule et d'oeuf ici. Afin de trouver les attributs que vous avez appliqués, le concepteur doit utiliser Reflection pour charger le type. Le chargement du type nécessite également le chargement de tous les types utilisés par ses membres. Ce qui amènera le CLR à aller chercher votre assembly mytools.dll.

Le chemin de sondage en vigueur au moment du design est celui de Visual Studio, pas celui de votre application. Qu'est-ce que ce chemin ressemble est obscur pour moi. La boîte à outils joue également un rôle. Il crée une copie de l'assembly qui contient le contrôle dans un répertoire privé. L'emplacement à rechercher est c: \ users \ votrenom \ appdata \ local \ microsoft \ visualstudio \ 9.0 \ projectassemblies. Cela se passe souvent mal et des copies parasites sont laissées dans ce répertoire. Je dois le nettoyer à la main de temps en temps quand je remarque que l'initialisation de la boîte à outils commence à ralentir.

Eh bien, quelque chose que vous pouvez vérifier pour voir si une copie de mytools.dll est également présente et n'est pas une ancienne version. Mettre le GAC est un moyen de ne pas avoir de problèmes.