Home/ Questions/Q 6223601
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T08:31:04+00:00

I have a C++ DLL project which is created in VS 2010. It is

  • 0

I have a C++ DLL project which is created in VS 2010. It is exposed as COM(ATL). I used this dll to another .NET Project as reference. C++ Project linker settings are set as follows:

­"Register Output" = Yes
"Per-user Redirection = Yes

I created a build definition to build these two projects in tfs 2010. C++ Project builds fine, but .NET project fails because the output dll of C++ project is not registered. Setting to “Per-User redirection” = false does not work. I also tried using WF activity ‘InvokeProecss’ to register the c++ dll using Regsrv32/batch file/my own exe etc, but I get exit code of 5. My TFS 2010 is in Windows 2008 Server R2. And I think, it’s not running the process as admin.

If I generate a interop dll using tlbimp, and then I refer that interop in my .NET proejct, it works fine(oviously in tfs build, I need to add InvokeProecss to call tlb). But this is not acceptable as our general practice is to refer a COM dll directly from .NET proejct.

Can anybody please help about this?

Is there a way to run the tfs automated build activity ‘InvokeProcess’ as Administrator without prompting for user name/password?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    By default, the TFS Build Service runs as the “Network Service” account which is a relatively low-privilege account. Alternatively, you can configure it to run as any domain account you like. I wouldn’t recommend that as a solution to the problem you described, however. I would agree with Hans that, in this case, it would be better to use the type library importer (TlbImp.exe) to “reference” your COM server from your managed assembly.

    If the COM object isn’t changing, you can just use the type library importer to generate an interop assembly, check that in and reference it from your .NET project. If it is changing, you can add a post-build step to generate the interop assembly rather than using the InvokeProcess activity. As Hans pointed out, you can’t actually reference a COM object directly from a managed assembly. Your reference is actually causing an interop assembly to get generated at build time after resolving the reference to the registered COM server.

    • 0