Dans un projet VB.NET, vous pouvez utiliser l'onglet Paramètres de la page Propriétés pour définir les paramètres d'application. Pour référencer les paramètres dans le code, vous utilisez la syntaxe My.Settings.SettingName dans VB.
Dans l'onglet Paramètres, vous pouvez choisir le modificateur d'accès. Ce peut être "ami" ou "public". Vraisemblablement, lorsque vous choisissez "Public", vous rendez les paramètres accessibles à d'autres assemblages. Cependant, une fois que "public" est choisi, je ne peux pas comprendre la syntaxe pour référencer les paramètres d'un projet d'un autre. En fait, je ne peux pas observer aucune différence entre utiliser "interne" contre "public" comme modificateur d'accès.
Ma question: choisit "public" car le modificateur d'accès rend les paramètres accessibles à d'autres assemblages? Si oui, quelle est la syntaxe pour référencer les paramètres des autres assemblages? Sinon, que fait "public"?
5 Réponses :
Vous mélangez des choses plutôt mal. Un paramètre n'a pas de modificateur d'accessibilité, ils sont toujours publics. Toutefois, dans une application WinForms, vous avez en effet une propriété "Paramètres d'application" dans la fenêtre Propriétés pour un contrôle. Juste en haut. Et une propriété de modificateur. Ce dernier est ami par défaut dans un projet VB.NET, privé dans une application C #. Qui détermine l'accessibilité de la variable contrôle , pas le réglage.
Oui, my.Settings vous donne accès au paramètre qui stocke la valeur de la propriété de contrôle. Mais c'est là que se termine la bonne nouvelle. Vous devez toujours définir la portée du paramètre dans le concepteur de paramètres sur l'utilisateur. De sorte que la valeur puisse être sauvegardée et restaurée lorsque votre programme recommencent.
Les paramètres avec la portée de l'utilisateur sont stockés dans un fichier difficile à retrouver. Le chemin typique d'un tel fichier est C: \ users \ hanpsant \ Appdata \ local \ windowsformSAplication1 \._url_2acx4ldi2zmg42elj3eyq0snhqco4qe \ 1.0.0.0
La première partie est moi, l'utilisateur actuel de mon ordinateur portable. La partie bizarro du nom du chemin est un hash , une valeur unique pour le nom et la version de l'application. Et probablement quelque chose d'autre comme la phase de la lune lorsque j'ai compilé l'application. L'algorithme pour calculer ce hachait n'est pas documenté. Juste que ce sera unique à mon application et ne peut pas être piétiné par une autre application.
Et c'est le RUB, une application ne peut pas trouver les paramètres Scoped utilisateur pour une autre application. Vous devrez abandonner les paramètres si cela est important pour vous. Et remplacez-le, dites, un xmldocument dans un endroit bien connu.
Hans, merci pour la réponse. Je ne comprends pas les détails, mais je pense que je comprends la conclusion - "Une application ne peut pas trouver les paramètres Scoped utilisateur pour une autre application". Cependant, est-ce pertinent ici? Je n'essaie pas d'obtenir une application pour lire les paramètres d'une autre application; J'essaie d'obtenir un projet à lire (et à écrire à) les paramètres d'un autre projet qui références.
Oui, je pense que c'est pertinent ici, le mandain de ma réponse. Vous ne pouvez pas écrire les paramètres d'une autre application. Sauf si elles sont dans un endroit écritable que vous savez . Savez-vous où ils sont sauvés?
Je pense que vous pouvez passer une instance de votre objet de paramètres d'une DLL dans une autre DLL (dites au démarrage de l'application), puis accédez au paramètre à l'aide de la propriété d'élément de cette classe (les classes de réglage sont héritées de la classe héritée à partir d'applicationsBasebase)
'dans DLL1: Classe1 Paramètres de propriété partagéeFromanotherdll en tant qu'accordsBase ...
'dans DLL2: (fait au démarrage) Classe1.Settingsfromanotherdll = my.Settings.default
'dans DLL2 lors de l'accès des paramètres DIM Réglage en tant que chaîne = classe1.Settingsfromanotherdll.item ("réglage")
Mike, j'ai essayé quelque chose de similaire à ce que vous proposez. J'ai créé un singleton qui enveloppe efficacement les paramètres singleton et le rend public. Cela fonctionne, que le modificateur d'accès des paramètres soit défini sur "ami" ou "public". J'espérais que l'option "publique", une fois que j'ai compris son but, conduirait à une solution plus simple.
Voici un exemple de code pour obtenir la valeur du paramètre nommé Databasename code> de n'importe quel fichier .exe situé à proximité de notre application d'exécution et stockez-le dans "DBName" variable: string currentDirectory = System.IO.Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
string exeName = System.IO.Path.GetFileName(Assembly.GetExecutingAssembly().Location);
FileInfo[] fileInfos = new DirectoryInfo(currentDirectory).GetFiles("*.exe");
foreach (FileInfo fi in fileInfos)
{
if (fi.FullName == System.IO.Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)) continue;
Assembly asm = Assembly.LoadFrom(fi.FullName);
Type[] allTypes = asm.GetTypes();
foreach (Type type in allTypes)
{
if (type.Name != "Settings") continue;
Type settingsType = type;
PropertyInfo propDefault = type.GetProperty("Default");
object defaultSettings = propDefault.GetValue(null, null);
PropertyInfo piDBName = settingsType.GetProperty("DataBaseName");
string dbName = (string)piDBName.GetValue(defaultSettings, null);
break;
}
break;
}
Je cherchais la même chose, de sorte que c'est:
En C #:
[Espace de noms] .properties.settings.default. [SETNAME]
En VB:
[Espace de noms] .My.mySettings.default. [SETNAME]
La version vb.net de cela ne fonctionne pas pour moi, malgré les paramètres de l'autre projet Public . Ce que j'aimerais voir, c'est un objet de paramètres de niveau de solution; C'est un tel pita passe, disons, des informations d'identification de la connexion de base de données autour des projets.
MISE À JOUR : Ceci fait fonctionne, mais seulement si les espaces de nom du projet sont différents. Se réfère à ma réponse ailleurs. (Toutes mes excuses pour le vote en bas, mais je ne me laisserai donc pas le supprimer!)
Ceci est un peu plus délicat dans vb.net que dans C #. Ceci est principalement parce que dans VB.NET, l'espacement de nom n'est pas très important. Donc, dans une solution vb.net, il n'est pas rare - mais éventuellement pas une grande pratique - d'avoir la même racine (alias défaut) Espace de noms pour tous les projets / sous-ensembles dans une solution, par exemple:
MyNamespace.Main, MyNamespace.ClassLib1, MyNamespace.ClassLib2, MyNamespace.Common, etc.
Je pensais à l'origine que cette question s'appliquait à la VB et au C #, j'ai donc posé la question des deux langues. Cependant, je me rends compte que je me suis trompé à propos de C # - il n'y a pas de mystère sur la syntaxe là-bas (utilisez [Espace de noms] .properties.Settings.default. [SETNAME]). Je n'ai toujours pas compris la syntaxe pour VB, cependant, j'ai donc édité la question de s'appliquer uniquement à VB et je continue à rechercher une réponse pour cette langue.