Initialise BasicHttpBinding object from file other than app.config?

Question

I currently have code, in C#, that requires a BasicHttpBinding object to connect to SSRS. As it stands, I initialise this object using values assigned in code, rather than reading it from the app.config (this is because the platform I'm deploying to, MS CRM 2011, does not provide access to the app.config file for reading. In fact, I don't think the app.config file even gets copied to the server).

I'd like to make this binding editable without recompiling so the solution can be installed easily at different customers. The cleanest way I can think of is to have the binding config stored in a web-resource (for non-CRM people, this is just a name for a file stored inside CRM that you can access from code), but I'm not sure of the best way to parse that config into a BasicHttpBinding object? Manually parsing it and setting the properties seems inefficient and not very robust.

Is there any way of getting .NET to to it for me (similar to the BasicHttpBinding(string) constructor, but since I don't have access to app.config this isn't an option)?

Answer 1

Given the (presumably) low volatility of this configuration, could you not store it in the plug-in secure / unsecure configuration in your plug-in registration step? Accessing this at runtime would be significantly quicker that connecting to CRM to retrieve the contents of a web resource. Granted, it means that you require the plug-in registration tool and a sys admin to make changes but it also means that any sensitive data is obfuscated from users. App.config for a plug-in is indeed unavailable - but then that's what your config section in the plug-in step are for.

As far as using the constructor for BasicHttpBinding It sounds like you're looking for a way have all of the constructor magic done for you by just passing the key name for a config section. I don't believe that this will be possible but in any case your suggestion that " Manually parsing it and setting the properties seems inefficient " is probably unfounded - after all that's exactly what the native constructor will ultimately be doing anyway. Hide it behind a function and you'll never know it's there ;)

I have connected to the SSRS web service in plugins previously (beware - not supported in CRM Online due to service not being exposed :( ) and I took my usual approach of storing config, as above, in the plugin configuration and then read it into an XmlDocument at runtime then parsed out the values as required to instantiate objects/set properties.

So long as the config is the same for all requests to the plugin, you can also potentially afford some efficiencies by setting the config values (not the connection itself) as class-level properties in your plugin (even though this is against advise in the SDK - but that's due to thread-safety which shouldn't be an issue with "static" config values such as this) and only read the values from config if they are not already set.