Okay. I have gotten this to work with a wedge DLL. All of the stuff seems
to be working as of right now with this extra wedge.
I had a code problem where I was throwing an uncaught exception on the
managed code side of things. Something stupid. The static varibles stuff
must have been happening when I ran "caspol -i off" with just a managed dll.
What really makes you crazy with this now is that it is so easy with VS2005
to switch an ATL application to a managed C++ application. A filter works
great but and extension is totally whacked and the error you get isn't very
intuitive.
Regards
Frank
"Frank Postle" wrote:
> My reading appears to indicate that there is a bug in the way that IIS
> accesses extensions. A unc path (\\?\) instead of a local path, this results
> in some sort of security policy exception.
>
> Is this something that is going to be fixed? If it isn't then does anyone
> know of a good work around? I have tried to build an unmanaged wedge in
> between IIS and the managed DLL. My first look this didn't work either, but
> I am going to look at this again.
>
> I have done this before but I have only used assemblies from the GAC and not
> managed classes declared locally. I am not sure what is going on here.
>
> I have tested this a bit with "caspol -s off" and there seemed to be an
> issue where the static variables within a managed class weren't scoped the
> same between the filter and the extension. I have a combined
> filter/extension set of dll's (1 unmanaged dll with ext and filter and 1
> managed dll with ext and filter). In the filter a static value of a class
> isn't the same value. It is as if that there is some sort of scoping that
> generates two separate sandboxes in the same apppool (process).
>
> Any help or guidence would be greatly appreciated.
>
> Regards
>
> Frank
FAQ
Profile
Private Messages
Log in
