Hi --
I am implementing a language service that will integrate with the IDE and expose code editing, debugging, etc. My core language engine is implemented in non-managed code, and so its whole bootstrapping and initialization mechanism is being executed on an unmanaged thread. One of the features I will be adding is the ability to compile CLR byte code from my own language's expressions and so I would like (if I possibly can) to do most of my Visual Studio integration implementation writing in the language itself and not have to implement significant parts of it in a separate language like c#. This will be an eat-your-own-dog-food kind of exercise, in which I generate with my own compiler the .NET interfaces needed to integrate with Visual Studio.
My question is this: In order to get access to the managed runtime while inside a Visual Studio package extension -- given that I'm starting off from an unmanaged thread -- I was assuming I would have to host the CLR from my own code, the way I would do it if I were outside Visual Studio. This would be a separate instance, of course, from the CLR that Visual Studiois hosting, but would give me a great degree of control over executing any managed code that I create.
First off, is this just a really terrible idea (although I'll know soon enough when I try it out shortly)? And second, would this likely complicate integration with Visual Studio's debugger. I haven't gone up the Debugger/Language Service implementation learning curve enough yet to have a good feel for this and just want to avoid as many blind alleys as I can.
If anyone has any thoughts on this, I would be most appreciative.
Thanks.
Mike