1

I am writing a VSTA 20151 enabled app.

In it, I need to load an assembly, access a well-known method (a constructor, not that it matters), invoke it, and pass it a COM object (wrapped up so it is a .net object naturally).

This works fine. Now, in order to enable debugging, I need the process that the assembly is loaded from be different than the one that interacts with the VSTA subsystem. The application interacts with the VSTA subsystem; which means I need the assembly to be loaded in a distinct process.

Is there a simple way to load a .net assembly in a separate process, passing it a com object (or a .net object wrapping the com object) to a well-known entry point?

The complex method would involve creating a custom .exe loader that loads the assembly, use IPC to get ahold of the COM interface, wrap it up and pass it to the assembly. Then use IPC to return any error messages. Not certain what kind of IPC I should use. But there are a lot of moving parts here (the two IPC systems, the loader), and I'd hope there would be an easy way to do it without them.

I looked at System.Diagnostic.Process.Start, but it doesn't seem able to "open an assembly as a process and pass it this .net object" among the options.

Apartments (and similar) probably won't work, as the separate process is needed so that a debugger can attach to the VSTA "script" process and pause/advance it without locking up the VSTA "hosting" process (which in the docs says it can lead to deadlocks).

The application is mixed managed/unmanaged, if that matters. Most of the managed component is C#, most of the unmanaged is C++, and most of the interface is C++/cli.

1 VSTA 2015 is a Microsoft solution to allow on-the-fly editing of a "script-like" environment of a .net language, where the Visual Studio IDE workflow is integrated with the application workflow. Note that this is different than pre-VSTA 2012 in fundamental ways: pre-VSTA 2012 information or answers are unlikely to be useful here.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
  • 1
    Would creating an out-of-proc (exe) COM server (wrapping your managed code that loads the assembly) work for you? I'm not familiar with VSTA 2015 but based on what you described, this would be my first attempt. – xxbbcc Nov 10 '15 at 15:42
  • @xxbbcc Maybe? Basically, VSTA provides me with the assembly binary (which it auto-recompiles when the source code changes), and I'm responsible for running it in a context where it "works". In my case, it "works" means I load the assembly and construct it with the app object model. Is there an easy way to create an out-of-process COM server, or do I have to hand roll it in practice? Is there some kind of .net magic I can use to say "hey, this is an out-of-process COM server", or am I damned to COM interface writing and .reg file guid purgatory? – Yakk - Adam Nevraumont Nov 10 '15 at 16:00
  • I haven't done an out-of-proc in C# so I can only recommend a few links to you: https://support.microsoft.com/en-us/kb/977996 and http://stackoverflow.com/questions/446417/create-out-of-process-com-in-c-net – xxbbcc Nov 10 '15 at 16:33
  • Doing an .exe COM server in C++ is not particularly complicated, though (I assume it's about the same using C++/CLI) so in the worst case you can fall back to that approach. – xxbbcc Nov 10 '15 at 16:34

0 Answers0