I am trying to deploy a windows forms application which uses the properties/settings of the project to store config information.
In a form it is retrieved and sometimes changed by saving as below
Properties.Settings.Default["name"] = textBox1.Text;
Properties.Settings.Default.Save();
I only need to deploy to 3 PCS. Is it enough to deploy the .exe file alone?
Or do I also need the exe.config file ?
Thanks
If your App.config1 file contains default configuration information not embedded in your program, such as a connection string, then yes, you will need to bundle it with your executable.
However the code you've posted shows you're using the "Settings" feature, which is a feature of .NET that runs on-top of App.config. If you use the Settings feature, then your app.config file is (usually) actually stored under your current user's AppData directory and not the same directory as the executable, these files are also created as-required, in which case you won't need to ship the app.config file... assuming you have nothing else in the file.
Related
I am trying to help port a .Net service to a more modern .Net version (possibly Core) and use the MSIX installer. The application has several configuration files generated by the compiler (in source they are app.config but compiled they become *.exe.xml), they are installed into Program File right next to the binaries and a GUI helper app as well and the application itself can modify them to change service behavior (port, ip, tls cert, etc).
Writes under C:\Program Files\WindowsApps\package_name are not allowed.Writes under C:\Program Files\WindowsApps\package_name are not allowed.
The problem I am facing is that the MSIX installer makes it so that files in it's sandboxed version of Program Files cannot be written to (see above). That means that this application cannot be configured, so I am trying to figure out not only how to make the app configurable again, but also how windows wants to handle app configuration.
Right now it seems like there is two general approaches to do this:
write the configuration data to the service account's AppData/local folder
try to mimic a /etc/Myservice behavior in another folder. (meaning a local system-wide directory that houses configuration data for the service)
If you suggest #1 please answer the following additional questions:
How would I move Application configuration files to a user configuration file directory
how can an admin with a normal account modify the config file in the Service Account's AppData folder with the mentioned GUI helper application? (do they need to enable desktop access to the service account, login and run the GUI)?
If you suggest #2:
Where would you suggest this directory exist (specifically where will MSIX allow it)?
How do I tell the .Net application that the files are not right next to it? Can I just use AppData.CurrentDomain.SetData?
Well, a service running on the system account is the same for all users, so I would say that CommonApplicationData is a better folder for storing its settings, instead of appdata. This folder is easily accessible to both your service and to any admin that needs to deploy a custom config file.
In AppData you should store only actual user files (like files or settings generated by the actions taken inside your app by a specific user - thus different files for different users).
Now, the second part is where you need to configure you code to load the config file from a custom path instead of looking for it next to the EXE. I am no .NET expert but after a quick search I found this:
Relocating app.config file to a custom path
The modern approach to deploying app customizations
What is not clear to me is how your customers use the GUI helper tool to customize the config file. Is this just a tool that is used by someone from the IT department to generate the config file, and then they would copy that file and deploy it to the end-user machines using an MSI/MST file (or through some other custom deployment method)?
If your application is only deployed by IT folks, then you can try another simpler (and much elegant) solution for providing it with a custom config file, which actually doesn't require any code changes.
You can still leave the config file next to the EXE, in ProgramFiles and instruct the IT teams that deploy the app to use an MSIX Modification Package to deploy the custom config file generated by your GUI helper. (check the link included above for an example - with a video version at the end of the article).
Note: IT teams can use multiple free or paid tools to generate MSIX Modifications Packages.
Of course, your GUI helper tool still needs to generate that customized config file in a folder where it is allowed, as it can no longer write under ProgramFiles. So actually, you do need to modify a little bit your code in this scenario too.
I have written a C# app using Winforms, and am trying to utilise the inbuilt Properties.Settings (User scope) to remember user state between launches of the program.
When the app is deployed via Visual Studio's inbuilt Build > Publish, apparently this file is put into the Local Appdata folder.
However, I want to use NSIS to create the executable of the program. I am able to place the ProgramName.exe.config file into Local AppData, via NSIS script, but my app does not seem to read from it. No user settings persist.
Is this even possible? Or should I use my own method (database or write my own settings xml) to store user settings?
OK, I got it working with NSIS.
The App.config file has a property called "Copy to Output Directory" which was set to "Do not Copy" by default. I found this information here: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/
I found out where the user.config file was going to be created, with help from #Jimi by adding System.Configuration as a reference, and then getting the path using:
var config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);
The user.config file is not created on application install, rather the first time that the following is called:
Properties.Settings.Default.Save();
There is nothing special that the developer has to do in NSIS.
With a Windows Forms (or WPF) application, if I create an installer through Publish command (ClickOnce that is), the installer creates application folder with executable and config file in C:\Users\[UserName]\AppData\. On the other hand, if the installer is created through Setup project (MSI), the installed app would be in C:\Program Files\My Company\My App with both the executable and the config file. Out of the two, I chose MSI path.
My expectation was that the application settings (as in Project properties > Settings tab) are read from/written to the config file that is in Program Files, which remains there even if I uninstall the program or upgrade it with a newer version, so that user's settings don't get lost. But it doesn't appear to be the case. Even that the Program Files version of the config file is there, the installed application appears to be reading from/writing to C:\Users\[UserName]\AppData\ as if it were a ClickOnce app. What am I missing?
(This is VS2010 + Win7 + C# + .NET 4.0 Client Profile, though I don't think those things have anything to do).
I hope I understand your question in the right way.
If you want to know, why settings are read from/written to the AppData folder, then it's because of security/permission reasons.
When first starting your application, your initially application settings from app.config file were copied to that folder. Your application will automatically work on that newly created file.
This is done, because it's a risk letting the user work on the "global" settings in your Program Files folder, with which all your users will work. Think about what would happen, if a user only has permissions to read, but not to write to this file.
I developed a windows service using Visual Studio 2012.
This service has a config file. When the application is build, the config file takes the name of the exe + .config.
If I install the service everything works, it means that the service uses the settings in the config file.
If I want to change a value in the config file and I restart the service, it does not read the new values, but it is still using the original values.
It looks like if the config file is copied in a different location when I install the service and the config file is not used anymore. Why? Where is the config file that service reads?
If you use .NET settings which you create in Visual Studio, then they are saved under
c:\Users\{Username}\AppData\Local\{AppName}\
this should work as you describe. you just have to be sure that you modify the correct .config file.
To check where your app resides, open the windows task-manager, right-click your exe and click 'properties'. here you can see the folder you app is running
I have installed a C# Windows Service on Windows Server 2008. I installed it with InstallUtil. The service reads some data from the app.config file and it is doing it fine. Can you tell me where this file is located after installing the service?
I have been looking for hours but can't find it.
You can verify the exact location of the installed Windows Service by following the steps below:
Bring up the list of Windows Services by clicking the "Services" icon under the "Administrative Tools" icon. You can also get this list by typing "View local services" in the Search Menu under the Start Menu.
Select your Windows service in the list of installed services, right-click and then select Properties. You can also double click on row representing the service.
Locate the "Path to executable" value on the Properties dialog box. The value will include any command line parameters.
Open the folder in which the service executable resides.
If the Windows service has been built with .NET Framework, its configuration will be stored in the corresponding .config file, i.e., the name of the executable suffixed by ".config", e.g., if the name of the executable is "XyzService.exe", then the name of the .config file will be "XyzService.exe.config".
A couple of things to note:
If you installed the service after building it on the same machine using say, Visual Studio, then Visual Studio would have transformed the App.config file from the project and placed it in the build output folder automatically (and renamed it appropriately using the above naming convention).
If your machine is set to hide file extensions in Windows Explorer, you will see 2 files "XyzService" and "XyzService.exe". In this case, the "XyzService.exe" is your config file. If you then switch off the option to hide file extenions in Windows Explorer, you will then begin to see "XyzService.exe" and "XyzService.exe.config".
If you cannot find a corresponding .exe.config file, then it is possible that the code within the service is falling back to default values. In this case, you can place a properly named and formatted config file alongside the service executable and then restart the service and everything should be fine.
According to Microsoft
For client executables, the application configuration file resides in
the same directory as the application's executable and has the same
base name as the executable with a .config extension.
Note, if your exe is called appname.exe, and you have Windows explorer set to hide extensions, then your application will display as appname and your config file then it will be displayed as appname.exe (even though the true name is appname.exe.config)
As others have pointed out, InstallUtil doesn't do anything with the config file and it should have copied to the server in the same manner as the exe itself.
It is the same location from where you have registered service using installutil tool.
The App.config is likely called {ProjectName}.exe.config given the fact that it is a Windows Service. Check to see if that file exists and is what you are looking for.
The same place where your application (Windows Service) is.
Check it out, if it's not there place it in the same directory as of service.
If you have a live environment (and from your question it seems like you do), you can check what's actually happening using the superior Process Monitor utility. But usually the .config fileis located right next to the .exe, and named the same.