DefaultConfiguration.EnvironmentName throws exception when multiple environments are present

[chuseman]

When multiple environments are specified, the new implementation of the EnvironmentName getter (from #297) throws:

RoundhousE encountered an error.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidOperationException: Sequence contains more than one element
   at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] index)
   at roundhouse.infrastructure.app.tokens.TokenReplacer.create_dictionary_from_configuration(ConfigurationPropertyHolder configuration)
   at roundhouse.infrastructure.app.tokens.TokenReplacer.replace_tokens(ConfigurationPropertyHolder configuration, String text_to_replace)
...

The getter uses SingleOrDefault(), which only allows 0 or 1 elements in the list. I'm not sure how this getter should behave when multiple environments are present -- should it just do FirstOrDefault() maybe?

The problem actually stems from how TokenReplacer.create_dictionary_from_configuration() blindly uses reflection to fill a dictionary with all of the property name/values. If instead the ConfigurationPropertyHolder implementation filled the dictionary, it could reason about itself and not even set an EnvironmentName key if there are multiple EnvironmentNames perhaps?

I'd be happy to contribute a PR if somebody provides some direction.

[BiggerNoise]

@chuseman Thank you for reporting this. I apologize for the delay in getting back to you, it's been a madhouse here.

I agree with your idea, the configuration object should be able to take control of how it represents tokens.

So:

• Add a to_token_dictionary() to the ConfigurationPropertyHolder interface
• Move the implementation of create_dictionary_from_configuration to the DefaultConfiguration class renaming it so it implements to_token_dictionary()
• You can either spell out each property individually, encode the exceptions, or something else. I think that the issues will be dramatically reduced simply by having the two pieces of code right next to one another.
• Consider adding some test cases to roundhouse.tests/infrastructure.app to test some of your edge cases
• If you end up making more than one commit locally, squash it all down to one before you make your pull request.

[BiggerNoise]

Fixed by #329