I had created a visual studio extension (VSIX) which was compatible with vs2010 and vs2012. It had Nuget Package Manager as a dependency. Now I want to make it compatible with vs2013. I added the vs2013 to the supported products. But, the istallation would always fail. Apparently, Nuget team have changed the Identfier for vsix extension for vs2013. I cannot change the identifier to new one as it will affect vs2010/12.
<References>
<Reference Id="NuPackToolsVsix.Microsoft.67e54e40-0ae3-42c5-a949-fddf5739e7a5">
<Name>NuGet Package Manager</Name>
<MoreInfoUrl>http://docs.nuget.org/</MoreInfoUrl>
</Reference>
</References>
Is there a way to add depndencies to vsix based on visual studio version. So that I can add one more reference to nuget for vs2013. OR is there any workaround to this?
The new identifier for vs2013 nuget extension is NuGet.67e54e40-0ae3-42c5-a949-fddf5739e6a5
You can do either of the following:
Remove the reference to the NuGet extension. This will result in a risk of package load errors or other errors if your users do not have NuGet installed, or if they have an outdated version of NuGet that your extension does not support.
Ship separate VSIX packages of your extension for Visual Studio 2010-2012 and Visual Studio 2013.
The latter is likely the best approach. You can create both extensions from the same codebase by following the approach used in the Cloud Explorer extension (note there will be subtle differences because this extension doesn't support Visual Studio 2010, but yours does).
Create a separate project file for the VS2013 extension in the same folder as the extension that targets 2010-2012. I highly recommend you use a visual diff tool to compare Rackspace.VisualStudio.CloudExplorer.11.csproj and Rackspace.VisualStudio.CloudExplorer.12.csproj to show the subtle differences that allow these to live side-by-side.
Create subfolders Properties\vs2010 and Properties\vs2013 to hold the two separate versions of your source.extension.vsixmanifest file. Use the correct NuGet reference for each of these files.
If your project is open source on GitHub, I could help apply the changes and send a pull request.
Related
I am trying to update my published Visual Studio extension to the 2022 version, this one
The problem is: I keep getting (when attempting to update on the marketplace).
The extension is incompatible with the targeted version of Visual
Studio. More info at https://aka.ms/ExtensionSdkErrors
Locally, the extension installs and runs fine (on 2022 as well), this version that can be downloaded from the "GitHub releases", and there are no blocking messages when building it as well from the analyzers.
The link in the error message says that the extension should be using the latest version of the VisualStudio.Sdk (version 17). The thing is, it does!
Any suggestion what I could look at to make the submission succeed?
Extension has two bundled child project templates inside, and one template wizard (in addition to the SDK it has a reference to Microsoft.VisualStudio.TeamplateInterface v.17), because SDK does not seem to have this package bundled.
Full source code:
https://github.com/nbelyh/VisioPanelAddinVSTO/tree/vs2022
Many interop assemblies were embeddable prior to Visual Studio 2022. Beginning in Visual Studio 2022, embedding is no longer required or supported.
try removing the references from the project file https://github.com/nbelyh/VisioPanelAddinVSTO/blob/master/Wizard/PanelAddinWizard.csproj
envdte
EnvDTE80
Microsoft.VisualStudio.OLE.Interop
Microsoft.VisualStudio.Shell.Interop
and use the Microsoft.VisualStudio.Interop
You can refer following list:
https://learn.microsoft.com/en-us/visualstudio/extensibility/migration/migrated-assemblies?view=vs-2022
For more details:
https://learn.microsoft.com/en-us/visualstudio/extensibility/migration/update-visual-studio-extension?view=vs-2022
I am struggling with creating NuGet packages. I am using Visual Studio 2017 Community edition.
I have seen a couple of videos that show a "Pack" option on the menu when right-clicking the project in Solution Explorer. However, I do not have that option. Is this one of the features in the other (non-Community) versions of Visual Studio? I believe I have also seen a "create NuGet package on build" option mentioned somewhere. I cannot find that either.
I have tried various ways of using nuget, dotnet, and msbuild from the command line(s), but haven't had much success. Very frustrating.
Any help is appreciated.
If you really want to use Visual Studio, I would recommend installing an extension that helps you with that problem. For example, this one. The options people have in videos depend on the extensions they have installed. For you, it is the same.
Alternatively, just use the command-line tooling for this as explained here or for .NET Core here or here.
dotnet/msbuild pack is only available for SDK-style projects, but I believe works for all versions of Visual Studio, as well as on the command line. .NET Core introduced these SDK-style projects, which can be identified by <Project Sdk="Microsoft.NET.Sdk">. If your project (.csproj if it's a C# project) doesn't have the Sdk property or import Microsoft.NET.Sdk in either of the two other ways, then it's not an SDK style project and doesn't support packing in this way. Another obvious difference between the two styles of projects is that SDK projects are only a few lines long from the new project template and don't list files in the project, whereas old style projects are typically a full screen long, even from a new project template with only a single class file, and it does list individual files in the project. If you want to continue with this project type, you'll need to use nuget.exe pack and you'll probably want to create a .nuspec file to define some of the package metadata.
However, using SDK style projects is the future, it just takes time for all of Microsoft's existing project types to migrate. It's much simpler to use, so personally I would avoid old style projects unless you're using a project type (like ASP.NET, not ASP.NET Core) that doesn't support it.
All of this is confusing for anyone new to the .NET ecosystem. My recommendation is 1. when you install Visual Studio, when making your workload selections, make sure in the component list that .NET Core is selected, whatever the newest version of .NET Core that is available at the time of installation. When creating a new project in Visual Studio, always select the .NET Core version, or .NET Standard version of any new project template, even if you want to target the (Windows) .NET Framework, in which case you edit the .csproj and change <TargetFramework>netstandard2.0</TargetFramework> to <TargetFramework>net45</TargetFramework>, although I would recommend multi-targeting possible by adding a s to the element name and using a semi-colon separated list: <TargetFrameworks>net45;netstandard2.0</TargetFrameworks>. So, avoid the "Class Library (.NET Framework)" template, instead use "Class Library (.NET Standard)" and then change the target if you have to.
#zivkan led me down the right path. Changing my project types to .Net Core from .Net Framework made all the options I mentioned in my original post available. No extensions were needed.
My .Net Core class library project now has the Pack and Publish options available on the project's context menu. In addition, there is a another tab (Package) on the project properties page. On that page there is a "Generate NuGet package on build" option along with version, name, tags and other properties.
I have done much .Net framework development, but have been ignoring .Net Core and the newer options. I guess I need to dig in and learn about them.
I am having a rough time figuring out how to setup cross-targeting inside a Visual Studio 2017 project and I have not been able to find any examples.
I started out with a .NET Standard 1.5 project and to keep it simple I am just trying to add .NET Standard 1.6. If I understand the documentation correctly, I should now be able to do all of this inside the csproj file without having to mess with a project.json or nuspec file.
I've tried all of these values but none seem to work:
<TargetFrameworks>netstandard15;netstandard16</TargetFrameworks>
<TargetFrameworks>netstandard1.5;netstandard1.6</TargetFrameworks>
<TargetFrameworks>.NETStandard,Version=v1.5;.NETStandard,Version=v1.6</TargetFrameworks>
This is the only source of documentation I can find on the feature and it doesn't contain a full example:
https://docs.nuget.org/ndocs/schema/msbuild-targets
https://docs.nuget.org/ndocs/create-packages/supporting-multiple-target-frameworks
I've gotten this to work on latest Visual Studio 2017. As described in this post https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/ it is the correct way to do it. My csproj file looks like this:
<PropertyGroup>
<TargetFrameworks>netstandard1.6;net452</TargetFrameworks>
</PropertyGroup>
Visual Studio 2017 RC release notes also has this listed as a feature (under .NET Core and Docker):
Cross-target multiple target frameworks in one project.
My mistake at the start was that when I first created the project the property was called TargetFramework, I tried to add multiple targets and VS did not like that at all. It just crashes then... So make sure to rename it to TargetFrameworks and it should work.
A few extensions that I'm using are broken under VS2012 because at some point they were updated to work with VS2013, by changing the version of referenced libraries. At runtime an error like this can be produced:
Could not load file or assembly 'Microsoft.VisualStudio.Shell.12.0, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
I see various extensions referencing multiple versions of the same library:
<Reference Include="Microsoft.VisualStudio.Shell.Interop" />
<Reference Include="Microsoft.VisualStudio.Shell.Interop.8.0, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<Reference Include="Microsoft.VisualStudio.Shell.Interop.9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Others release an extension per VS version.
Another option, according to this article, is to dynamically load the correct version.
I'd like to help fix these extensions, but what's the proper way to tackle this issue?
So the Visual Studio reference assemblies break down into a few different categories, which you should handle differently depending upon the category:
Interop assemblies: these are the ones like the Interop.* assemblies you listed in your question. Each interop assembly isn't a newer version of the "same" thing, but rather an assembly that contains all the COM interfaces that were added in that version of Visual Studio. Referencing old versions is fine, just don't reference a newer one than the lowest version of Visual Studio you want to target
Editor assemblies, Roslyn: Anything related to the core text editor (assemblies are Microsoft.VisualStudio.Text.Data, Microsoft.VisualStudio.Text.UI, Microsoft.VisualStudio.Text.UI.Wpf, and Microsoft.VisualStudio.Editor) and Roslyn Visual Studio includes assembly redirects that redirect whatever version you're referencing to the version of VS you're actually running in. Once again, target the lowest version that you intend to support.
Microsoft.VisualStudio.Shell.[version]: this one confuses people a lot. How this particular assembly works is for each version of Visual Studio that ships, a new assembly name (with the version in the assembly) is made. Then, in future versions of the Visual Studio, we ship a newer version of the assembly that you target. So again, make sure you're targeting Microsoft.VisualStudio.Shell.[version] with the lowest version you intend to support.
The tricky problem here is the VSSDK project upgrader likes to upgrade your projects to newer versions. Get used to editing MSBuild files by hand to ensure it doesn't do this, or downgrade what it already did. For the final VSIX you ship to users it's often best to either build with an older version of VS to ensure it's not picking up newer stuff by accident. If you want to only use a newer version, then you'll have to find the VS binaries from the older version you wish to use and check those into your source control system to ensure the older versions are still being picked up. Test your VSIX if you go this route as it's easy to make a mistake and reference something newer by accident.
I wrote an article discussing the various assembly versioning policies used by Visual Studio assemblies.
http://tunnelvisionlabs.github.io/vsbase/docs-master/html/edbfd3ce-43f4-4f3f-a90c-bc22bda19fae.htm
In addition, the VSSDK.* NuGet packages use dependency declarations to help you identify the version(s) of Visual Studio each extension can be used with.
The particular version of Microsoft.VisualStudio.Shell you referenced is a Versioned Assembly (per the previous article) and included in the VSSDK.Shell.12 package, with the following description:
This package provides the Visual Studio "Shell" reference assembly used by Visual Studio 2013 and newer.
To easily target both Visual Studio 2012 and Visual Studio 2013, use NuGet to manage your VS SDK dependencies, and ensure the following conditions hold:
Make sure your assembly does not have a dependency on the VSSDK.IDE.12 NuGet package. This dependency means one or more assemblies referenced by your project only work with Visual Studio 2013 and newer.
Make sure your assembly does not have a dependency on VSSDK.IDE.10Only, VSSDK.IDE.11Only, or VSSDK.IDE.12Only. These indicate that your package references one or more assemblies that only work with a particular version of Visual Studio.
Ideally you would only want to install VSSDK NuGet packages which include both the vs2012 and vs2013 tags.
I am trying to convert a SharePoint 2010 solution (custom web parts, content types, lists, event receivers, etc.) developed in Visual Studio 2010 to SharePoint 2013 and Visual Studio 2012. When I open the project in VS 2012, it converts a couple of the project files but won't compile because of reference issues.
I copied the DLLs (mostly Microsoft.SharePoint..., although I needed to copy the Microsoft.Office.SecureStoreService.dll too) that were causing issues from my 2010 server to the 2013 server and fixed the references. However, the Microsoft.Office.SecureStoreService.dll still gives me compiler errors claiming "Error 203 The type or namespace name 'Office' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)" when visual studio has no problem with the namespace and finds the SecureStoreProvider class inside it just fine.
I've also tried to change the target framework from 3.5 to 4 and only see "Install other frameworks..." in the target framework dropdown.
I'm sure that others have dealt with this, but have been unsuccessful in framing the right google search query. I'm relatively new to SharePoint in general and any help would be appreciated.
thanks,
Mike
I was able to get my solution upgraded from a 2010 project to 2013 using the following. Note that this will update your solution to use the new 2013 API. It is possible to update just the project file but still run in 2010 mode.
First edit your .csproj file (for c#).
Modify the target framework to this:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
Add this a node for the office version, I put mine directly below the TargetFrameworkVersion tag
<TargetOfficeVersion>15.0</TargetOfficeVersion>
Update references
Reload the project and update your referenced assemblies. If you haven't specified a specific version they should already be referencing the v15 (SharePoint 2013) assemblies.
Do a find replace for 14.0.0.0 to 15.0.0.0. This updates any references on your pages, layouts, and master pages to the v15 assemblies.
Change calls
Change any calls to SPUtility.GetGenericSetupPath() to SPUtility.GetVersionedGenericSetupPath()
Check each file to do a check for any hive references. You'll need to add a /15/ to these. EG: _layouts/ to _layouts/15/
Open the package "folder" in visual studio then update the properties for that package to use version 15.
Clean up
Finally do a compile clean up any missed items. Deploy your solution and make sure to test thoroughly.