Home
TeamSite
Implement VB.Net Sample Custom Command
robcom
I am attempting to do a simple proof of concept at the moment, but am having trouble implementing the VB.Net sample custom command supplied with the SDK: VBNETIManEvt. At the final step, the command simply does not appear on the Document menu.
I have implemented the matching VB6 sample custom command: MyVBIManEvt
I have completed the following steps for VB6. This works.
Open MyVBIManEvt in VB6 and build the DLL: ImanEvtTemplate.dll
Copy the DLL to the test client and register the DLL using REGSVR32.exe:
RegSvr32.exe "C:\ImanTest\ImanEvtTemplate.dll"
Edit the Doument menu registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Interwoven\WorkSite\8.0\FileSite\Commands\Document]
"Commands"="...,-,ImanEvtTemplate.MyEditProfileCmd,-,..."
Start Outlook and Test
WORKS: The command appears between the dividers, and executes OK.
So I try similar for the VB.Net sample: (This fails)
Open MyVBNETIManEvt in MS Visual Studio 2005 and upgrade (converts OK):
Check the 'COM visible' property is ticked.
Build the DLL (release): VBNETIMANEvt.dll
Copy this DLL and all others created to the test client (C:\windows\system32)
Register the .Net DLL using REGASM.exe
regasm "C:\WINDOWS\system32\VBNETIManEvt.dll"
(> Types registered successfully)
Edit the Doument menu registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Interwoven\WorkSite\8.0\FileSite\Commands\Document]
"Commands"="...,-,VBNETIManEvt.MyEditProfileCmd,-,..."
Start Outlook and Test
FAILS: The bracketing dividers appear in the document menu with no command appearing in between.
I looked a bit at GacUtil, but this requires strong names, and attempting to implement a strong name produces the error: "Referenced assembly 'Interop.IMANEXTLib' does not have a strong name". - Dropped.
The files were moved into the C:\windows\system32 after reading a bit more on this, but doing REGASM again and re-testing made no change.
Ideas on what step is missing?
Find more posts tagged with
Comments
guido1
I don't know what state the sample VB.NET code is in, however most likely your attempt to register the COM DLL has failed.
This could be because you haven't done one of the following:
set the assembly to be visible to COM. Look at the project properties, and then in VB.NET I believe it's the Compile tab. In there you should see a checkbox to switch on COM interop
your class may not be visible to COM: make sure its scope is public; as a safety measure you can even decorate the class itself with the attribute
Once you've done this there's no need to use the REGASM tool: when you compile the project Visual Studio will automatically launch it for you each time you compile the project.
What you should see in the registry, under HKCR, is the prog ID of your class, i.e. . - in your example VBNETIManEvt.MyEditProfileCmd
If you can see that in HKCR then you know that registration has failed
Hope that helps!
robcom
Thanks, but no solution.
The .Net assembly is COM visible:
> Application (tab), Assembly Info (button), Make Assembly COM visible (tick)
The public class is:
Public Class MyEditProfileCmd
Implements IMANEXTLib.ICommand
On the TEST PC, there is an entry in HKCR.
[HKEY_CLASSES_ROOT\VBNETIManEvt.MyEditProfileCmd\CLSID]
@="{3E30F13E-F581-3AB7-9BC3-285311037BDF}"
Now, I expect that if a registry entry is created here that the Registration has SUCCEEDED (not failed?)
guido1
So if you are confident the assembly is registered to COM then the problem is most likely your definition of the registry entry within the WorkSite registry hive
Looking at your original post a little closer I can now see that on the one hand you have defined (either explicitly or implicitly) the ProgID attribute of your class as "VBNETIManEvt.MyEditProfileCmd".
On the other hand your WorkSite registry entry in your original message specifies a prog ID of "
ImanEvtTemplate
.MyEditProfileCmd".
They need to match one another otherwise the WorkSite client will never find the correct COM component to load.
Just to be sure I just ran up a quick test using the SDK example you were using and it works beautifully, i.e. I built the VBNETIManEvt.MyEditProfileCmd sample which also registers the assembly for COM, then entered "VBNETIManEvt.MyEditProfileCmd" in to an appropriate part of the WorkSite registry, and then fired up a client to see that the command had been correctly added to one of the context menus
robcom
The different references are explained as there are TWO dlls tested:
[VB6] = ImanEvtTemplate.MyEditProfileCmd (WORKS)
[VB.Net] = VBNETIManEvt.MyEditProfileCmd. (FAILS)
[VB6] = RegSvr32.exe creates:
[HKEY_CLASSES_ROOT\ImanEvtTemplate.MyEditProfileCmd\Clsid]
@="{3D265A98-1913-48FF-8884-825EB7BB7C2C}"
The following regkey makes the command show in the Document menu:
[HKEY_LOCAL_MACHINE\SOFTWARE\Interwoven\WorkSite\8. 0\FileSite\Commands\Document]
"Commands"="...,-,ImanEvtTemplate.MyEditProfileCmd,-,..."
[VB.Net]
On my VisualStudio 2005 PC, building the DLL does NOT auto-create an HKCR key,
However: 'RegAsm.exe VBNETIManEvt.dll' creates the key:
[HKEY_CLASSES_ROOT\VBNETIManEvt.MyEditProfileCmd\CLSID]
@="{202722BE-37F6-34FF-A03E-66B7F10BF8C8}"
The following regkey does NOT make a command show in the Document menu:
[HKEY_LOCAL_MACHINE\SOFTWARE\Interwoven\WorkSite\8. 0\FileSite\Commands\Document]
"Commands"="...,-,VBNETIManEvt.MyEditProfileCmd,-,..."
As my .NET DLL does not create the HKCR registry when building, I agree that there seems to be an issue with how the .Net DLL is configured to be exposed to COM. My HKCR keys is only created when I run RegAsm.exe. As I have checked:
The .Net assembly is set as COM visible:
> Application (tab), Assembly Info (button), Make Assembly COM visible (tick)
The class is public:
Public Class MyEditProfileCmd
Implements IMANEXTLib.ICommand (etc).
I wonder if the upgrade to Visual Studio 2005 added something. I will compare the original .vb files. Guido, what version of Visual Studio did you compile the VBNETIManEvt sample with?
Robert
archer9
Hi Robert,
Just a thought, you might find you need to use the /codebase option when you manually register the dll using regasm. This should create the path information for an assembly that is not installed in the GAC. So something like:
RegAsm.exe /codebase "Path To Assembly"
I hope this helps.
Regards,
Roger
guido1
I don't think the conversion to VS2005 should have affected anything. In fact, although I was basing my tests for you on VS2008, I have just tried it with a VS2005 VM and it works fine there to.
Both versions of VS will internally run the REGASM utility when the project is compiled and if it is set to be registered for COM interop. I'm not certain why in your environment this isn't the case.
As archer9 suggests you can try adding the /codebase switch, although this is intended for strong-named assemblies that are destined for the GAC.
If you're going to register the DLL manually I would add to his suggestion that you also apply the /tlb switch to generate the appropriate COM type library for your assembly.
In other words, if you are manually going to register your assembly you might enter in something like:
regasm VBNETIManEvt.dll /codebase /tlb
This should register your DLL as a COM visible assembly (with the Codebase registry entry), and also output a type library (VBNETIManEvt.tlb) in the same folder.
As I say, though, you really shouldn't need to do any of this! The SDK example you are using works like a charm in a standard Worksite 8.x install with VS2005 (or VS2008 for that matter).
Best of luck..!
robcom
Waaahoo. It appears adding the /codebase parameter sorted the issue. (I had just found a similar recommendation via Google)
Thank You.