Je crée une application console dans Visual Studio 2010 avec c #. Je veux que cette application soit autonome, en ce sens que tout ce dont vous avez besoin est l'exécutable et que vous pouvez l'exécuter n'importe où. Je souhaite également utiliser app.config pour stocker des chaînes de connexion, etc.
Mon problème est que je n'arrive pas à comprendre comment inclure ces données app.config dans l'exécutable compilé. Je vois qu'il crée appname.exe.config, mais je ne veux pas que les gens aient à s'inquiéter de la saisie de deux fichiers distincts lorsqu'ils obtiennent l'application.
Aucune des recherches que j'ai faites n'a abouti à rien. Est-ce seulement possible?
Tu ne peux pas. La moitié de ces fichiers de configuration est d’autoriser les modifications de la configuration de l’application en dehors de celle-ci.
Vous devez simplement modifier votre programme pour qu'il ne dépende pas du fichier de configuration de l'application. Le moyen le plus simple consiste à coller les valeurs de votre configuration dans des variables globales en lecture seule.
Je peux voir où vous allez avec cela, mais la réponse pourrait être un peu plus compliquée que vous ne le cherchiez.
De cette façon, vous avez des valeurs par défaut raisonnables que vous n'avez pas besoin de maintenir séparément de votre app.config en tant que constantes, vous pouvez exécuter votre application en tant qu'exe, et vous pouvez toujours la modifier à l'exécution en l'ajoutant dans le fichier app.config. .
Une chose à garder à l'esprit est que lire dans app.config à partir d'une ressource ne vous donnera pas le même comportement que l'app.config normal. Vous le lisez et l’utilisez à la main.
Vous voulez dire que vous devez l'ajouter à l'exe en tant que ressource? Tout d’abord, vous ne pouvez pas, app.config est basé sur un fichier et non sur une ressource.
D'autre part, le seul point de fichier de configuration est que vous pouvez le changer. Sinon, utilisez simplement des codes ou des constantes.
En règle générale, vous ne souhaitez pas procéder ainsi car votre application.config fournit un mécanisme permettant la configuration au moment de l'exécution. En ce qui concerne votre objectif spécifique (maintenir la configuration en dehors de votre code, mais le faire suivre le binaire), vous avez deux options:
Je suis sûr qu'il existe d'autres options plus créatives. Ma recommandation serait pour la deuxième option. Lorsque l'application est lancée pour la première fois, créez les clés nécessaires et définissez leurs valeurs par défaut à partir de l'exécutable. Ainsi, si vous avez besoin de déboguer à une date ultérieure, vous pouvez simplement exécuter regedit et apporter les modifications nécessaires sans recompiler.
Comme d'autres l'ont souligné, l'idée d'un fichier de configuration est d'éviter les valeurs codées en dur.
Vous pouvez également créer une section de configuration personnalisée, avec chaque élément optionnel et ses valeurs par défaut. De cette façon, toute personne qui peut se débrouiller avec les valeurs par défaut n'a pas besoin d'un fichier de configuration. Mais s’ils doivent remplacer un paramètre par défaut, ils peuvent en fournir un.
(Désolé, juste un peu de brainstorming. Je n'ai pas d'exemple disponible.)
La meilleure solution de contournement consiste à la créer vous-même au démarrage de l'application.
Exemple de code:
Program.cs
[STAThread]
static void Main()
{
CreateConfigIfNotExists();
}
private static void CreateConfigIfNotExists()
{
string configFile = string.Format("{0}.config", Application.ExecutablePath);
if (!File.Exists(configFile))
{
File.WriteAllText(configFile, Resources.App_Config);
}
}
Rappelez-vous qu'il n'écrira que votre configuration actuelle lors de la construction. Il ne le mettra pas à jour automatiquement lorsque vous déploierez une nouvelle version. Il inclura la config telle qu'elle est lors de la construction. Mais cela pourrait suffire :)
S'il vous plaît la première réponse sur ce post précédent - Fichier de configuration en tant que ressource intégrée
Comme on le dit ici, l’intérêt d’un fichier de configuration est de modifier certains paramètres en dehors de l’application. Vous pouvez coder en dur ou utiliser des constantes, mais vous pouvez également utiliser le registre dans Windows si vous le souhaitez. De cette façon, vous pouvez apporter des modifications à l'application et ne disposer que d'un seul fichier exe.
Le projet de code contient de bonnes informations sur la lecture, l'écriture et la suppression du registre . http://www.codeproject.com/KB/system/modifyregistry.aspx Mais soyez prudent lorsque vous modifiez le enregistrement. De nombreuses applications en dépendent, vous pouvez donc détruire certains paramètres si vous faites quelque chose de mal. Je recommande de lire et ensuite de faire.
public string Read(string KeyName) {
RegistryKey rk = baseRegistryKey;
// Open a subKey as read-only
RegistryKey sk1 = rk.OpenSubKey(subKey);
// If the RegistrySubKey doesn't exist -> (null)
if ( sk1 == null )
{
return null;
}
else
{
try
{
// If the RegistryKey exists I get its value
// or null is returned.
return (string)sk1.GetValue(KeyName.ToUpper());
}
catch (Exception e)
{
// AAAAAAAAAAARGH, an error!
ShowErrorMessage(e, "Reading registry " + KeyName.ToUpper());
return null;
}
}
}
public bool Write(string KeyName, object Value) {
try
{
// Setting
RegistryKey rk = baseRegistryKey ;
// I have to use CreateSubKey
// (create or open it if already exits),
// 'cause OpenSubKey open a subKey as read-only
RegistryKey sk1 = rk.CreateSubKey(subKey);
// Save the value
sk1.SetValue(KeyName.ToUpper(), Value);
return true;
}
catch (Exception e) {
// AAAAAAAAAAARGH, an error!
ShowErrorMessage(e, "Writing registry " + KeyName.ToUpper());
return false;
}
}
public bool DeleteKey(string KeyName) {
try
{
// Setting
RegistryKey rk = baseRegistryKey ;
RegistryKey sk1 = rk.CreateSubKey(subKey);
// If the RegistrySubKey doesn't exists -> (true)
if ( sk1 == null )
return true;
else
sk1.DeleteValue(KeyName);
return true;
}
catch (Exception e)
{
// AAAAAAAAAAARGH, an error!
ShowErrorMessage(e, "Deleting SubKey " + subKey);
return false;
}
}
Bien sûr, cela ne fonctionnerait que sous Windows. Je suppose que vous utilisez Visual Studio, donc vous utilisez probablement Windows.
Bon codage et bonne chance!
IL Merge a beaucoup de problèmes avec l'exécutable wpf également lent . J'ai fini par utiliser Cosura.Fody https://github.com/Fody/Costura et d'utiliser un paramètre de ligne de commande pour transmettre la valeur de configuration de l'application. Également en utilisant iexpress http://en.wikipedia.org/wiki/IExpress pour créer un exécutable final avec des arguments en ligne de commande et des fichiers exe fusionnés ensemble.
Vous ne créez pas de fichier .exe pour une application de console .NET.
Au lieu de cela, vous devez lancer le fichier .dll de votre application console à l'aide de la commande Invite ci-dessous (j'utilise l'application "Hello World" à titre d'exemple).
dotnet HelloWorld.dll
Je pense donc que la réponse que vous recherchez, car vous voulez que les autres puissent lancer votre programme comme ils le feraient avec un fichier .exe, est de créer un fichier de commandes qui exécute la commande Invite.
Ensuite, tout utilisateur pourra utiliser votre programme.
Un exemple de script de lot pour lancer notre application "Hello World" serait
echo off
dotnet N:\SharedDriveFolder\HelloWorldProgramFolder\HelloWorld.dll
Ensuite, votre programme sera exécuté et, puisqu'il se trouve dans un dossier Shared Drive, tout utilisateur de votre organisation pourra l'exécuter.
J'espère que cela répond à votre question car j'ai remarqué votre message et j'ai eu le même problème.
Je cherchais le fichier .exe et il m'a fallu environ 2 heures de recherche avant de tomber sur cet article https://docs.Microsoft.com/en-us/dotnet/core/tutorials/publishing-with-visual- studio qui m'a aidé à tout mettre ensemble.