HiQuote:
Originally Posted by cobraeye
I too have same problem here.
Please inform me how you have Unregistered the dll .
Thank you
Printable View
HiQuote:
Originally Posted by cobraeye
I too have same problem here.
Please inform me how you have Unregistered the dll .
Thank you
Actually it is about how to create a .NET DLL that can be used in ASP/VB. I found an article a while back and I tried to find it for you but unsuccessful. You can try to google it. Basically the steps involve
1. create GUID for your .NET DLL
2. use regasm.exe /tlb to register and unregister your DLL.
Good Luck
Thanks,
When I try to Unregister, Its saying "....Consider using PView to Detect and remove it.."
Inform me How to detect and remove dll using Pview..
Thanks
The problem with registering a .Net object for COM interop is COM doesn't know where to find your DLL even after you register it. You must add the CodeBase registry entry which points to your DLL's location. The easiest way to do that is with an installer. Build an installer, extract the registry information, then add the CodeBase. Most installers will allow you to use a variable for this purpose so if the user installs the DLL to a different folder, the CodeBase will always point to the correct location. For example, in InstallAware, on the Registry tab, you can click the Import button which allows you to browse to your DLL. Once you select it, it will automatically import the registry settings for you. However, you must still add the CodeBase with code similar to this: Key = CodeBase Value = $TARGETDIR$
Here's something else to keep in mind. When creating a DLL for COM interop, there can only be one public class with a single, non-parameterized entry point. Be sure to mark any other classes or functionality you don't wish to expose as Internal (C#) or Friend (VB).
You also might want to specify the COM interface. That allows you to assign dispatch ID's to each property and method. This is important in case you ever change things. COM doesn't guarantee the order in which things are registered but if you specify an interface, you can control it so if you add new functionality, you don't break existing objects that use your DLL (i.e. DLL hell).
I realize that it'll take some research into creating an installer and/or creating a COM interface but I leave that as an exercise for you. I just wanted to point out the fact there is more to writing a COM object in .Net than appears at first.