COM Interop Problem on 64 bit system with Windows Forms LocalServer

i have windows forms application exposes coclass oneinterface throug com.

in order have run local server , not inproc, have post-build actions involving 64-bit regasm, using 64-bit reg.exe replace inprocserver32 registry entry localserver32 entry.

btw impossible have vstudio invoke 64-bit reg.exe putting whole path windows\system32\reg.exe in build action. vstudio wants start 32 bit reg.exe. way make copy of 64bit reg.exe , put under  name in ouputdir-folder.

also, put call registrationservices.registertypeforcomclients in main method before application.run(new mainform()) call.

registrationservices svcs = new registrationservices();
int scookie = svcs.registertypeforcomclients(typeof(test), registrationclasscontext.localserver, registrationconnectiontype.multipleuse);

when in 32-bit system (using 32-bit regasm , reg.exe) works fine. 

the behahvior following: when com client creates com object, , windows forms app running, directly hands out com object. if server application not yet running, started , creates com object.

this expected, the registertypeforcomclients supposed equivalent coregisterclassobject of windows com api.

when same 64-bit processes, works when windows forms application started.

when not started, com layer starts windows forms application doesn't return. tried vba client simple c++ console app using com api calls. in both cases works fine, when server app started, doesn't work when com starts on behalf of client.

the funny thing is, when change registry key  from localserver32 localserver, works, com succeeds in starting server cocreateinstance succeeds.

this not option me, because trying achieve have rtdserver running, , rtd function of excel doesn't work when there localserver , no localserver32 registry key.

as mentioned, works fine in 32 bit.

so, reason weird behavior?

i can supply test projects demonstrate problem, if interested.

btw, there caveat testing whole thing related uac. mentioned works when com server application started. not entirely correct. when start app debugger , have vstudio running admin, , use vba officeapp client, doesnt work. because, security of client , server app don't match. in case vba client starts new instance of server app, leads mentioned deadlock under win 64. when start server app doubleclicking in windows explorer, works security settings match. still can debug, attaching process, though.

are compiling cpu?  have tried compile specific platform?  does make difference?

when 64-bit executable activated com, windows account used run application?  is username different username of consuming process?

---

jose r. mcp
code samples

.NET Framework  >  Common Language Runtime Internals and Architecture