How to make Activex.dll safe in C#

I have created a Activex dll in c# using Visual Studio 2005 by marking the component as "Mark as COM visible" in the compile properties of project. I will be using this code in the javascript. Now I want to mark this activex dll as safe. I have searched in the net and came to know the two possible solutions for doing this are: -

1. Implement IObjectSafety interface
2. Add a typical CLSID values in the DllRegistryMethod of activex registration.

But no where step by step instructions were given for doing this. Please help me in marking the activex dll as safe which was developed in c# using Microsoft Visual Studio 2005.

Thanks,

Is the ActiveX for the client, or for the server?

If for the server, just use a direct reference to the managed assembly (no need for COM).

Re the client, frankly I'm not sure it is a good idea to be writing ActiveX controls - most browsers won't love them. You'd do better with AJAX and DHTML, or Silverlight / Acrobat / etc for something more complex.

[update] So you want ActiveX at the client... my next though would be "can Silverlight access the certificate store?" I can't find anything, though...

Distributing an ActiveX control (for IE) is usually a matter of packaging the dll into a cab, marking it as safe for scripting and safe for activation. You then place the cab on the web-server, and on the edge you have an <object...>...</object> element specifying the source (code-base) of the cab.

I have to stress that this approach is going to be very hit-and-miss; it won't work on many browsers, and will work some of the time on IE (depending on the user's security settings). I don't recommend it.

A more practical option might be to write a standalone .NET exe that you package via ClickOnce ("Publish" in VS); drop the ClickOnce deployment on the web-site, and navigate to the application. check - full .NET code at the client, without the browser issues.

Working with .dlls isn't difficult, but a few simple tips should make your experience smoother. Don't forget that you must register a .dll to use it. To register an ActiveX .dll, use the Windows API call:
Public Declare Function .DLLSelfRegister Lib "vb6stkit.dll" (By Val lp.dllName As String) As Integer

After modifying a .dll, you may need to re-register it if you added a new class or you copy the source to another development computer (something you should try to avoid). Compiling an ActiveX .dll assigns a unique identifier to the file. If you copy the source to another machine and then compile it there, the identifier changes to reflect the current computer. Consequently, each time you copy the .dll to the Web server, you will have to reregister it, regardless of the type of development changes you made to the source.

Working with .dll files does require that you manually restart the server occasionally. The easiest way to manually restart Internet Information Server (IIS) is to connect via Computer Management (a Windows 2000 utility). The Web server service is called World Wide Web Publishing Service. If you have the Windows 2000 Server Resource Kit, you can use the service.vbs tool and run the batch file:
C:
cd\
cscript service.vbs /X /N W3SVC /S IISmachinename
pause
cscript service.vbs /G /N W3SVC /S IISmachinename

When debugging the .dll, use Visual Basic's Debug feature, which allows you to walk through your code when you load an ASP page. You can learn more about debugging Visual Basic .dll files within Visual Basic from the Microsoft Knowledge Base.

If the code is not thread-safe, then it's not thread-safe, and you'd better not call it from a web service.

Assuming you can't get the authors to fix their code for this environment (or to rewrite in managed code), then you should consider creating a separate server for that DLL and communicating between the Web Service and this separate service using .NET Remoting. In effect, you'll need to make sure that the DLL is only ever accessed from a single thread, from the time it's initialized, through all of the calls, to the time it is uninitialized.

Still, let's not get ahead of ourselves on the threading. You still haven't told me exactly what the problem is - what variable is being set to Nothing when you expected it to be set to something else?