Allow setting of configuration at runtime in ASP.NET MVC/WebAPI

[AndyMDoyle]

In relation to #93

Here's a simple solution to allow converting the Bugsnag.ConfigurationSection.Configuration object constructed from web/app.config when calling Bugsnag.ConfigurationSection.Configuration.Settings in to an instance of Bugsnag.Configuration that allow properties to be changed at runtime.

This would allow you to leverage the configuration section for the majority of static date, while allowing you to dynamically set one or more properties at runtime.

Here's an example:

//This configuration must be done early in the lifecycle of your application before the ASP.NET client is used

      //Grab the default ASP.NET client's default config which initially is a writable copy of ConfigurationSection.Configuration
      var bugsnagConfig = Bugsnag.AspNet.Client.RuntimeConfiguration;

      //Set whatever you want dynamically at runtime
      bugsnagConfig.AppVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString();
#if DEBUG
      bugsnagConfig.ReleaseStage = "development";
#else
      bugsnagConfig.ReleaseStage = "production";
#endif

      //Store this configuration centrally for use when a per-request or the global ASP.NET client is constructed
      Bugsnag.AspNet.Client.RuntimeConfiguration = bugsnagConfig;

      //Setup Web API
      config.UseBugsnag(bugsnagConfig);

      //MVC doesn't need any setup, but the Bugsnag.AspNet.Client.Current used by the HttpModule will use the configuration from Bugsnag.AspNet.Client.RuntimeConfiguration when each request starts

Goal

Allow quick cloning of ConfigurationSection.Configuration in to a writable Configuration object.

Allow setting configuration values at runtime (during app start-up), and reusing these instead of always using the values from app/web.config

Design

Beside constructing a Bugsnag.Configuration object by copying the values from Bugsnag.ConfigurationSection.Configuration.Settings which is simple enough to give you a configuration object that can be changed at runtime, this doesn't address the fact that Bugsnag.AspNet.Client.Current always goes back to the config file when a new instance is created.

To allow a custom configuration throughout ASP.NET, we need to store a copy of this configuration centrally. For this I have created a static instance under Bugsnag.AspNet.Client that will hold the configuration for the lifetime of the application.

Bugsnag.AspNet.Client.Current has then been updated to use this instance when the per-request client is constructed, or when the fallback 'global' client is constructed.

While this design does not allow the configuration of the global client to be changed after initial construction, I think this may be a suitable tradeoff to allow a more dynamic configuration at the per-request level.

Changeset

Added

An extension method in Bugsnag.ConfigurationSection.ConfigurationExtensions
A static property to hold the runtime configuration in Bugsnag.AspNet.Client

Changed

Changed Bugsnag.AspNet.Client.Current to use the new runtime configuration (which falls back to using the configuration file values if not explicitly set)

Linked issues

Related to #93

Review

Please note this is not extensively tested, and not something I expect to be merged without more thought and discussion from the Bugsnag team. :)

For the submitter, initial self-review:

• Commented on code changes inline explain the reasoning behind the approach
• Reviewed the test cases added for completeness and possible points for discussion
• A changelog entry was added for the goal of this pull request
• Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • Initial review of the intended approach, not yet feature complete
  • Structural review of the classes, functions, and properties modified
  • Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• Consistency across platforms for structures or concepts added or modified
• Consistency between the changeset and the goal stated above
• Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• Usage friction - is the proposed change in usage cumbersome or complicated?
• Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• Concurrency concerns - if components are accessed asynchronously, what issues will arise
• Thoroughness of added tests and any missing edge cases
• Idiomatic use of the language