Force rebuild after Spring config file edit - c#

In our C# project we use Spring as an Inversion of Control (IoC) container. We noticed, that changes to the Spring configuration xml file do not cause the solution to be rebuild. Therefore the changed configuration is not copied to the output folder and every debug-run uses the old configuration.
How can we force Visual Studio (2008) to copy the config file even though none of the project code has changed?
Further info:
The build action of the config file is set to None. Copy to Output Directory is set to Copy always.

Seems the solution is simpler than I thought. If the build action for the *.xml config file is changed to Embedded Resource, then changing the file also touches the project. Therefore, every debug cycle causes a rebuild of the project, where the config file is included. This causes the file to be copied to the output directory with the adjusted configuration. => Problem solved.

Related

Windows installer (MSI) does not copy a config file

I installed an MSI buillder tool on my visual studio 2017 and started deploying my desktop application with generated MSIs. The istaller is able to copy vital files and adds registery keys but it does not copy some additional config files which are required for logger. According to this page, switching "Copy to Output Directory Property" to "Copy always" supposed to take care the issue however, it still does not copy the config file into output directory on client's computer.
Can somebody give an advice about how I can diagnose this problem ?
Edit:
I think I can explicitly add logs files into MSI with following method but I have two concerns on this. Would I add the file into MSI with its global or relative path ? Secondly will it be a good practice ?
Edit 2:
For the reference for developers who has the same issue, looks like the method stated above adds files with its relative path. I added screenshot of difference page at source control.
It is completely normal to add individual files to a VS setup project. Every tool that generates an MSI works this way. VS setups are probably the exception with their "project output" type of input choice, where you get little idea of the actual files that will be installed. So you get the best control of the MSI content by adding each file individually, including that config file. Also, some files really don't belong in the Application Folder (that defaults to Program Files) because they are data files that belong somewhere like the User's Application Data.
The path where the MSI build gets its files from is nothing to do with where that file is deployed on the target system. You tell the MSI build where files will be deployed on the target system by using the File System view on target machine, where you get a list of destination folders to add files to.
Also, the copy to output directory stuff is nothing to do with the build of the MSI file. As far as I know, its main reason is to allow you to have all dependencies at the output build location of the code so that the program will work correctly from that location, and it happens to give you the opportunity to get all the files going into a setup from the same place. It does not mean "copy this file somewhere in such a way that it is automatically included in the MSI build and the deployed on the target system".
Once you get the MSI working and installing the config file, you may run into Windows Installer file overwrite rules that prevent you from overwriting files that have been updated after they were installed.

Output path being ignored when I build solution

I created separate configuration for my C# project. In project settings, for new configuration, I defined different output path (so for Debug I have bin\, for new configuration I have bin\NewConfig).
When I build my project under new configuration nothing appears in bin\NewConfig and from build log I can see that it removes files from bin\ and moves all files here.
How I can make my build files to appear in directory that I define in Output path? Could that setting be overridden or disabled somewhere else?
You have to remember that you are building a solution configuration for which you can choose which configuration of your projects are being built.
Check if the correct configuration of your project is selected for the selected solution configuration...

appname.exe.config not created on windows application

When I build a windows application. It does not work because it cannot read my app.config file. I looked in the bin directory and it does not have the appname.exe.config file. If I manually copy over the app.config and rename it the appname.exe.config the application will work..but when I build the project this file is never created automagically. What am I missing? Why is my project not creating it? I have looked through the whole folder structure and there is no other config files.
Everyone here is giving you false information I think. I think #bowlturner had it right. According to Microsoft, you do need to set the app.config's Copy to output directory property to either Copy Always or Copy if newer. From Microsoft's MSDN Site:
When you develop in Visual Studio, place the source configuration file for your app in the project directory and set its Copy To Output Directory property to Copy always or Copy if newer. The name of the configuration file is the name of the app with a .config extension. For example, an app called myApp.exe should have a source configuration file called myApp.exe.config.
Visual Studio automatically copies the source configuration file to the directory where the compiled assembly is placed to create the output configuration file, which is deployed with the app.
The correct settings are:
Build Action = None
Copy to Output Directory = Do not copy
and very important, the project file needs to contain this element:
<ItemGroup>
<None Include="App.config" />
</ItemGroup>
The only thing that worked for me was to delete bin\ and obj\ entirely. Rebuild and the file is created fine.
Look on App.config properties, should be:
BuildAction: None
CopyToOutputDirectory: Do not copy
Custom tool and custom tool namespace should be empty
Also try to Rebuild project. Right click on project -> Rebuild
Assuming you're using Visual Studio click your config file in the Solution Explorer and and in the Properties panel set Copy To Output Directory to something other than Do Not Copy.

How can I tell VS2010 to include files in my manifest for publishing?

I have an application that is published through the ClickOne mecanism. The issue I'm having is that it is not publishing my NLog.config file, which is required for my application to run. I've looked through the Application Files screen, but I don't see NLog.config as an option to select. My NLog.config file has a built action of Content and is set to copy to the output directory. If it matters the NLog.config file is in another project that is referenced in the project I'm publishing.
I'm aware that I can use MAGE to essentially scan my publishdirectory and have it update my manifest, but what I'm looking for is a way to do it automatically.
What are my options?
Possible Solution
One solution could be to configure NLog through code rather than XML.
I use this great tool too and I have a click-once program too:
In the Solution explorer, click on your nlog.config. In the properties window, put the Build Action as content.
Be sure that you see "Applications files" of the project's properties window.
VoilĂ !

reloading app.config after writing

When I use this to write to my app.config file:
Configuration config =ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.AppSettings.Settings["Wachtwoord"].Value = "Test";
config.Save();
ConfigurationManager.RefreshSection("appSettings");
I can read it again. But when i close and restart the program, the value of "Wachtwoord" has changed again to the old value.
Does anybody how I could fix this?
Thanks
Are you sure that this has not been caused by Visual Studio overwriting your settings file when you build the project? The original settings file lives with your source code, whereas you run the application from your build output directory (e.g. bin\debug). You may be making changes to the copy in the build output directory when you run the application, which will make changes to the version there. When you rebuild the project, the settings file will be overwritten.

Categories

Resources