I have a C# class library project with some settings in Settings.settings. I need to be able to change these settings at build time based on the configuration (Debug, Release, etc.).
It's fairly straightforward to add a pre-build event to copy Settings.<configuration>.settings to Settings.settings, but as it turns out - this doesn't help! The settings are taken from Settings.Designer.cs which is generated from Settings.settings as soon as you save your changes (i.e. at code edit time).
Is there a way to regenerate Settings.Designer.cs from Settings.settings at compile time? Or is this the wrong way to go about modifying configuration settings?
The Settings.Designer.cs is generated by the IDE, not MSBuild. So, no, changing that file at compile time won't have any effect. You didn't document your question well enough to offer the best alternative, but it sure sounds like using a setting wasn't the correct choice.
Related
I have a c# ClickOnce application that I need to be able to publish multiple times for OEM purposes.
The way I understand it now is that publish settings are located in the .csproj file.
However, this is inconvenient in the case where I want to publish multiple versions.
for example, Company A needs totally different icons, start menu location, product name etc. from Company B, but the assemblies need not be renamed.
Here are a couple approaches/questions that I can think of to solve this issue...
1.Is there a way to create a separate publish settings file to use during build time?
2.Can I edit specific publish settings (like Start Menu location, etc) at build time with MSBuild.exe? I think this would be ideal...
e.g.
MSBuild.exe project.sln /target:Publish /property:edit-project-publish-settings-here
3.Maybe create a 2nd .csproj file? (Would prefer not to do this...)
Please share your thoughts as to the best approach, or any other clever ways to make this happen. Thanks!
I wish I could give you some brilliant solution, but personally I would probably go with option 3.
I mean, its pretty simple, the changes should be pretty static and it will be difficult(ish) to totally screw it up and deploy the wrong changes to the wrong company.
If you copy the .csproj in your project folder, it will reference all of the same source files and you can just change the executable name. Create another VS solution and you can reference the copied .csproj and get rid of your first one so that you can publish two separate versions.
This isn't ideal for ClickOnce however.
If you use a Singleton object that specifies the "mode" (Company A, B, C, etc.) you can easily store that in the app.config (or another xml file). Then just re-publish your ClickOnce Application but copy the correct version of your configuration file in so it gets shipped with the build. This way, you don't need any additional csprojects Just include all of your icons and set them at run-time on App Start based on your Singleton object.
I found that you are able to edit certain properties using MSBuild.exe like this
MSBuild Solution.sln /target:publish /property:ProductName=ProductA\;Publisher=CompanyA\;ApplicationIcon=companyA.ico
I found another useful post on modifying.csproj files programatically with .NET code. (This would only be needed if you're modifying things that are deeper than just the project properties specified in the ClickOnce documentation below)
The MSBuild documentation here was also useful -- especially under Publishing Properties
Or maybe access it's data via reflection somehow ?
Thanks
EDIT: I'd like to know if there's a way to do it without reading it as an XML.
Like a ms library that supports it, so it'll work for any kind of project and any kind of vs version (2005, 2008, 2010 ... ).
The *.csproj file is really just an XML file. You can open it just like any other XML file and treat it as such as well. Realize that any changes made to it, though, will require reloading the project.
Also, remember, there is no *.csproj file once the application is compiled/deployed.
Yes, you can open it in a text editor, or from Visual Studio
Right click on a project
Unload Project
Right click on the unloaded project
Edit project
Right clicking the project and selecting the properties option gives you a GUI to change some of the settings in the project file. Also, when you right click a file and change it's properties it causes a change in the project file. If you want to do anything very serious, like add custom build steps, you have to do it by hand in a text editor like notepad++. It's just an XML file. If you're familiar with MSBuild the proj file has many similarities to a build script for MSBuild.
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.
According to MSDN, one can add customized settings files to ones project for convenient management of groups of settings.
So I created a custom settings by visual designer, set all properties as a User Scoped to be able to save them.I bind some control properties to this customized settings. And change some values mannually through Properties.CustomSettings.MyValue = x;
But when I do Properties.CustomSettings.Default.Save() - nothing happens. The changes are not persisted between application run (I'm aware about Debug version change) .
I searched a file in the directorites that ConfigurationManager gives me (according to this post) but didn't find any track of this CustomSettings.
So, what is the trick with saving this Customized Settings Files and How to save Customized Settings Files?
Ok, now I've got a right answer. Everything is OK that this custom settings were created under the dll file.
The problem is with this question
Application.UserAppDataPath strange behaviour
If one have AssemblyVersion with automatic Build and Revision Numbers and have AssemblyFileVersion in AseemblyInfo.cs, say, of exe that uses this dll, then Application.UserAppDataPath will throw ArgumentException "Illegal characters in path." Application.UserAppDataPath is used to build path to this config file to save this CustomSettings.
But ApplicationSettingsBase just eats all exceptions that happens inside, so the file is just not saved and nobody could even think about AssemblyFileVersion in AseemblyInfo.cs of exe...
Ohhh my god... 8 hours of fighting with this ... feature...
Is there a way to have different application settings per each build configuration?
I would like to be able to batch build a few configurations with different settings, instead of having to change the settings and build, rinse repeat.
Thanks in advance!
I don't know much about the appsettings architecture (I've never really used it), but you can define different values for constants using a bit of MSBuild magic.
Create two .cs files, Constants1.cs and Constants2.cs (or name them after your configurations).
In each file, define a class called Constants (or whatever) -- but do it as if each file were the only definition (ie. use the same class name). Typically, this should just define public static readonly fields -- do not use const, as that can get you into trouble with partial builds.
Now Unload your project file and Edit it. Find the entries that look like this:
<Compile Include="Constants1.cs" />
<Compile Include="Constants2.cs" />
and change them like so:
<Compile Include="Constants1.cs" Condition="'$(Configuration)'=='Debug'" />
<Compile Include="Constants2.cs" Condition="'$(Configuration)'=='Release'" />
Finally Save and Reload your project. Now only one of the files will actually be built at a time, depending on your build configuration.
You could add a prebuild or postbuild task to the proj, you have access to the ConfigurationName from there. Would be fairly easy to do something like "copy Web.config.debug Web.config"
Besides all these, MS promised to add this feature in VS 2010.
What do you mean under 'application settings' ? Project's property for each configuration such as Debug or Release? Or defirent app.conf file for each of them?
If first, you can create a number of configurations with suitable settings and use Batch Build to build them by turn.
http://msdn.microsoft.com/en-us/library/169az28z.aspx
or as Google Ninja said, use pre-build task:
del Web.config app.config
copy Web.config.Debug Web.config
(create a number of configuration files before it)