j’ai un composant (System.ComponentModel.Component) et je cherche à ce qu’il récupère le chemin de l’application sur laquelle il est déposé en design time. Ce dont je me rapproche le plus est en utilisant la méthode GetAssemblyPath.
[code] // This method uses the ITypeResolutionService.GetPathOfAssembly
// method to display the path of the executing assembly.
private void GetPathOfAssembly()
{
if (this.relatedDesigner.typeResService != null)
{
System.Reflection.AssemblyName name =
System.Reflection.Assembly.GetExecutingAssembly().GetName();
MessageBox.Show(
this.relatedDesigner.typeResService.GetPathOfAssembly(name),
"Path of executing assembly");
}
}[/code]
Ca va te retourner le chemin de visual studio ca… pas le projet. Cela dit sans comprendre ce que tu veux faire a la base c’est dur de t’aider parceque je vois pas une bonne raison pour ca comme ca la a froid…
Mais pourquoi faire ???
Tu veux pas plutot rajouter un fichier au projet ? (c’est pas la meme chose hein, poser un fichier dans le repertoire d’un projet ne le fait pas participer au processus de build).
Si tu veux faire ca, faut faire un peu d’interop avec Visual Studio (mais attention, terrain glissant spotted, faut bien separer le code DesignTime dans une assembly a part et eviter de referencer des assemblies d’interop VS @ runtime).
[quote=« girafologue, post:5, topic: 50933 »]Mais pourquoi faire ???
Tu veux pas plutot rajouter un fichier au projet ? (c’est pas la meme chose hein, poser un fichier dans le repertoire d’un projet ne le fait pas participer au processus de build).
Si tu veux faire ca, faut faire un peu d’interop avec Visual Studio (mais attention, terrain glissant spotted, faut bien separer le code DesignTime dans une assembly a part et eviter de referencer des assemblies d’interop VS @ runtime).[/quote]
En fait mon composant récupère un fichier xml « principal » (dont le chemin est défini et connu) et doit le copier (d’où la création du fichier) dans le répertoire du projet. Le composant modifiera uniquement le fichier copié.
Le contexte :
Le composant sert à "appliquer et « sauvegarder » une « personnalisation ». Si le developpeur souhaite que l’utilisateur final de la form puisse sauvegarder certaines propriétés des contrôles d’un formulaire ( dans le cas d’un formulaire avec beaucoup de champs par exemple…), il utilise alors ce composant.
Par défaut le composant est pré-défini pour sauvegarder certains contrôles avec certaines propriétés,
par exemple :
le composant va prendre en compte la propriété Text du contrôle nommé tbxNomClient, la propriété ForeColor du contrôle nommé tbxPrenomClient etc. Ce paramétrage est défini dans le fichier xml « principal » histoire que le dev ne se retape pas tout le composant à configurer à chaque fois. Mais le dev doit pouvoir rajouter ou supprimer des entrées dans le paramétrage de son appli.
Euh ouais par contre ca me semble foireux niveau integration avec le source control (si le fichier ne fait pas partie du projet, VS ne l’archivera pas automatiquement sur une operation de Check-in).
[quote=« GloP, post:8, topic: 50933 »]J’ai lu en diagonale, mais il me semble qu’il y a deja des mechanismes integres au designer pour faire ce genre de choses en plus.
Le problème c’est que les applis développées par les dev qui devront utiliser ce composant ne s’appuient pas du tout sur les configurations settings standard .NET (UserScope, ApplicationScope, MachineScope etc…) ce qui fait que du coup si j’utilise ça, je me demande si je ne vais pas perdre plus de temps à écrire la glue qui fera correspondre les applications settings avec la façon dont les confs des applis sont gérées.
Pas d’idée pour récupérer le chemin du projet ? en attendant j’ai contourné en ajoutant une propriété que le dév devra renseigner
