tinaschrepfer on tinali
Remove use of "any" content typ… (compare)
tinaschrepfer on tinali
Merge pull request #169 from Mi… Add sample support for "any" co… (compare)
tinaschrepfer on master
Update VSSDK package and remove… Merge pull request #169 from Mi… (compare)
@aguinet I have to deal with this situation, in terms of keeping compatibility, it's very hard to maintain honestly. The best advice I can offer you is if you can build in VS2017 then it will build on VS2019 and be able to run on VS2017. The most common issue if developing new features and finding out this API does not exist in VS2017.
Thanks for your answer! We ended up by installing both VS2017/2019 build tools + extension SDK in our builder..
IPropertyPage. I use it for my Project Properties dialog. If my
UserControlis based on
Winformsit works fine, however it has DPI issues. A
UserControldoes not display itself. I have tried using
UIElementDialogPage, that also does not help. Any suggestions how should I solve this issue?
VSPackageinitialization, and I am unable to find any APIs/samples to do so.
Just to clarify are you trying to add a tab to the project properties tab? Or to the properties window?
Maybe VS2019 Add Project Property page could help point you in the right direction, if you haven't seen it already? Or Modifying project properties of custom project system in VisualStudio ? They may not be exactly what you need, but something may spark an idea.
ElementHostcontrol in WinForms. I already had created the whole property page with WinForms and it worked fine. However, the issue which caused me to rethink the UI was high DPI screens e.g. a 1080p screen with 125% Scaling on Windows 10. Traditional WinForms controls do not scale well and the controls look for overlapped. Thankfully, I was able to resolve it by creating a WPF based user control and use it via the
ElementHostin WinForms. It scales correctly after that, even on a scaling of 300% on a 2160p screen.
Another info for anyone providing extension for VS2017; once you have
AllUsers="true" in your vsixmanifest, vsixinstaller gets to the point where it wants to install (not repair, not update)
Microsoft.NET.Core.Sdk.2.1 which fails (because the user has usually a slightly different version of this package already installed - seems more like a version mismatch in Visual Studio 2017 catalog itself). Your extension gets installed, but VSIXInstaller reports a failure.
This can be replicated with @madskristensen 's Extensibility Tools (https://marketplace.visualstudio.com/items?itemName=MadsKristensen.ExtensibilityTools) .
Once the user runs Visual Studio Installer and repairs their installation, things will work well (but just once).
.csfiles in solution explorer based on a button provided by my plugin.
The comments suggest we should use a different piece of code to get IVsOperationProgressStatusService based on VS version: V16.1 or "Post Visual Studio 2019 Update 2".
Does this mean that one has to create two VSIX packages? Or is there a way at runtime to detect the VS version?
For some VS versions, Workspace.CurrentSolution will return an incomplete code model. (Partial Load Mode (PLM))
This is a new feature to enable faster loading of solutions.
In such versions, if we want to wait for the solution to "really load", we have to use IVsOperationProgressStatusService.
The API to get a IVsOperationProgressStatusService differs between VS 16.1 and "Post Visual Studio 2019 Update 2".
If I am to create a VS extension that targets VS 2017 and VS 2019 (multiple versions), how can I have a single VSIX for all versions?
If VS version > some version, I need to use IVsOperationProgressStatusService. And to get IVsOperationProgressStatusService I need to use different codes based on the version.
Or should I have three VSIX projects:
I'm working on an extension that provides a custom debug engine for Visual Studio -- https://github.com/googlestadia/vsi-lldb. The debug engine is similar to MIEngine (https://github.com/microsoft/MIEngine). The underlying debugger is LLDB and the extension provides all the necessary integrations (attach, stepping, natvis and expression evaluation, etc).
My question is about implementing custom code-completion in the Immediate Window.
The expressions in the Immediate Window are handled by
IDebugExpressionContext2  and
IDebugExpression2. This works fine, when the user enters the expressions and hits Enter
IDebugExpressionContext2::ParseText is invoked,
IDebugExpression2 object is created and the expression is eventually evaluated .
Now I want to implement basic code-completion for the expressions in the Immediate Window. For example, to show a list of members when the user types
foo-> and such. I can easily do this using my expression evaluation engine (https://github.com/google/lldb-eval), but I can't figure out how to implement it in Visual Studio.
I have found an interface
IVsImmediateStatementCompletion2 . Looking at the name, this seems like exactly what I want :) However I'm not sure how what is the proper way to impement this interface. The documentation says this interface should be implemented on the same object that implements
IVsLanguageInfo -- this matches what I see in Roslyn .
My extension currently doesn't provide a language service implementation, only the debug engine. I've tried adding a dummy implementation like
class MyLanguageService : IVsLanguageInfo, IVsImmediateStatementCompletion2 and registering it via
[ProvideService]. After I registered it for ".cpp" files, I can see that methods for
IVsLanguageInfo are being called (namely
IVsImmediateStatementCompletion2 is never triggered.
So here's the big question, how do I implement a custom completion for the Immediate Window in my DebugEngine? :) Thanks!