WinForm Controls in IE, probing problem

[Guest]

Hi,

We have an application that consists of .NET WinForm controls hosted in IE
in ASPX pages. Up until now, the app has always run over local networks /
intranets and runs reasonably fast. However we have recently deployed this
in a hosted environment, where the client will connect to the web server over
the internet, and we're running into some significant performance issues
related to initial control load time. This happens even after the control
has been initially downloaded and resides in the download assembly cache.

Part of the problem seems related to "probing", where the CLR will (for some
unfathomable reason) continue to probe for the DLL in non-existent
directories, even after it has found it in the first directory. This was
discovered by looking in the server's IIS logs. I was able to resolve this
by using a config file, and referencing that config file in the aspx page.

However, this "fix" has now made the probing problem even worse, it is now
probing for a resources dll in even more directories, up to 16, and there is
no resources dll. For example, if my control is called MyControl.dll, with
the config file it now appears to look in only the right place for
MyControl.dll, then uses the one from the cache. However, it is now
searching for MyControl.resources.dll and MyControl.resources.exe in every
possible subdirectory. There is no MyControl.resources.dll. I tried adding
a MyControl.resources tag to my config file, pointing to the original dll,
but no luck.

Any ideas how I can get it to stop looking for a DLL that is not required,
does not even exist, in 16 directories that do not exist? Thanks for your
help.

Doug

 

[Guest]

I'm going to reply to my own post here, so that if anyone comes across this
in a newsgroup search, they'll know the answer (there's nothing more
frustrating than searching newsgroups and finding someone with the same exact
problem you have, and no replies).

As I stated below, the initial probing problem can be solved by using a
config file to specify the CodeBase for the dll, and ref'ing the config file
in the containing ASPX page.

The resources probing problem can then be solved by adding the following to
your AssemblyInfo.vb file in the WinForm control:

Imports System.Resources

' Set neutral resources language for assembly.
<Assembly: NeutralResourcesLanguageAttribute("en-us")>

That tells the CLR the DLL is neutral culture, and not to probe for a
supporting resources dll. This fix was provided to me by a very helpful
developer support person at Microsoft.

Doug