I use Visual-D for Visual Studio daily for writing D programs. Also I am very experienced in writing Visual Studio extensions, I wrote this commercial one: http://misoftware.rs/OmniCode.

Now, looking at Visual-D source code, 85% is D code. Well, at first it seems OK to write a D extension for D in D, but I wonder, how do you manage to use all .NET APIs from D?

Because for implementing every aspect of a language extension in Visual Studio (Intellisense, outlining, QuickInfo, signature help, snippets), in my experience, you really need to work with the .NET assemblys of the Visual Studio Extensibility SDK. I guess you are doing it in a old COM way, which I think is still supported by VS. But I think that is far from being productive. Also I doubt you can support every new aspect of VS editor experience, because since VS 2010 I think, the editor is based on WPF, so it is .NET in all its glory.

I am just worried if Visual-D is taking the right approach for implementing stuff. I could definitely help in the C# area.

On 31.10.2015 00:19, Ramon wrote:
> I use Visual-D for Visual Studio daily for writing D programs. Also I am
> very experienced in writing Visual Studio extensions, I wrote this
> commercial one: http://misoftware.rs/OmniCode.
>
> Now, looking at Visual-D source code, 85% is D code. Well, at first it
> seems OK to write a D extension for D in D, but I wonder, how do you
> manage to use all .NET APIs from D?
>
> Because for implementing every aspect of a language extension in Visual
> Studio (Intellisense, outlining, QuickInfo, signature help, snippets),
> in my experience, you really need to work with the .NET assemblys of the
> Visual Studio Extensibility SDK. I guess you are doing it in a old COM
> way, which I think is still supported by VS. But I think that is far
> from being productive. Also I doubt you can support every new aspect of
> VS editor experience, because since VS 2010 I think, the editor is based
> on WPF, so it is .NET in all its glory.
>
> I am just worried if Visual-D is taking the right approach for
> implementing stuff. I could definitely help in the C# area.

You are right that writing Visual D in D has not been the easiest way to write an extension for VS. The first attempt was actually a derivation of a C# extension, but I hated it (I might be more relaxed about this today). Please note that this was before the release of VS2010, so VS itself was not based on C# as much as today.

My reasoning was this: why should I spend my spare time writing code in a language I don't like? Writing it in D seemed natural instead, and actually doing this meant contributing to the dmd compiler/library/toolchain resulting in automatic conversion of Windows and VS SDK to D, DLL support for D, precise GC and numerous bug fixes.

Most functionality can be accessed through COM, but WPF seems to be very different. That's why there is vdextensions.csproj to integrate some stuff that I didn't manage to access directly.

On Saturday, 31 October 2015 at 08:31:54 UTC, Rainer Schuetze wrote:
>
>
> On 31.10.2015 00:19, Ramon wrote:
>> I use Visual-D for Visual Studio daily for writing D programs. Also I am
>> very experienced in writing Visual Studio extensions, I wrote this
>> commercial one: http://misoftware.rs/OmniCode.
>>
>> Now, looking at Visual-D source code, 85% is D code. Well, at first it
>> seems OK to write a D extension for D in D, but I wonder, how do you
>> manage to use all .NET APIs from D?
>>
>> Because for implementing every aspect of a language extension in Visual
>> Studio (Intellisense, outlining, QuickInfo, signature help, snippets),
>> in my experience, you really need to work with the .NET assemblys of the
>> Visual Studio Extensibility SDK. I guess you are doing it in a old COM
>> way, which I think is still supported by VS. But I think that is far
>> from being productive. Also I doubt you can support every new aspect of
>> VS editor experience, because since VS 2010 I think, the editor is based
>> on WPF, so it is .NET in all its glory.
>>
>> I am just worried if Visual-D is taking the right approach for
>> implementing stuff. I could definitely help in the C# area.
>
> You are right that writing Visual D in D has not been the easiest way to write an extension for VS. The first attempt was actually a derivation of a C# extension, but I hated it (I might be more relaxed about this today). Please note that this was before the release of VS2010, so VS itself was not based on C# as much as today.
>
> My reasoning was this: why should I spend my spare time writing code in a language I don't like? Writing it in D seemed natural instead, and actually doing this meant contributing to the dmd compiler/library/toolchain resulting in automatic conversion of Windows and VS SDK to D, DLL support for D, precise GC and numerous bug fixes.
>
> Most functionality can be accessed through COM, but WPF seems to be very different. That's why there is vdextensions.csproj to integrate some stuff that I didn't manage to access directly.

I seem to remember that it is possible to call into managed code from C++ (something like C++/CLI). Would it theoretically be possible to have a wrapper that allows direct access to the managed .NET API from D? A project like this could also help improve general interoperability between D and the .NET platform. Not sure on the specifics about these things, though, and just thinking about it this seems like a stupid amount of work to get right.

Maybe I'm actually gonna give this a try, since I have way too many things to do anyways it seems to be very reasonable to start yet another (possibly gigantic) thing!

I really would not recommend to use D at all for writing VS extensions. The thing is, are you be able to debug your D extension in Visual Studio experimental instance? Also Visual Studio is only for Windows, no need to multiplataform support, so just write it in C# and be ultra-productive, VS extension API is already cryptic enough.

On 31.10.2015 16:47, Ramon wrote:
> I really would not recommend to use D at all for writing VS extensions.
> The thing is, are you be able to debug your D extension in Visual Studio
> experimental instance? Also Visual Studio is only for Windows, no need
> to multiplataform support, so just write it in C# and be
> ultra-productive, VS extension API is already cryptic enough.

I guess I would use C# now if starting all over, because you don't find any good support or examples in other languages anymore. But as I said, it's a way to actually work with D for me, and it doesn't seem productive to rewrite it in C# (I'm not an expert in that language anyway).

Debugging the extension works both with the native and the mixed mode debugger, but the debug information emitted by dmd is sub-standard. I've made a number of pull requests years ago, but they have been mostly ignored.

On 31.10.2015 14:49, default0 wrote:
> I seem to remember that it is possible to call into managed code from
> C++ (something like C++/CLI). Would it theoretically be possible to have
> a wrapper that allows direct access to the managed .NET API from D? A
> project like this could also help improve general interoperability
> between D and the .NET platform. Not sure on the specifics about these
> things, though, and just thinking about it this seems like a stupid
> amount of work to get right.

I guess it should be possible. When debugging Visual D, you see the transition between native and CLI on the callstack several times. AFAICT you usually call into a COM interface that is exposed by the .NET object. Even though these exist for Wpf objects, it's sometimes hard to get hold of these. At least, I failed when trying to implement the coverage margins and had to add the vdextensions C# project.

>
> Maybe I'm actually gonna give this a try, since I have way too many
> things to do anyways it seems to be very reasonable to start yet another
> (possibly gigantic) thing!

Good luck ;-)

On Saturday, 31 October 2015 at 16:15:22 UTC, Rainer Schuetze wrote:
>
>
> On 31.10.2015 14:49, default0 wrote:
>> I seem to remember that it is possible to call into managed code from
>> C++ (something like C++/CLI). Would it theoretically be possible to have
>> a wrapper that allows direct access to the managed .NET API from D? A
>> project like this could also help improve general interoperability
>> between D and the .NET platform. Not sure on the specifics about these
>> things, though, and just thinking about it this seems like a stupid
>> amount of work to get right.
>
> I guess it should be possible. When debugging Visual D, you see the transition between native and CLI on the callstack several times. AFAICT you usually call into a COM interface that is exposed by the .NET object. Even though these exist for Wpf objects, it's sometimes hard to get hold of these. At least, I failed when trying to implement the coverage margins and had to add the vdextensions C# project.
>
>>
>> Maybe I'm actually gonna give this a try, since I have way too many
>> things to do anyways it seems to be very reasonable to start yet another
>> (possibly gigantic) thing!
>
> Good luck ;-)

Are you using https://github.com/Hackerpilot tools as the backend for Visual-D?

On 31.10.2015 19:07, Ramon wrote:
>
> Are you using https://github.com/Hackerpilot tools as the backend for
> Visual-D?

No. Visual D had it's own semantic engine, but switched to D_Parser by Alex Bothe some years ago (https://github.com/aBothe/D_Parser). This is the engine that is used by Mono-D and is still the best around AFAICT.

BTW: D_Parser is all C#, but it runs in a different process.

On Saturday, 31 October 2015 at 19:59:19 UTC, Rainer Schuetze wrote:
>
>
> On 31.10.2015 19:07, Ramon wrote:
>>
>> Are you using https://github.com/Hackerpilot tools as the backend for
>> Visual-D?
>
> No. Visual D had it's own semantic engine, but switched to D_Parser by Alex Bothe some years ago (https://github.com/aBothe/D_Parser). This is the engine that is used by Mono-D and is still the best around AFAICT.
>
> BTW: D_Parser is all C#, but it runs in a different process.

Does Visual-D implements a complete Debug Engine?

On 01.11.2015 17:34, Ramon wrote:
> On Saturday, 31 October 2015 at 19:59:19 UTC, Rainer Schuetze wrote:
>>
>>
>> On 31.10.2015 19:07, Ramon wrote:
>>>
>>> Are you using https://github.com/Hackerpilot tools as the backend for
>>> Visual-D?
>>
>> No. Visual D had it's own semantic engine, but switched to D_Parser by
>> Alex Bothe some years ago (https://github.com/aBothe/D_Parser). This
>> is the engine that is used by Mono-D and is still the best around AFAICT.
>>
>> BTW: D_Parser is all C#, but it runs in a different process.
>
> Does Visual-D implements a complete Debug Engine?

It incorporates Mago, a debug engine created for D: https://github.com/rainers/mago.
D also works with C++ engines, but expect some quirks, e.g. you'll have to fall back to C++ expressions for watches.