Develop Reference

.NET Build events xcopy application settings.settings

I am trying to add these lines to the application's Build Events
xcopy debug.settings settings.settings
In order to acees the debug.settings as Default, but I am getting a exited with code 4 error when compiling. I have read code 4 would probably mean that it cannot find the specified files. But how would I reference debug.settings?
I have this file as part of my application's properties:
I got this idea from a stackoverflow question: .NET different application settings for development and release This would be a followup question based on its answer.

This is likely because xcopy cannot find the source and destination paths for the settings files. Try updating them to the fully qualified path (i.e. C:\SomeFolder\MyProject\debug.settings).
Also, check out the documentation when in doubt (or looking for what error codes mean).
As an aside, if you are simply looking for a way to change values in an app.config or web.config based on your build configuration, take a look at SlowCheetah.

Declare folder as language neutral in VS2017 build for the Microsoft Store

I am building an application for UWP in Visual Studio 2017 (it is actually a Unity game, the solution is exported from Unity). During build, I get the following warnings, and the files which are reported as such do not show up in the final appxupload file, and thus cannot be found at runtime:
1>GENERATEPROJECTPRIFILE : warning PRI263: 0xdef01051 - No default or neutral resource given for 'Files/Data/GI/level1/ca51e77bb6146d425e0c9319844929a0.vis'. The application may throw an exception for certain user configurations when retrieving the resources.
There is a warning message for the resource situation in general, which reads like this:
1>GENERATEPROJECTPRIFILE : warning PRI257: 0xdef00522 - Resources found for language(s) 'be,ca,fa' but no resources found for default language(s): ''. Change the default language or qualify resources with the default language. http://go.microsoft.com/fwlink/?LinkId=231899
The languages that are reported as such are in folders which have language iso codes (for example, in the error message, the file is actually in the folder Files/Data/GI/level1/ca/). However, these folders are NOT language specific, they are named this way due to an internal indexing scheme of Unity which I cannot change.
So, what I am asking is this: How, and where, can I configure Visual Studio or whatever part of MSBuild is responsible to NOT treat these folders as language-specific? Or is there any other solution to this problem?
Thank you.

I found a solution/workaround. Part of the build is a call to makepri.exe which creates the Package Resource Index (PRI) files which more or less contain a directory of files in the build. Makepri, by default, looks for language-named folders and splits the build along the languages it finds - which moves the language-specific files into resource packs.
Luckily, this behavior can be configured, as is described here - makepri can be instructed to just place everything in one big resource file instead of splitting up. This is achieved by editing the .csproj file, and adding the following two lines to the configuration section for Master|x64:
<AppxBundleAutoResourcePackageQualifiers>
DXFeatureLevel
</AppxBundleAutoResourcePackageQualifiers>
<AppxDefaultResourceQualifiers>
Language=en-us;de-de;es-es
</AppxDefaultResourceQualifiers>
The first tag disables auto-language qualifiers (since "Language" is MISSING from the list of qualifiers). Since languages are now no longer auto-detected, they must be explicitly listed (second tag).
I've not found a way to do what I originally wanted - specifying that certain folders should not be considered language-specific - but this works for me.

How can I change visual studio 2008 solution resources to be linked and not embedded?

I'm developing a C# solution where I use files as external resources.
I need to this files to be modified without building all solution again.
I used to have shuch configuration and all went well.
I don't remember what I changed but now all resources are embedded in .exe file, I cannot find a way to make them linked again.
In resource properties in all resources Persistence option is diabled and is set to Linked at compile time, so I don't think this is the problem because I think it must be this way.
I think it could be a language configuration, problem started when I changed a form language propiertie that created an language specific resx but later it returned to its original configuration.
Thanks

Take them out of resources, add (add existing file) them to the project, make sure you set the properties on each one to copy if newer, assuming you are happy to have them deployed in to the same folder as the exe/dll that depends on them.

How to preserve app settings from a referenced assembly?

I have an app MainApp that references another project MyDLL.dll. Inside the MyDLL project I have made some user settings in a Settings.settings file that may be changed at runtime. So it appears that these settings get saved in the app.config file of MyDLL. But the problem is, the main project is MainApp, and MyDLL.dll.config does not, so far as I can see, get copied to the MainApp output folder. This is reflected in the fact that even though I save the settings in the code of MyDLL, the next time I run MainApp the settings have gone back to the default.
I must be missing something really obvious here. There has to be a way for related assemblies to preserve their settings values. But how?

While you can add an app.config to a library project, it has no effect to do so. Configuration is linked to the application, not the library.
You need to create the settings and configuration in your application itself. You can do something like including the library's app.config if you really wanted to, but that would probably not do what you want, either. It's best to just handle your configuration in the application.
Why is this so? Because what's to say it's valid to have user settings for your library in the first place? A library should not be tied to any particular kind of application. What if you used it in a Windows Service or an ASP.NET application?

How to force deployment project to update files during installation of newer version?

I have a Deployment Project for my VS2008 C# application. When installing a new version of my application I want to make sure that files are updated with the files contained in the installer.
I want my installer to automatically remove any old version of the installed application. To do that I follow this procedure (also described here):
Set RemovePreviousVersions to True
Set DetectNewerInstalledVersion to
True
Increment the Version of the
installer
Choose Yes to change the ProductCode
For the assemblies I make sure the AssemblyVersion is set to a higher version:
[assembly: AssemblyVersion("1.0.*")]
Everything is working as intended except for my configuration files (xml files). Since I cannot find a way to "version" these files I cannot make sure that the files are updated if they have been modified on the target machine.
Is there any way to do this and how?
UPDATE: I have tried the approach/solution/workaround found here
Include the file directly in a
project with the following
properties: "Build Action -> Content
file" and "Copy to Output Directory
-> Copy always"
Then add it to the deployment
project via Project
Output->Database->Content Files
Unfortunately it did not make any difference. The behavior is exactly the same.

Add the following property to the Property table of the MSI:
Property REINSTALLMODE with Value amus
Note: This will cause all the files in the MSI (versioned and nonversioned) to overwrite the files that are on the system.

If you're willing to use Orca (there may be another way to do this method, but it's the only one I know of) you may be able to set up RemoveFile directives.
See here for a typically light-weight MSDN document -- could be a starting point.
http://msdn.microsoft.com/en-us/library/aa371201.aspx
Alternatively you could always create a very simple bootstrapper executable that simply calls "msiexec /i REINSTALLMODE=oums" (or whichever command-line switches are needed). Call it setup.exe if you like...
Better option long-term may be to switch to InstallShield or similar -- VS2010 includes a light version of IS and I believe they're moving away from vdproj projects.

Have you tried the approach/solution/workaround found here?
Include the file directly in a
project with the following
properties: "Build Action -> Content
file" and "Copy to Output Directory
-> Copy always"
Then add it to the deployment
project via Project
Output->Database->Content Files

I may be incorrect here, and therefore I am exposing myself to down votes, but here goes anyway!
I believe it is on purpose that config files do not automatically get overwritten; the principle there being that you would not normally want your application's configuration overwritten when you install the new version of the program... at least not without numerous warnings and/or chances to merge configuration first.
Having your application configuration get overwritten by an updated version of a program could make for a very upset end user (in this case, web site admin).
Further, I know that sometimes, the developer may be the person doing the deployment. In such a case, this behavior might not seem so logical when deploying a single site to a single server; but when roles are split and/or you have multiple servers with different configurations, this can be a life saver.

You need to include the new version of your files in your custom installer and manually install these file during Custom Install routine is called
This must be applied to any file that does not have version that can be tracked by the installer.