www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Where is Visual-D C# code?

reply Ramon <midiway midi.rs> writes:
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
Oct 30 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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



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 

today). Please note that this was before the release of VS2010, so VS 


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.
Oct 31 2015
parent reply default0 <Kevin.Labschek gmx.de> writes:
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



 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 

 might be more relaxed about this today). Please note that this 
 was before the release of VS2010, so VS itself was not based on 


 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!
Oct 31 2015
next sibling parent reply Ramon <midiway midi.rs> writes:
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 

already cryptic enough.
Oct 31 2015
parent Rainer Schuetze <r.sagitario gmx.de> writes:
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

 ultra-productive, VS extension API is already cryptic enough.



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 


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.
Oct 31 2015
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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 



 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 ;-)
Oct 31 2015
parent reply Ramon <midiway midi.rs> writes:
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 



 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?
Oct 31 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Oct 31 2015
parent reply Ramon <midiway midi.rs> writes:
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.




Does Visual-D implements a complete Debug Engine?
Nov 01 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.




 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.
Nov 01 2015
parent reply Ramon <midiway midi.rs> writes:
Rainer, do you have an e-mail where I can message you about
Nov 04 2015
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 05.11.2015 04:01, Ramon wrote:

 Rainer, do you have an e-mail where I can message you about working in a



It's the email address used to post here: r _dot_ sagitario _at_ gmx 
_dot_ de.
Nov 05 2015