Our product consists of client, server and agents. Each deployed on different machines. The QA is having a hard time to manipulate the log4net sections in the respective config files. Right now, they have to have remote desktops to all the relevant machines and open notepad in each of them and then edit the files one at a time switching between different machines as they proceed. A real pain in the ass.
Can anyone suggest a better solution to this problem?
Thanks.
You could store the log4net configuration in a database (you could then even consider to create a web interface that allows your QA team to modify the configuration). You have to figure out how your applications pick up the new configuration (e.g. you have some remote Admin interface that allows you to tell your applications to use the new configuration).
On start-up you load the configuration from there. Maybe it is advisable to have some backup configuration in a file that is loaded first in case loading from the database fails. The default configuration would be for instance so that the QA team gets an email if loading the configuration from the database fails.
Another option would be to store all log4net configuration files on a network share... create an application setting that tells your application where to find the log4net configuration and call the Configure() method accordingly. Again the question is how your applications pick up the new configuration.
Not sure if ConfigureAndWatch() would behave as expected if the configuration files is on a network share. If so that would be quite an easy option to implement.
Related
Our asp mvc is published automatically using octopus deploy. We use web config transformations and we always end up with additional environment specific files in the installation folder. Eg
Web.development.config
Web.test.config
Web.preprod.config
There is a slight advantage in having these files deployed since we can easily compare values between different environments when troubleshooting.
Is there an security risk in having different config files deployed to a production environment??
IIS should be configured to prevent the download of .config files by default, but depending on how tight your security needs are, it might be worth getting rid of them. (eg if someone comprises a test server, they do not gain access to production).
If you do want to get rid of the, you can write a PostDeploy.ps1 script to remove Web.*.config
These files can be removed using the community-contributed step File System - Clean Configuration Transforms.
If you want them to be available for diagnostic purposes, redeploy the Release, but switch off this step.
I've started working on an Azure project. In terms of config, I currently have three files: ServiceConfiguration.Cloud.cscfg, ServiceConfiguration.Local.cscfg and ServiceDefinition.csdef.
ServiceDefinition.csdef is the template file for the csfg files. ServiceConfiguration.Cloud.cscfg contains all the actual Azure configuration, including DB passwords, SAS keys etc.
Should ServiceConfiguration.Cloud.cscfg be checked into source control? I wouldn't have thought so but a quick search on github for the file shows that it is.
If it should be checked in, how should the sensitive password data be managed?
I typically check in the configurations. The reason is that the behavior of your application will change dramatically depending on these configurations. For example -> number of roles for a distributed application directly affects how you process incoming messages and the vmsize directly affects how much memory you have. You may encounter issues debugging problems if each developer is using a different configuration. This standardizes your deployment.
Anything with plain-text password information shouldn't be checked into a public repo unless you want people to have access to that information.
You can add this file to the .gitignore file and prevent it from being checked in.
Provide a different ServiceConfiguration.Cloud.cscfg named something like ServiceConfiguration.Cloud.cscfg.template with all the config info of your cloud service minus the password values. If someone forks your project they need to use that and fill in the appropriate values and rename the file.
Do this and change all your passwords to something else. Even if you delete this file from the repo, it still exists in the history and anyone can view it.
Let say i have a cross-platform runnable application
This application create then read/write some data and preference in external files
Bundle hierarchy is as follow:
ApplicationFolder/application.jar
ApplicationFolder/database.odb
ApplicationFolder/config.xml
Whether it's on a Mac, Windows or Linux, the application knows that everything is next to her (ie: /database.odb or /config.xml)
Now comes the Self Contained Application feature provided by JavaFx 2
The application is embedded in .exe on Windows, .app on Mac and don't know yet about Linux...
As a Mac user i've tested it on Mac and saw that database.odb and config.xml are now created at the user root path
I thus agree that i should think of a cross-platform mechanism to save/read my application preferences regarding the operating system
But i'm not quite sure of what to do and how to do it (can't find any googling help either..)
On windows, the .exe is installed in a folder, so i guess i can keep the same behavior
On Mac, the .app is a folder and i should keep everything inside (how to get the .app path ?!)
Isn't there a built-in mechanism in Java/JavaFx ?
Thanks a lot for any comment, advice, documentation or else that you could give me
Badisi
There are many ways to do this. I have listed some of them here in no particular order. The recommended approach depends on the type of data being stored.
Java provides a couple of mechanisms (e.g. the properties API and the preferences API) for maintaining application preferences.
If your application is sophisticated enough to benefit from an database, then you might want to use Java EE or Spring, both of which have their own configuration mechanisms.
For read-only configuration, you can bundle the relevant files inside your application jar.
To store customized application configuration files or client application wide databases in relative to the application jar, write the required files at runtime. See How do I get the directory that the currently executing jar file is in?.
For user specific configuration, use System.getProperty("user.home") to retrieve the user's home directory, then create a subdirectory for your preference storage (for example "{$user.dir}/.myapp") with hidden file attributes so that it doesn't show up on a standard file directory list.
If your app relies on internet connectivity, then you can store some of this information server side rather than the client and make use of it from the client using internet protocols. An advantage of this approach is that user configuration and data is automatically ported across client machines.
I use the Log4Net as my log tool, everything works really well when the test system just has a single database.
But my real system has more than one database. Different user may have the different database. I want to put the log information into different database according to the current logined user.
But so far as I know. It seems that the Log4Net does't support this topic. It seems the log4Net is configured just "once" in the lifetime.
Is it possible for me to make the log4net select database configuration basing on my information on the fly.
I found the answer:
log4net - configure using multiple configuration files
and this: http://logging.apache.org/log4net/release/manual/repositories.html
The reason I thought that Log4Net only supports one configuration is I did NOT dig. As the content of the above links said: We need to create our own repository for each configuration.
Now everything is working well, and log information goes to different databases now based on the given configuration on the fly as I expected.
On a project I am working on, we usually keep our application settings defined in a separate file. This is how it has been done for many years, and going forward we would like to keep all system configurations in one file. I was considering to use the web.config section so I can just load the configurations that I need from my C# code running on the server using the ConfigurationManager class.
If I use our own way for the application settings, I would load it in a session and have it available for the application by loading values from the session. After some reading online it looks like some of the performance issues behind using the session is that we have to deserialize the values from the session object.
Does IIS deserialize the web.config values each time we read values using the ConfigurationManager?
Thank you,
Vijay Selvaraj
Web.config is read once upon loading of the AppDomain. It is refreshed if any changes are made to it or any referenced files (you can put sections into external files by using the configsection= attribute on a section)
No, configuration sections are deserialized into the custom classes that reflect them only when the configuration file is re-read (such as when the app pool is recycled, a change to web.config is detected, and a couple of other conditions).
See also this question.