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)
Clean Solutionoperation with deleting bin & obj folders.
InitializeAsyncwhere I subscribe to
@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: