Call a .NET class from a Gadget (without regasm.exe)

In some cases, a gadget developer would like to interact with the "world" outside of the sidebar such as libraries or applications to process some work. When it is a library, we already know that we are able to interact with COM component by using the ActiveXObject constructor (example: var xmldoc = new ActiveXObject("Microsoft.XMLDOM");).

They are also different ways to interoperate with an application or a web service using WCF like described by Karsten Januszewski on his blog

Or it is also possible to reference a Windows Forms UserControl in the OBJECT tag and CLASSID parameter using url#type where type is a fulltype name (namespace + class) in .NET. For an example, follow the link. But that will only work using http: in the url and it means that it will not work when the .NET assembly is local.

Another way would be to dynamically execute a command line application, pass it arguments and get back the standard output of the application to get some kind of processing result.

For our current solution, we will focus on the first described solution aka interoperate with a .NET assembly exposed as a COM component. Actually, this solution requires to register the .NET assembly using regasm.exe command. The solution described here bypass the use of the command and simulates the behavior of regasm.exe directly from javascript in the Gadget. 

So first, you need to have a .NET assembly exposed as a COM component (like described on Phil Wilson's blog). Then to simulate the regasm behavio, we need to have a list of registry entries that are added when registering a .NET assembly. The default behavior of regasm is to create registry entries in HKCR - HKEY_CLASSES_ROOT which won't fit a public deployment as many users are not admin of their machines. But what we know is that a user can modify registry entries under HKCR - HKEY_CURRENT_USER.

So first, we need to generate a .reg file using regasm.exe. For example, regasm.exe /regfile /codebase yourassembly.dll:





"Assembly"="DPAPIComLib, Version=, Culture=neutral, PublicKeyToken=3def732129791e7a"
"CodeBase"="file:///C:/Users/fredeq/AppData/Local/Microsoft/Windows Sidebar/Gadgets/mydotnet[1].gadget/bin/DPAPIComLib.dll"

"Assembly"="DPAPIComLib, Version=, Culture=neutral, PublicKeyToken=3def732129791e7a"
"CodeBase"="file:///C:/Users/fredeq/AppData/Local/Microsoft/Windows Sidebar/Gadgets/mydotnet[1].gadget/bin/DPAPIComLib.dll"


[HKEY_CLASSES_ROOT\CLSID\{C76D54A7-8472-44C7-AD7F-BA394E1D3900}\Implemented Categories\{62C8FE65-4EBB-45E7-B440-6E39B2CDBF29}]

Then, replace all HKEY_CLASSES_ROOT occurences by HKEY_CURRENT_USER\Software\Classes to be able to register your .NET assembly in the current user registry hive. Take a look at MSDN to have a detailed article on these deployment principles.

So now, we are at a stage where we know how to expose a .NET assembly as a COM Component, we know how to register a COM clsid/progid for a user without admin privileges, and finally we know how to update the registry using the WScrippt.Shell COM Component. So everything is here to dynamically register a .NET Assembly from a Sidebar Gadget.

Take a look at the following code (should be implemented/referenced in your Gadget):

function regAsm(root, progId, cls, clsid, assembly, version, codebase) {
var wshShell;
wshShell = new ActiveXObject("WScript.Shell");

//wshShell.RegWrite(root + "\\Software\\Classes\\", progId);
wshShell.RegWrite(root + "\\Software\\Classes\\" + progId + "\\", cls);
wshShell.RegWrite(root + "\\Software\\Classes\\" + progId + "\\CLSID\\", clsid);
wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\", cls);

wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\", "mscoree.dll");
wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\ThreadingModel", "Both");
wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\Class", cls);
wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\Assembly", assembly);
wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\RuntimeVersion", "v2.0.50727");
wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\CodeBase", codebase);

wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\" + version + "\\Class", cls);
wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\" + version + "\\Assembly", assembly);
wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\" + version + "\\RuntimeVersion", "v2.0.50727");
wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\InprocServer32\\" + version + "\\CodeBase", codebase);

wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\ProgId\\", progId);

wshShell.RegWrite(root + "\\Software\\Classes\\CLSID\\" + clsid + "\\Implemented Categories\\{62C8FE65-4EBB-45E7-B440-6E39B2CDBF29}\\", "");

Call this function using your own values (clsid, progid...). You find your values in the .reg file generated by regasm.exe:

function button1_click()
"DPAPIComLib, Version=, Culture=neutral, PublicKeyToken=3def732129791e7a",
System.Gadget.path + "/bin/DPAPIComLib.dll");

You may want to replace HKCU by HKLM when user is running the gadget as an administrator.

Then, after using regAsm funtion, you are able to call your .NET Class from the javascript as a COM Component like you do when using ActiveXObject.



sec =

new ActiveXObject("DPAPIComLib.DPAPIUserScopeCcw");

out.value= sec.Protect(

"Hello", "World");...

This is a first explanation of how to call .NET from a Gadget without registration issues. I will refine the information based on readers feedback and had some features like a tool/VS add-in to generate the regAsm call (the .js file) during development process based on reflection of the compiled assembly to be registered from Javascript.