I am doing a windows service, using app.config, where there is a section to retrieve common configuration in another file. Using
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", "filepath\\file");
works for me, but using
string appconfig = ConfigurationManager.AppSettings["CommonAppSetting"];
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", appconfig);
does not. It gets from the app.config of the windows service instead of the common configuration.
Anything I did wrong, or is there other better ways of doing it?
You need to reset some variables (ClientConfigPaths) in the ConfigurationManager in order for it to refresh its values. These can be seen in the following accepted answer (complete with code for doing this legwork).
Change default app.config at runtime
Related
In Grails 2 we used the "External configuration plugin", which included the method checkNow() for checking and refreshing values from an external config file.
Does it exist a simple approach for doing something similar in Grails 4+? I have seen references to Spring Cloud Config Server, but it seems a bit overkill for me. All I really want to do is be able to (now and then) update a config value in runtime. It could also be purely by a few lines of code, and does not have to originate from changes in the config file. This would avoid having to restart our server for minor changes in config. Thanks!
I'm replying to myself with a ridiculously simple answer: "just change it". Using the console plugin (or any other form of code execution), I can just assign grailsApplication.config.any.property a new value. It won't persist and it won't update any listeners or anything. But it is a glaringly obvious solution that I just assumed wouldn't work due to the getProperty() calls (I interpreted the name as reading from file) and googled discussions about Spring Cloud Config.
So, move on... nothing to see here. Just mild embarrassment :-P
We are trying to switch completely from log4net to Serilog. However, this part of functionality seems to be missing. What I need is to be able to get location of log-files Inside a library class. This is important for our Desktop Click-Once application because that location is different on different OSes and for different users. When user needs access to the logs we can direct him to the proper folder.
Very similar question was asked here:
Read current Serilog's configuration
But I can't believe that there is no way to get this information from Serilog. I don't need to change that configuration - just read it. In log4net we could do:
log4net.LogManager.GetAllRepositories()
and then
repository.Root.Appenders.OfType<FileAppender>
Please tell me that there is some kind back-door to the current LoggerConfiguration or if there is some alternative way to get file-path of the current File-Sink.
Serilog does not expose the list of Sinks that have been configured, so your only option at the moment would be to use Reflection if you really want to get this information from the live Serilog configuration.
You can see an example on this answer:
Unit test Serilog configuration
That said, given all you want to do is to know the path where log files are being written, that's something you can easily store at the start of the application at the moment you set up your Serilog logging pipeline.
If you configure the file path in code, you can store that information in a static property somewhere your entire app can access. If you get your folder path from the appSettings.json or App.config, you can read the information from there.
If you have environment variables in your configuration you can get the same values that Serilog gets by expanding these environment variables e.g. Environment.ExpandEnvironmentVariables("%LogPath%\\AppName.log")
This is a (actually it is several) follow-up question to my previous question on F# Type Providers and Continuous Integration.
It seems to me that it would be a good idea to use the SqlDataConnection type provider as a compile-time check that the code/database integrity remains intact in feature-branch driven development; you would know at every commit/build that no changes have been made to the code that has not also been applied to the database, assuming that building the database is also a part of your CI process.
However, a couple of questions arise:
The name (as well as the location) of the config file is not the same at compile time as at runtime, e.g. app.config -> MyApp.exe.config, which will result in a runtime error if you try to use
SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">
(Actually, specifying ConfigFile="app.config" is not necessary, since it is the default value.)
The runtime error can be avoided by copying the app.config file to the output directory (there’s a setting for that), but that would result in having both an app.config and a MyApp.exe.config file in the output directory. Not very pretty. Adding a separate configuration file for type providers would be another solution, but imho that’s not very pretty either.
Question: Has anyone come up with a more elegant solution to this problem?
The next problem arises when you come to the build server. It is most likely that you don’t want to compile against the same database as you did while developing, thus requiring a different connection string. And yes, in production you’d need yet another one.
Question: How do you go about solving this in the most convenient way? Remember, the solution has to be a working part of a CI process!
This strategy would require generating the database on each build at the build server, probably from a baseline script with some feature/sprint update scripts.
Question: Has anyone tried this and how did it affect build times? If yes, how did you create this step?
At runtime you can use the GetDataContext overload that accepts a connection string. See here: Providing connection string to Linq-To-Sql data provider
I am familiar with the solution that #Gustavo proposes, but I’ve always felt that there is something fishy about it. Something about having to specify the connection string twice… However, when I once again got the same reply, I slowly started to realize that the answer must be correct, and that it’s me who’s thinking wrong. These are my conclusions:
The reply states that you can use the GetDataContext overload that accepts a connection string. If you change this to should, things become clearer, at least to me.
The thing is that I’ve been thinking of the class definition as both a compile-time directive and as a run-time variable, but even though this is possible, it is hardly a good idea. The default value of the ConfigFile argument is as we’ve already seen “app.config”, but that file doesn’t exist (with that name) at run-time, so it doesn’t make sense to try to use it, thus leaving GetDataContext as the only reasonable option. I suggest that you do this:
Keep your compile-time settings in a file called compilation.config (or whatever you prefer) and specify this file for usage in the class definition.
Use the GetDataContext overload that accepts a connection string for run-time resolution and specify this connection string in the app.config file.
You will end up with something looking like this:
type private dbSchema = SqlEntityConnection<ConnectionStringName="DbConnection", ConfigFile="compilation.config">
let private db = dbSchema.GetDataContext(ConfigurationManager.ConnectionStrings.["DbConnection"].ConnectionString)
Heck, this even supports the SRP; compile-time settings in one file and run-time settings in another!
Regarding the rest of my questions, I assume that the answer lies in some scripting in the Continuous Deployment pipeline. Still interested in other solutions though.
I am trying to write F# client for our web services. The example here looks very good except it uses the server url in the code.
type TerraService = WsdlService<"http://msrmaps.com/TerraService2.asmx?WSDL">
This prevents me from reading service url from configuration file at run time, and make deployment from dev server to production server difficult.
I am wondering if there is any WSDL provider that works similar to Dbml Provider
I'm not sure I understand exactly what you're looking for, but note that the URL provided as a static parameter is used to generate types, but if desired a different URL can be provided at runtime by using a different overload of the Get...Soap method. This URL can come from wherever you want (e.g. you can read it from a config file if that's your scenario). E.g.:
type TerraService = WsdlService<"http://msrmaps.com/TerraService2.asmx?WSDL">
let terraClient = TerraService.GetTerraServiceSoap(EndpointAddress(myRuntimeUrl))
Nothing currently exists that does that but the code is open source so you could make a version of it that work's in the mode that you desire:1 2.
I'm searching a way to set the serviceURI for ClientFormsAuthenticationMembershipProvider in code behind. I wish not to have the app.config being changed. Is this possible ?
I'm accessing services from a windows service as well as from a windows program and configuration should be handled in a central place.
Thanks,
Sascha
It is possible to cast to ClientFormsAuthenticationMembershipProvider ClientFormsAuthenticationMembershipProvider just before doing the authentication. If casted you have a property ServiceUri. Set it and it's done.