How to register .net 8 build activex so that test program can run access it from different folder

Oliver Lan 0 Reputation points
2025-04-17T19:07:44.5333333+00:00

I can run C:\Windows\syswow64\regsvr32 to register my activex.dll which is stored at the C:\Program Files (x86)\AA but the test program, test.exe, could not access it from C: \Program Files (x86)\BB folder.

Any thought?

Developer technologies | .NET | .NET Runtime
{count} votes

8 answers

Sort by: Most helpful
  1. Bruce (SqlWork.com) 77,686 Reputation points Volunteer Moderator
    2025-04-17T19:44:56.7166667+00:00

    is test.exe a 64 bit application (if so, why in x86 folder)? also as .net 8 can only build 64 bit active/x dlls, it should probably should be in the "program files\aa" folder.

    note: regsvr32 is also used to register 64 bit active.x controls.

    0 comments No comments

  2. RLWA32 49,541 Reputation points
    2025-04-17T21:42:54.8333333+00:00

    By default VS2022 .Net 8 projects will create 64-bit COM components. Even when building for AnyCPU VS2022 will create a 64-bit Yourfile.comhost.dll which is what is passed to regsvr32.exe for COM registration.

    However, in Expose .NET Core components to COM under "Additional Notes" there is guidance that says "The NETCoreSdkRuntimeIdentifier MSBuild property determines the bitness of *.comhost.dll."

    So in the DllServer project available at OutOfProcCom I added a property to the DllServer.csproj file as shown below -

    <Project Sdk="Microsoft.NET.Sdk">
    
      <Import Project="..\Contract\Server.Contract.props" />
    
      <PropertyGroup>
        <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
    
        <!-- Indicate the assembly is providing a COM server -->
        <EnableComHosting>true</EnableComHosting>
    
        <!-- Added to create 32-bit COM Server -->
        <NETCoreSdkRuntimeIdentifier>win-x86</NETCoreSdkRuntimeIdentifier>
    
      </PropertyGroup>
    
      <ItemGroup>
        <ProjectReference Include="..\COMRegistration\COMRegistration.csproj" />
      </ItemGroup>
    
      <Target Name="ServerUsage" AfterTargets="Build" DependsOnTargets="AssignTargetPaths">
        <Message Importance="High" Text="%0a************************************%0a*** $(MSBuildProjectName) usage instructions ***%0a************************************" />
        <Message Importance="High" Text="The server must be COM registered in order to activate.%0aThe following commands must be executed from an elevated command prompt." />
        <Message Importance="High" Text="Register:%0a    regsvr32.exe &quot;$(ProjectDir)$(OutputPath)$(ComHostFileName)&quot;" />
        <Message Importance="High" Text="Unregister:%0a    regsvr32.exe /u &quot;$(ProjectDir)$(OutputPath)$(ComHostFileName)&quot;" />
      </Target>
    
    </Project>
    

    After building and registering the COM in-process server it was successfully instantiated by a 32-bit COM client.

    0 comments No comments

  3. RLWA32 49,541 Reputation points
    2025-04-18T01:27:08.2333333+00:00

    But still the activex.dll and its test program has to be at the same folder for test program to be able to load the activex.

    Sounds like there is a problem with the COM registration of the server.

    One possible cause is if the registration does not include the fully qualified path to the dll.

    For example, the following example would cause the problem -

    BadRegServer

    For the .Net 8.0 COM server project (DllServer) the registration looks like this -

    comhost

    DllServer.comhost.dll and DllServer.dll are in the same folder. The COM client application can be in a different folder and instantiate the COM object without a problem. The COM runtime can find the server because InProcServer32 contains the fully qualified path.


  4. RLWA32 49,541 Reputation points
    2025-04-23T21:35:54.2566667+00:00

    @Oliver Lan,

    If you are creating your in-process COM server using the .Net Framework (i.e., not .Net 8.0) then the command to register it should be --

    regasm activex.dll /codebase /tlb
    

    The /codebase parameter ensures that the fully qualified path to the dll is included in the registry.


  5. Oliver Lan 0 Reputation points
    2025-05-05T23:50:45.9166667+00:00

    I talked to Microsoft support engineer today, they give me a way to find the activex from the application at the different location:

    AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>

    {

                var assemblyName = new AssemblyName(args.Name).Name;
    
                    if (assemblyName == "ActiveXName")
    
                    {
    
                        string path = @"C:\Program Files (x86)\MyTestActiveX\ActiveXName.dll";
    
                        if (File.Exists(path))
    
                        {
    
                            return Assembly.LoadFrom(path);
    
                        }
    
                        else
    
                        {
    
                            MessageBox.Show($"The assembly {assemblyName} was not found at the specified path: {path}");
    
                        }
    
                    }
    

    };

    RLWA32 thank you so much, very appreciated


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.