G
Guest
I have an issue with using a .Net DLL as a COM object in an ASP.NET page.
First a little background.
1. The web application is for intranet use only.
2. The web site will be included in the Trusted Zone
3. Access is required to the local file system to move a file from there to
a designated network share.
4. The user must be able to pick the file in question
5. Design requires that the OpenFileDialog filter the extensions
6. A separate necessity is to use a DLL (unmanaged) that is provided by a
third party and known to exist in the file system and be accessed from the
DLL.
What we have in place currently works but is clumsy. The .Net DLL is built
into an install package. Using the OBJECT tag we look for a certain clsid. If
it's not there the install runs and installs the DLL, places it in the GAC,
and performs a REGASM for COM interop. It works great until a change is
needed in the object. The install package needs to be rebuilt, CLSID needs
changed, install package needs uploaded and then the user must accept the
install.
What I would like is something more transparent. Unfortunately the
transparent options don't work like I want.
If I use the OBJECT tag in the page (<object id="myobject"
classid="http://server/myobject.dll#myobject.myclass"...></object> and do not
sign the dll with a strong name key, I can use the classes in Java Script as
long as no FileIO happens (it needs to). If I use a strong name key then the
methods seem to disappear for use in Java Script. I figured using strong name
would allow me to modify the Code Access Security but it doesn't seem to work.
Any help would be greatly appreciated.
Thanks,
Erik
First a little background.
1. The web application is for intranet use only.
2. The web site will be included in the Trusted Zone
3. Access is required to the local file system to move a file from there to
a designated network share.
4. The user must be able to pick the file in question
5. Design requires that the OpenFileDialog filter the extensions
6. A separate necessity is to use a DLL (unmanaged) that is provided by a
third party and known to exist in the file system and be accessed from the
DLL.
What we have in place currently works but is clumsy. The .Net DLL is built
into an install package. Using the OBJECT tag we look for a certain clsid. If
it's not there the install runs and installs the DLL, places it in the GAC,
and performs a REGASM for COM interop. It works great until a change is
needed in the object. The install package needs to be rebuilt, CLSID needs
changed, install package needs uploaded and then the user must accept the
install.
What I would like is something more transparent. Unfortunately the
transparent options don't work like I want.
If I use the OBJECT tag in the page (<object id="myobject"
classid="http://server/myobject.dll#myobject.myclass"...></object> and do not
sign the dll with a strong name key, I can use the classes in Java Script as
long as no FileIO happens (it needs to). If I use a strong name key then the
methods seem to disappear for use in Java Script. I figured using strong name
would allow me to modify the Code Access Security but it doesn't seem to work.
Any help would be greatly appreciated.
Thanks,
Erik