Here is a gotcha I was hit with this week. Figured I would share in case anyone else hits it.
I have an application that uses a windows forms control hosted in Internet Explorer using an <OBJECT> tag. We have installed CAS policy so that this control can communicate via remoting to our main application which is a locally running executable. This control references a configuration file using a tag in the page. In preparation for .NET 2.0 we had placed a <SUPPORTEDRUNTIME> tag into the configuration. Little beknownst to us IEHost ignores this tag yet does not throw an error when it is encounterd. We thought we were all set for .NET 2.0. Then we installed it and everything stopped working. Seems we missed this little tidbit:
All managed controls hosted by Internet Explorer use the latest version of the common language runtime installed on the computer. This means that in some instances the control may not run against the version it was built. This applies to any security zone, but does not apply to downloaded managed executables.
at MSDN. When our control was loaded into .NET 2.0 we lost the CAS policy we had installed to make things work and the control failed to even load.
The fix was to update the .NET 2.0 CAS Policy but there was no way we could automate this since any code we were running in the browser ran under .NET 2.0 which had no policy installed. Kind of a chicken and an egg thing.
BTW when we first called support they told us the solution was to create an iexplore.exe.config and use the supportedruntime tag there. I can't even believe they suggested this. It would basically bind internet explorer no matter what it was loading to version 1.1 of the framework! I could unwittingly break other peoples applications. Needless to say I indicated this was a non-starter.
When drilling into why Internet Explorer always loads the latest version of the framework I was told that an executable can only load one version of the framework. While technically true there are obviously ways around this. Take a look at how IIS uses the worker process to load multiple framework versions side by side, each in their own worker process. The Internet Explorer team could have probably come up with similarly clever solutions. It just wasn't worth the effort I suspect given the size of the feature. Too bad ClickOnce wasn't expanded to allow automatic policy elevation for <object> hosted controls. This would have solved our problem nicely.
Looks like we will have to send out an installer to install new policy and we will have to continue to do this each time Microsoft releases a new version of the framework. Lucky for us they aren't pumping out new versions every couple of months!