I’m working with WinForms a project that has a couple of oddball requirements. This is an existing business system that is installed in numerous locations under a fairly wide variety of environments. Part of this variety is a mixture of SQL Server versions, and–of particular importance–SQL Server Reporting Services versions. Everyone is on at least 2005, but about 50% of our users are on some flavor of 2008.
Unfortunately for me, I need to be able to run a client-side report that’s written in 2008-version RDL. I can’t modify the report in any substantive way at this point, so rewriting it in 2005-version RDL isn’t an option. The catch is that this report (as it’s written in 2008) requires the 2008 ReportViewer control. However, the 2008 ReportViewer control cannot connect to 2005 SSRS.
The solution that I’ve come up with is more than a little hacky, but it will alleviate 90% of the problems introduced. I’ve left the references pointing to the 2005 version of ReportViewer, and I’m modifying the application configuration on startup to add assembly binding redirection tags moving from version 9.0.0.0 to 10.0.0.0 for ReportViewer.Common and ReportViewer.WinForms if the user’s target report server is running 2008.
As twitch-inducing as this solution is, it’s working for me. The users running SSRS 2005 can still access their existing reports, just not the new one. The users running SSRS 2008 can access everything. My only problem is that I haven’t been able to find a way to refresh the configuration data. I’m updating this info before any of the assemblies are loaded, but calling ConfigurationManager.RefreshSection("runtime") doesn’t appear to have any effect. Once the app restarts, the proper assemblies are loaded, but I’d really like to be able to have this change take effect immediately.
Any thoughts on how I can force the runtime to reload the binding redirection information from the App.config file at runtime?
Once the AppDomain is created, the configuration data that affects binding is fixed. Which happens on the default CLR when the primary AD is created, before your code starts running. If you are really desperate then you could create a secondary AppDomain and give it a custom AppDomainSetup with another ConfigurationFile. And loads and run your regular startup code in that AD. Not exactly sure what kind of side effects this might have.