Signed assembly will not load in internet explorer

[Mombiatch]

I've got an assembly that implements a class that inherits
System.Windows.Forms.UserControl. This works wonderfully when I embed it in
an ASP.NET page, using the <object clsid="whatever.dll#namespace.class"
id="formcontrol"></object> tag. This works when the assembly isn't signed,
but as soon as I sign it, the control no longer loads. Any ideas?

I'm also struggling to get jit debugging enabled. I followed the directions
to set <system.windows.forms jitDebugging="false" /> into the <configuation>
section of machine.config or web.config for the site (hosted in IIS) - to no
avail - the dialog saying a security exception has occured still comes up,
no way to attach a debugger. Any ideas? I also tried putting it in the
whatever.exe.config file.

One final question is about the location of downloaded assemblies. I've seen
references to %windir%\assembly\downloaded2 directory, but this doesn't
exist on my win2k3 machine. I can see the downloaded assemblies using
gacutil though - was wondering where these are stored and if there is an
easy way to delete specific assemblies (to force it to be downloaded again
when it changes) I have seen that the version number seems to be
automatically incremented in VS.NET, maybe this led to a design change for
enhanced security?

Thanks
Joe

[Mombiatch]

I've noticed some behaviour that might point to a solution, which of course
I can't find :-P I looked at the IIS log in
%windir%\system32\logfiles\ex<date>.log and found that my page was
requesting the dll representing the UserControl:
(Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+.NET+CL R+1.1.4322)
clipped from each log entry)

2004-07-26 07:55:52 127.0.0.1 GET /ProductIssues/mediaclient.dll - 80 -
127.0.0.1 200 0 0

And got 200 - success. However, it then attempted to get the dll from
everywhere else:

2004-07-26 07:55:54 127.0.0.1 GET /MediaClient.DLL - 80 - 127.0.0.1 404 0 2
2004-07-26 07:55:54 127.0.0.1 GET /MediaClient/MediaClient.DLL - 80 -
127.0.0.1 404 0 3
2004-07-26 07:55:54 127.0.0.1 GET /bin/MediaClient.DLL - 80 - 127.0.0.1 404
0 2
2004-07-26 07:55:54 127.0.0.1 GET /bin/MediaClient/MediaClient.DLL - 80 -
127.0.0.1 404 0 2
2004-07-26 07:55:54 127.0.0.1 GET /MediaClient.EXE - 80 - 127.0.0.1 404 0 2
2004-07-26 07:55:54 127.0.0.1 GET /MediaClient/MediaClient.EXE - 80 -
127.0.0.1 404 0 3
2004-07-26 07:55:54 127.0.0.1 GET /bin/MediaClient.EXE - 80 - 127.0.0.1 404
0 2
2004-07-26 07:55:54 127.0.0.1 GET /bin/MediaClient/MediaClient.EXE - 80 -
127.0.0.1 404 0 2

With 404's on all of those obviously. Does anyone have any idea what could
cause this sort of behaviour? I tried with an unsigned version of the dll
though, and it produced the same effect, so perhaps this isn't relevant.
Interestign behaviour though

Thanks
Joe

"Mombiatch" <mombiatch@invalid.com> wrote in message
news:RqqdnazWZeLgWZ3cRVn-ow@is.co.za...

> I've got an assembly that implements a class that inherits
> System.Windows.Forms.UserControl. This works wonderfully when I embed it

in

> an ASP.NET page, using the <object clsid="whatever.dll#namespace.class"
> id="formcontrol"></object> tag. This works when the assembly isn't signed,
> but as soon as I sign it, the control no longer loads. Any ideas?
>
> I'm also struggling to get jit debugging enabled. I followed the

directions

> to set <system.windows.forms jitDebugging="false" /> into the

<configuation>

> section of machine.config or web.config for the site (hosted in IIS) - to

no

> avail - the dialog saying a security exception has occured still comes up,
> no way to attach a debugger. Any ideas? I also tried putting it in the
> whatever.exe.config file.
>
> One final question is about the location of downloaded assemblies. I've

seen

> references to %windir%\assembly\downloaded2 directory, but this doesn't
> exist on my win2k3 machine. I can see the downloaded assemblies using
> gacutil though - was wondering where these are stored and if there is an
> easy way to delete specific assemblies (to force it to be downloaded again
> when it changes) I have seen that the version number seems to be
> automatically incremented in VS.NET, maybe this led to a design change for
> enhanced security?
>
> Thanks
> Joe
>
>