STEP 3: I’m using Choose-When-Otherwise syntax for defining different project setting for each Visual Studio target version.Please make sure that those attributes are not defined in other parts of your csproj file. This also allows for avoiding any unnecessary confusion in the future. The artifacts and temporary build files will be in separate directories for each version. STEP 2: In order to avoid any collisions, I’m adding value of VsTargetVersion attribute to OutputPath and IntermediateOutputPath.For some unknown reason, it’s not possible to build VS2019 extension with VS2022, so this approach fixes two issues here. STEP 1: If the VsTargetVersion is not defined (it’s not passed explicitly as a compilation parameter), then I’m assigning a default value based on the current version of VisualStudio that loaded the project.The final working MsBuild script looks as follows: This solution requires a separate compilation for each Visual Studio version (one for VS2019 and older and one for VS2022 and newer) but it allows for keeping a single VSIX project that supports all Visual Studio versions. The new idea was to tweak a little bit the csproj file to load appropriate project configuration based on the value of input property called VsTargetVersion. Besides the design-time experience, after compiling the extension, it turned out that the images from the Resources couldn’t load - for some unknown reason that magical tres comas path notation "pack://application:,/Resources/ stopped working.Īfter a couple of hours of struggling with Shared Project, I decided to change the approach. After moving the extension code to Shared Project all my XAML files seemed to be broken and XAML Visual Designer couldn’t load them correctly to display preview. I tried this approach and lost 4 hours of my life. Each VSIX project has its own vsixmanifest file and references appropriate nuget packages. So what can we do about that? According to the migration guideline on MSDN, the recommended approach is to move all extension code to Shared Project and reference it from two separate VSIX projects - one for VS2019 (and older) and one for VS2022 (and newer). However, those changes are not backward compatible and our extension can’t be installed on an older version of VisualStudio anymore (adjusting InstallationTarget.Version won’t help). Ok, that’s all - it doesn’t seem to be a lot of work as I said before. Runtime build native contentfiles analyzers buildtransitiveĪdditionally, you need to change the dotnet framework version to v4.7.2, if you still have an older version: The next thing that needs to be done is upgrading SDK NuGet package to a version appropriate for VS2022: Ĭompile build native contentfiles analyzers buildtransitive First of all, you need to adjust vsixmanifest by adding the new attribute ProductArchitecture to InstallationTarget configuration: What needs to be changed □︎īasically, two things need to be changed to migrate your extension to VS2022. I wanted to postpone the migration a little bit more but I got an email from one of my paid customers, that the need for constant switching between VS2022 and V2019 to use my MappingGenerator extension is killing his productivity - and I couldn’t allow for that to happen. After quick scanning of migration guideline it turned out that changing InstallationTarget was not enough and more work was required to support VS2022. Recently, the Visual Studio 2022 Preview was published. The migration was straightforward: it required only to extend InstallationTarget range to [15.0,17.0) in vsixmanifest, re-compile, and of course, re-publish the extension to the Visual Studio marketplace. It was initially created for Visual Studio 2017, but a few months later Visual Studio 2019 came out and I needed to support it as I was one of the beneficent. I published my first VisualStudio extension on 26th February 2018.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |