IEXPLORE.EXE.config

  • Thread starter Thread starter Marian Veteanu
  • Start date Start date
M

Marian Veteanu

Hello,

I have an HTML page that contains an <OBJECT> tag:

<OBJECT id='XfdContainer'
classid='http://localhost/XfdRuntime/StarLIM...tarLIMS.Web.XfdRuntime.XfdViewer.XfdContainer'
VIEWASTEXT>
</OBJECT>

The StarLIMS.Web.XfdRuntime.dll assembly and the other statically
linked assemblies (at compile time) are downloaded successfully. The
problem appears when I try to load an assembly dynamically. The
loading fails because the AppBase is http://localhost/ and not my
virtual directory that contains all binary assemblies:
http://localhost/XfdRuntime/

To fix this problem I've create an IEXPLORE.EXE.config file under
http://localhost with this content:

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="XfdRuntime"/>
</assemblyBinding>
</runtime>
</configuration>

I don't like this solution too much, so I'm wondering if there is any
other method to solve the problem of location assemblies. I don't want
to install them in GAC.

Thank you,
 
I was experiencing this same problem, and I figured out how to fix it.
For some reason, specifying the configuration file in your web page
that has the <object> tag causes IEHost to use the configuration file
url as the CodeBase for the AppDomain.

To specify a configuration file, see
http://msdn.microsoft.com/library/d...guide/html/cpconconfiguringieapplications.asp.
Here's the code:

<html>
<head>
<!-- Reference to the configuration file. -->
<link rel="Configuration"
href="www.adventure-works.com/webApp/StockCalc/StockCalc.config"/>
</head>
<body>
<object id="StockCalc" width=100 height=100
classid="StockCalc.dll#StockCalcControl">
</object>
<! -- Put the rest of the HTML code here. -->
</body>
</html>

In this example, the CodeBase of the AppDomain would be
http://www.adventure-works.com/webApp/StockCalc/.

In fact, you don't even have to put anything in the configuration file!
My config file just contains '<configuration></configuration>'. The
reason for this is that since the CodeBase is set properly, you don't
have to set up all sorts of Fusion redirection, private bin paths, and
<codebase> tags. It just works.

Another trick is to use the
[assembly:System.Resources.NeutralResourcesLanguage([culture])]
attribute on all of your downloaded assemblies that contain resources.
This will prevent the client from attempting to download all the
resource files when the client's culture is the same as the main
assembly's culture.
 
Back
Top