I heard of a prospective client today looking for COM Interop experience, so I've put together a minimal demo to satisfy myself I still remember the essentials.
The shape is deliberately old-school: a .NET Framework class library exposed as a COM server, called from a .vbs file through Windows Script Host. That matters because cscript.exe is not doing anything .NET-native here. If VBScript can create ComInteropDemo.ExampleService and call methods through IDispatch, the registration, ProgId, bitness, and marshalling path are all doing what they should.
src/ComInteropDemo- .NET Framework 4.8 class library exposed to COM.clients/vbscript/test-com.vbs- the main smoke test, using unmanaged late binding.clients/powershell/test-com.ps1- a handy optional check from PowerShell.scripts/Test-Prerequisites.ps1- checks the local machine has the bits this demo expects.scripts/Test-ComDemo.ps1- runs the VBScript client using the matching script-host bitness.scripts/Register-ComDemo.ps1- builds and registers the assembly with 32-bit or 64-bitRegAsm.scripts/Unregister-ComDemo.ps1- unregisters the assembly.
This is intentionally a Windows-only demo.
On a current Windows 10 or Windows 11 machine, the .NET Framework 4.x runtime is usually already there. This project targets .NET Framework 4.8 because it is old enough for the classic COM tooling path, but modern enough to be present on normal current Windows installs.
There are still a few separate things to check:
- .NET Framework 4.8 or later runtime.
- .NET Framework 4.8 targeting/reference assemblies, so the project can build.
- A .NET SDK on
PATH, because the helper script builds withdotnet msbuild. RegAsm.exe, which does the COM registration.- Windows Script Host (
cscript.exe), which runs the VBScript client.
I would not silently install any of these from a demo script. .NET Framework and COM registration are machine-level concerns, so the repo checks and reports what is missing instead.
.\scripts\Test-Prerequisites.ps1If the runtime is missing, install or enable the current supported .NET Framework 4.x runtime from Microsoft. If the build fails because reference assemblies are missing, install the .NET Framework 4.8 Developer Pack or the Visual Studio ".NET desktop development" workload.
From an elevated PowerShell prompt:
.\scripts\Register-ComDemo.ps1 -Architecture x64
.\scripts\Test-ComDemo.ps1 -Architecture x64Expected output:
Version: C# COM engine active via IDispatch ...
Input: 42.5
Result: 2077.1875
For a 32-bit client, register and run through the 32-bit script host:
.\scripts\Register-ComDemo.ps1 -Architecture x86
.\scripts\Test-ComDemo.ps1 -Architecture x86Those helper scripts resolve paths from their own location, so they do not care whether the current prompt is at the repo root or inside scripts. If I run the .vbs directly with cscript.exe, I need to give it a path that is correct for my current directory.
RegAsm may warn that /codebase is intended for signed assemblies. In this context that means a .NET strong name, not an Authenticode/code-signing certificate. Strong naming would be enough to remove the warning, but I have left it out of the demo source so there is no checked-in demo key file pretending to be a real signing practice. For anything installed on someone else's machine, I would strong-name the assembly and use a proper installer or registration step instead.
- Use an explicit COM-visible interface rather than relying on an auto-generated class interface.
- Give the class a
ProgId, because VBScript and VBA wantCreateObject("ComInteropDemo.ExampleService"). - Keep 32-bit and 64-bit registration separate in your head. They land in different registry views, and the script host bitness has to match the
RegAsmyou used. - VBScript is the better proof than PowerShell here. PowerShell is convenient, but VBScript is a cleaner check that the old unmanaged automation path actually works.
.\scripts\Unregister-ComDemo.ps1 -Architecture x64Use -Architecture x86 as well if you registered both bitnesses.