So, whoever is making these .qs sample files needs to use regular Intellisense rules for their comments so Intellisense works within the C# control code. Consider your first example, the TeleportationSample. IntelliSense has no idea what the TeleportClassicMessage type is on this line:
var received = TeleportClassicalMessage.Run(sim, sent).Result;
because in TeleportationSample.qs, the comments describing this operation do not follow the IntelliSense syntax of
/// <param name="args"></param>
and also because the .qs file type is unknown by Visual Studio, so your Visual Studio Extensibility solution needs to be modified to make that happen.
Thanks for the suggestion!
IntelliSense for Q# was added in our 0.3 release, and has been extended in every release since then.
We’ve also made some changes in 0.3 and 0.4 to better integrate Q# into the build system so that the generated C# classes are more visible.
Yes, this behavior is by design. We're looking into ways we can make all of this cleaner.
Mariano Gomez commented
I also noticed that when running a Step Into (F11) on that same line, var received = TeleportClassicalMessage.Run(sim, sent).Result in the classical driver, it did not resolve to the definition of the TeleportClassicalMessage() operation. Is that by design or is this related to the intellisense issue? My assumption is, this is due to the compartmentalized roles of the driver and the quantum machine, but it's just an assumption. Can you confirm whether this is by design?
Thanks for your feedback!
We are evaluating adding full support for Intellisense for Q# and for the generated C# files for a future release. We'll announce news in this area when appropriate.