I’ve been having some trouble converting an old VSIX project to Visual Studio 2022.

Some things to note:

• The project builds in VS2019 The project targets .Net Framework 4.8
• The project should be able to build for ‘any CPU’ but x64 only would be acceptable.
• Upgrading the project with the upgrade tool results in a Microsoft.NET.Sdk project which doesn’t produce a VSIX file on successful build. (No skips) Porting the old project without upgrading it eventually results in a “vsct.exe exits with code 1” error on build. I find nothing suspicious in the build log. (Google says this has something to do with mixing 32bit and 64bit assemblies but I have tried having all my projects target 64bit explicitly, same error)

Has anybody else gone through this struggle? Is there any advice you have for me?

A few more things that have confounded me:

• “Extension 'ProductName.VSIX' could not be found. Please make sure the extension has been installed.”

This has shown up intermittently. But then the extension installs manually, just fine.

• “There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "LibraryName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=asdf, processorArchitecture=AMD64", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.”

This one confuses me because I don’t see MSIL as an option in my dropdown, just “Any CPU, Mixed Platforms, x86, and x64. Is MSIL for Any CPU?

I’ve followed this and it didn’t help.

Thanks all for your time.

I’ve been having some trouble converting an old VSIX project to Visual Studio 2022.

Some things to note:

• The project builds in VS2019 The project targets .Net Framework 4.8
• The project should be able to build for ‘any CPU’ but x64 only would be acceptable.
• Upgrading the project with the upgrade tool results in a Microsoft.NET.Sdk project which doesn’t produce a VSIX file on successful build. (No skips) Porting the old project without upgrading it eventually results in a “vsct.exe exits with code 1” error on build. I find nothing suspicious in the build log. (Google says this has something to do with mixing 32bit and 64bit assemblies but I have tried having all my projects target 64bit explicitly, same error)

Has anybody else gone through this struggle? Is there any advice you have for me?

A few more things that have confounded me:

• “Extension 'ProductName.VSIX' could not be found. Please make sure the extension has been installed.”

This has shown up intermittently. But then the extension installs manually, just fine.

• “There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "LibraryName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=asdf, processorArchitecture=AMD64", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.”

This one confuses me because I don’t see MSIL as an option in my dropdown, just “Any CPU, Mixed Platforms, x86, and x64. Is MSIL for Any CPU?

I’ve followed this and it didn’t help.

Thanks all for your time.

• c#
• visual-studio
• visual-studio-extensions
• vsix
• vsixmanifest

• 1 "MSIL" would translate to Any CPU, yes. So that warning is saying "you have something that is Any CPU, but it's depending on something that says it's amd64 only, so that won't actually be any CPU". – Jason Malinowski Commented Mar 13 at 17:48
• If you use ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch , will it suppress this warning? – Dou Xu-MSFT Commented Mar 18 at 8:49
• I have managed to work through my issues. It had to do with upgrading old assemblies and focusing on altering the .dll files from 32 bit to 64 bit in the cases where upgrading to NuGet was not an option. – CatAtGat Commented Apr 8 at 12:34

2 Answers 2

From looking at this document MSB3270,

the message says that you're trying to use a dependency that is of an architecture that doesn't match the target architecture your project is configured for.

Microsoft is just trying to warn you when you state that your project is compatible with "Any CPU" but you have a reference LibraryName that is AMD64. Because you have an AMD64 reference , technically your project is therefore not "Any CPU" compatible. Please try to change your project from "Any CPU" to "AMD64".

Besides, you can also use ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch to suppresses this warning.

<PropertyGroup>
   <!-- other property settings -->
   <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>

Docs Referred:

A similar ticket

Configure projects to target platforms

Has anybody else gone through this struggle?

Yes, I have, and it was a struggle, indeed. As a result, I had to split the VSIX package into an x86 build for pre-VS2022 and an x64 build for VS2022, targeting different frameworks and referencing different packages. Feel free to explore the result here.

Is there any advice you have for me?

• If you still want to support both VS2019 and VS2022, you must have two separate packages. You can create a special 'Shared Project' for the common code (.shproj), see the final result of mine.
• In the VS2022 package you only need to reference the Microsoft.VisualStudio.SDK package (as opposed to VSSDK.Shell..., Microsoft.VisualStudio.Shell.Interop.14.0.DesignTime, etc. in VS2019).
• AnyCPU is not going to work. The VS2019 package must target x86 whereas the VS2022 packages must be an x64 one (though ARM is also supported nowadays)
• You might want to introduce a custom build constant and use #ifs in the common code. My example may be too extreme here as I support even VS2013, but your code may be simpler than that (in my case even some of the newer attributes are reimplemented locally to maintain compatibility).
• The documentation you linked mentions that the common resources can be moved to the shared project. In my experiences this doesn't work for every resource. For example, if you use custom icons for VS commands, they cannot be just linked, so they must be duplicated in both packages.
• If the shared project would just contain a lot of #ifs, for VS2022 you might want to consider to use the new extensibility API instead. Much simpler than the old API, though may not support everything you need. This page may help you to decide.