Publish stable versions of the Microsoft.VisualStudio.ProjectSystem.Managed and Microsoft.VisualStudio.ProjectSystem.Managed.VS projects

[nkolev92]

NuGet needs to consume the above 2 packages to populate the solution explorer, but only prerelease versions of those packages are available at https://dev.azure.com/azure-public/vside/_packaging?_a=feed&feed=vs-impl.

Normally this would be a big deal, but these packages reference analyzers and other preview packages which introduces a lot of conflicts in our graph and effectively makes us elevate many packages to top level.

cc @dmonroym

[jjmew]

@nkolev92 Can you provide us with some specific examples of packages that are having the problem?

[nkolev92]

The packages Microsoft.VisualStudio.ProjectSystem.Managed and Microsoft.VisualStudio.ProjectSystem.Managed.VS are the ones we depend on.

Those packages depend on prerelease versions of analyzers.

"Microsoft.CodeAnalysis" which itself depends on preview versions of System.* packages.
"Microsoft.VisualStudio.LanguageServices" which itself depends on exact versions of analyzers causing a conflict in restore.

Basically the packages in here: https://github.com/dotnet/project-system/blob/main/build/import/Packages.targets#L101-L111
We try not to introduce indeterminism in our graph resolution, so resolving this is any way would require us to reference many dependencies that we don't understand/introduce new feeds.

[jjmew]

@nkolev92 We think that reaching stable packages will be difficult because we rely on several pre-release packages than in turn depend on other pre-release packages. Reaching coherence with involved a change to the whole system. Having said that we will look at the specific packages that you pointed out. Those might ones that we could move to the latest stable version.

[13thirteen]

I would also like to express my interest in a public stable version of Microsoft.VisualStudio.ProjectSystem.Managed for consumption in my VSIX extension, see #6441.

[MagicAndre1981]

will those packages be ever published to nuget?

[drewnoakes]

@nkolev92 do you know if this is still an issue? I believe we made our analysers private so they shouldn't be contributing to a consumer's dependency graph.

[nkolev92]

I haven't attempted upgrading in the last month or 2 (16.10 -> 17.0 has given us a longer period), so I haven't been able to validate that just yet.

I can give a shot again, but it'll likely be early August when I can try it again.

[MagicAndre1981]

any update on this? Can we get a stable 16.x and 17.x version for VS2019/2022?

[chris-codeflow]

Like @MagicAndre1981, I think the developer community needs some guidance/recommendations on the best way to consume the Microsoft.VisualStudio.ProjectSystem.Managed and Microsoft.VisualStudio.ProjectSystem.Managed.VS packages in our Visual Studio extensions.

The guidance/recommendations should also include the relationship to the VS SDK packages.

[MiYanni]

@nkolev92 Checking in again to see if this is still an issue. Since our component is constantly evolving with Visual Studio, we're regularly updating the packages we rely on. Often, the packages we use will be preview packages. Therefore, we're unlikely to ever have a version of our package that is 'stable' (non-preview). We currently don't have a workflow were we swap our packages to non-preview versions before a VS release.

The package versions can currently be found here, but we might switch to Directory.Packages.props eventually.

[MagicAndre1981]

@nkolev92 Checking in again to see if this is still an issue.

for us normal users this is an issue. We need at least 1 stable version submitted to nuget with IActiveDebugFrameworkServices support. I need this to get the selected framework version when you have multiple TargetFrameworks set in the csproj.

[MiYanni]

@MagicAndre1981 We don't plan on publishing any new packages to NuGet.org, quite the opposite. We plan on delisting the current packages (since they are very much out-of-date). You can see the discussion in this issue. Our latest package can always be obtained via our public Azure DevOps feed (which is mentioned at the top of this issue). I can't really comment on further on making stable packages because, as mentioned, our dependencies are generally non-stable.

[MagicAndre1981]

@MagicAndre1981 Our latest package can always be obtained via our public Azure DevOps feed (which is mentioned at the top of this issue).

I know this and for me it worked. I made a PR to a project which gets reverted later as getting the nugets from the feed doesn't work for others while it worked for me.

[drewnoakes]

I know this and for me it worked. I made a PR to a project which gets reverted later as getting the nugets from the feed doesn't work for others while it worked for me.

Did you configure the package source on your machine, or in the code itself? It needs to be in the source code (project files) so that other machines find the package too.

This article might help: https://www.meziantou.net/defining-nuget-sources-in-the-csproj.htm

[MagicAndre1981]

I've updated the nuget.config in the project with vssdk, vs-impl and xliff-tasks feeds tested it on clean system and always got the prerelease versions. Earlier I linked the project where the changes got reverted. For the maintainer it was impossible to get the packages and I have no idea why.

We need at least 1 version on nuget that includes IActiveDebugFrameworkServices support to get the selected Targetframework in a project with multiple TargetFrameworks in the cproj.

[drewnoakes]

We're not planning on updating packages on nuget.org. NuGet supports custom package feeds, so understanding why that wasn't working in the specific case you mention and fixing it there is the way to go.

[nkolev92]

For the NuGet.Client team, it's really about the size of the dependency graph. I haven't tested it with recent versions just yet, but I'm guessing that'll be something we'll need to do soon, so I can report on that when we try to bump those versions.

[mitchcapper]

I am not sure I fully follow the arguments going on here against publishing versions to the nuget.org feed. I think the argument against the project-system team has made is:

• We build against beta versions of packages that are based on other beta/non-stable versions and they are not in the NuGet.org so it doesn't make sense to publish versions there
• We publish the latest version in our own devops feed people should just use that
• As we are always bleeding edge we really have no way of doing a 'stable' release.

Of course the problems with the current no-op process that occurs is

• Any extensions that want to upgrade and already exist won't find the updates as they are not in the normal nuget feed
• Projects have to add a custom Nuget.config file to add the devops feed
• The devops feed is highly unstable its basically nightly builds so rightfully so, but which should a developer choose? Guess pick one of the hundreds and hope?
• Even using the beta feed install is not straightforward. It seems even with a plethora of alternate nuget package sources: say https://github.com/microsoft/vstest/blob/main/NuGet.config you still may not be able to use the latest pre-release as it has deps on packages not found on any of those. For example right now version 17.6 has a dep on Microsoft.VisualStudio.projectSystem.SDK 17.5 or greater, but the latest pre-release is 17.4. Of course the deps are also not in sync, so what version does a user go back to, to get a version they can install? I guess currently that is the latest 17.4 beta. Wait no, seems 17.5.3-gbf0428edc0 at least. Of course im sure it goes beyond there but I don't feel like up-arrowing a package at a time to find out when the deps are on a package not in one of those beta feeds. In addition it doesn't follow any logic, while 17.5.3 works with 17.4 of MS.VS.* 17.2.0-beta1-20502-01 of this package actually requires 17.3 of MS.VS.*.

So developers are left with using a 3 year old version lacking some very nice features or trying to navigate the above. It isn't like extension developers are likely beginner programmers but is this potentially an unnecessarily complex step?

VS is an enterprise class product and extensions have first class 'support'. Is a potential solution to this to pick an old branch, say version 17.0.X or maybe even 17.2.X (given the fact most of the dependencies there are in Nuget.org already as pre-release). Test it mildly, is it not horridly unstable? Great. Update the deps to whatever mild other old package versions that seem pre-stable (or are released). push it to Nuget.org.

Doing this would take users from a 2020 version of the package to Oct of 2021 or May of 2022 respectively. You would still flag it as pre-release when published to nuget so it would be clear its not a 'stable' version but greatly ease the ability for developers to consume it.

For those looking to consume a somewhat updated version of Microsoft.VisualStudio.ProjectSystem.Managed here is what currently works:

1. On the project you want to upgrade add a Nuget.config file in the root containing:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <activePackageSource>
        <add key="All" value="(Aggregate source)" />
    </activePackageSource>
  <packageSources>
    <add key="vs-impl" value="https://pkgs.dev.azure.com/azure-public/vside/_packaging/vs-impl/nuget/v3/index.json" />
  </packageSources>
</configuration>

If you already have a nuget.config file just add the package source for vs-impl to it.

2. Go to the package manager make sure your "package source" dropdown is on all and you have pre-release checked.

3. For the Microsoft.VisualStudio.ProjectSystem.Managed package select version 17.5.19-gebf0e36166 this has all public deps and should install with just doing the above. It gets you to Thursday, October 13, 2022 worth of updates. Likely you can go a few versions beyond that (but I believe by 17.5.100 or 17.5.120 the deps are no longer avail). To use a newer version you will have to find the beta feeds for the other packages. Likely they are the ones indicated in: https://github.com/dotnet/project-system/blob/main/nuget.config technically it doesn't show a CI beyond 17.4 but hopefully thats it.

Profittt;)

If the project team doesn't go this route of course some 3rd party can probably do the above actions publish with a similar name. Extension developers who want to avoid the hassle probably just use the one updated package they find when they search. Of course if you wanted to perform an upstream attack being that 3rd party, waiting awhile, and then injecting malicious code into a package that gets consumed by extensions developers use and can then infect any project those developers work on certainly wouldn't be a great way to compromised a large number of builds.

[MiYanni]

@mitchcapper One thing that I'm going to be doing is adding to the repo is commit tags per VS release as mentioned here. This means that you'll be able to check a tag that says that particular commit was released in that particular version of Visual Studio. I don't currently have plans to relate those actual package versions... it might be something I can add later.

To your points, the packages we put on the feed are nightlies. I completely understand that there isn't a clear "I should use this version" path with this package model. Thinking about it, we (my team) internally knows when things are stabilizing for a release, but we don't have any external way to indicate that. As mentioned, we rely on many different packages from multiple teams to build our package. So, actually releasing a SemVer 'stable' package is still not on the table. However, based on what I first mentioned (proper commit tagging), there might be a way for me to name the packages differently so it is obvious which package to use, since those packages are what we created prior to a new VS release. This is an idea I'm just spit-balling from the top of my head, but would that at least give a bit more confidence on which package version to rely on for extension development?

I'd need to discuss the idea with team before working on it.

[mitchcapper]

there might be a way for me to name the packages differently so it is obvious which package to use, since those packages are what we created prior to a new VS release.

I think anything is an improvement over current, especially as you folks do already have an idea of what is stable. Hopefully if it is tagged for the current VS version then the deps as well are available.

As mentioned, we rely on many different packages from multiple teams to build our package. So, actually releasing a SemVer 'stable' package is still not on the table

I understand the argument against being able to release a Nuget.org package during nightlys and the added hassle that would bring. I was suggesting to infrequently release a much older package as by that time the deps would also hopefully have stabilized and have atleast pre-release releases (as you are not using the latest deps what the major/minor version from the time of that older package). IE you build the daily for commit for 17.5.1234-PSManaged_20230407 with a dep on the daily from Microsoft.VisualStudio.projectSystem.SDK which is 17.6.4432-SDK-20230406. Who knows availability or stability of that. In a year time though you could potentially go back to 17.5.1234-PSManaged_20230407 and change it from a dep on 117.6.4432-SDK-20230406 to a dep on pre-17.6-SDK. It takes a bit of extra time but it happens quite infrequently and would make it easier for extension development.

[MiYanni]

@mitchcapper I forgot to link this public document as it might help for understanding: https://learn.microsoft.com/en-us/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2022

Basically, that would be the list of VS versions that would have tags in our repo. Thinking about this some more, the idea I could bring to my team is that:

• Our public AzDO feed is only for nightly builds.
• If I have the tagging system up-and-running, I'll have the ability to run a "stable only" build. This build would only run when new VS versions are released (based on that document I linked you above). I could make that build only produce packages for NuGet.org. Then, those wanting to do extension development should (generally) only use NuGet.org as your feed since we deem those as 'stable' (even if the SemVer isn't non-prerelease).

I think that's the best I can do currently. Again, I'd need to discuss with my team. How does that sound?

Edit: (note for myself) Investigate AzDO feed views.

[mitchcapper]

I think that's the best I can do currently. Again, I'd need to discuss with my team. How does that sound?

I think most people here would find that quite amazing (and useful). I would assume only targeting minor versions would be great. If it is any easier from a dependency view, the nuget release could lag behind the actual nightly minor version (so say the 17.5 published version was actually from the 17.3 nightly). The difference between being 6-12 months behind the main branch and being 3 years is huge.

[MagicAndre1981]

• If I have the tagging system up-and-running, I'll have the ability to run a "stable only" build. This build would only run when new VS versions are released (based on that document I linked you above). I could make that build only produce packages for NuGet.org. Then, those wanting to do extension development should (generally) only use NuGet.org as your feed since we deem those as 'stable' (even if the SemVer isn't non-prerelease).

This would be great

[mitchcapper]

@MiYanni any chance of pushing for the 'stableish only' builds of this package? Nuget is still at the 2017 release.

At least it is easier than last time/s.

As I understand one of the concepts was to try and use the tagged builds to know what version to use. Steps I took:

1. I created a new project
2. added the dailys feed (https://pkgs.dev.azure.com/azure-public/vside/_packaging/vs-impl/nuget/v3/index.json)
3. checked my VS Version (17.10 preview 1), went to: https://github.com/dotnet/project-system/tags to find the commit ID that corresponds, oops there is no preview.1 tag for some reason but I see preview 2.
4. No worries, close all VS instances.
5. New installer so installer updates.
6. Go to Update VS, OK tells me to close all pwsh shells, I try to figure out why, realize I used a VS-env on one of them so track that down close just that one shell, success. Update starts 5.5 gb download and 1660 package update.
7. Relaunch project, back to nuget beta feed. Preview2 is tagged a944c3f on GH so look for said package in feed. For others, the nuget version is random version id (ie 17.10) + dash + prefixed with a g + shortCommitID + a few more letters of the commit (in this case ga944c3f). Hit install. Confirm the 100+ package install (although probably some hunk of that is .NET[core] polyfill as I am using .net framework 472 as must to write a VS visualizer).
8. Install fails, deps on Microsoft.CodeIndex.EnvVarDump which cannot be found. ALR I mean aware that we might need additional beta feeds lets google where that comes from. Literally 0 results on google. Switch to bing (I mean bing superior right?) and bam pages of GitHub related results, promising. Mostly from vscode and typescript repos, but still likely relevant. Click through multiple dozens of results across several pages, every one is a github actions run that is so old it 404s sadly bing's initial glimmer of hope is gone.
9. OK remember maybe we should add the nuget beta feed this project itself references: https://github.com/dotnet/project-system/blob/main/nuget.config so add https://pkgs.dev.azure.com/azure-public/vside/_packaging/dotnet-project-system-public-packages/nuget/v3/index.json as a package source.
10. Search again for the package, oops the "public-packages" feed I just added requires credentials the popup says. Lets try our MS Live act, maybe it just requires any credentials. Seems to work no error, oh wait nope just now says loading forever for that feed. Restarting VS fix? Nope still just infinite loading wheel. OK lets remove that beta feed.
11. OK we don't need the package to match our VS build lets try something older. How about release/vs/17.0.23 tag from July 19th 2023, c9fae6c. Scroll the long version list but no rc9fae6c nor verison number starting 17.0 so must have been too old. Oldest seems 17.7 so lets find a valid tag in that range. Bingo 17.7 tag is for commit ee1b6f4 find ree1b6f4 on the list as 17.7.278-gee1b6f4292.
12. Womp womp failure, even this super old tag requires the mysterious Microsoft.CodeIndex.EnvVarDump package.
13. Can we steal this package from the build system? Does it leak some magic URL we can use to fetch its goodness? Lets check the build logs. Hit the actions tab on GH, alright CI is not here just linting. Hit project homepage ok status badge points to https://dev.azure.com/devdiv/DevDiv/_build/latest?definitionId=9675&branchName=main for main pipeline. OK needs login. Auth with our live ID, tri factor auth with MS and get 401 1. Uh-oh, you do not have access. womp womp. Is there a reason to have several build pipeline links on the project page that all require (im guessing) a FTE ms account? I guess other FTEs maybe looking at GH:)
14. Lets read the readme again, maybe it has something helpful. OK details about the old system, how great the new interface based system is, a lovely screenshot showing the elusive Microsoft.VisualStudio.ProjectSystem.Managed.VS package installed, instructions on how to build the repo, but nothing about how to get the packages installed. Do I dare to build from scratch? Nothing in the instructions mentions complications or items hidden behind nuget feeds one cannot access. Still it likely doesn't do magic so lets check see what else we can find.
15. CONTRIBUTING.md talks about the CPS Documentation, I think that is the scope of what contains the packages so lets go there. Takes us to https://github.com/microsoft/vsprojectsystem. It talks about mostly custom projects but a sprinkling of extensions get mentioned so probably the right place. Links to Visual Studio Extensibility official MS VS2022 docs, sounds good. OK first page, nice section header says Overview with a link to Writing Visual Studio extensions. Hrm this VS2022 doc overview on writing extensions is from 2018, it probably just uses the 2017 package haha. OK lets go to this repos primary docs https://github.com/microsoft/VSProjectSystem/blob/master/doc/Index.md . First page talks again about custom project types but on the left we have extensibility docs, look through those no luck. Last ditch attempt search the repo for "Microsoft.VisualStudio.ProjectSystem.Managed" only to find this ticket mentioning familiar issues:) improve extensibility docs microsoft/VSProjectSystem#354 but no other help
16. HRM. Ok lets start scouring tickets see if we can find something relevant around it. Reduce number of package sources (feeds) for our builds [and declare in a single location] #8019 looks juicy. Link to a package artifact from build off devdiv.VS.com crap its authed for FTE.
17. @MiYanni made an interesting comment though on this thread

For our repo, we need all public feeds, so the best option is simply to find the smallest subset of public feeds to use.

HRM???????????????? is this still true? Wait fantastic a link is provided

Information for public repo feeds here: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/12676/Incident-help-for-Substitution-attack-risk-from-multiple-package-feeds?anchor=oss/public

Perfect! oh wait nope crap FTE auth. Something a bit ironic about the public feed documentation being private;)

ALR well thanks for joining my real time ted talk.

Before I could recommend one install version X of this package from the beta feed and it would work. We could have our project using a feature written in the last 7 years as long as we also added a nuget with the beta feed. Of course anyone who did this would have their projects break. It really is a CI feed not meant for use, but the only source for the updated VS library. Problem is the old version we had that worked, is no longer in the feed. So now the project just can't restore. I guess I can take from an old build folder I have the 38+ Microsoft.* dlls and move them into the repo into a bins folder and manually reference like that.

Maybe there is a magic version that doesn't have such a requirement. There are some other great bugs found along the way that could likely be resolved by MS releasing a updated package every half decade:

• Convert Microsoft.VisualStudio.ProjectSystem.Managed from PackageDownload to PackageReference NuGet/Home#9620
• Remote Debug fails for projects that multi target several frameworks (Error NETSDK1129) nforgeio/RaspberryDebugger#36
• CPS Custom In Memory Profile option MBulli/SmartCommandlineArgs#151
• Custom VS extension development #6441
• improve extensibility docs microsoft/VSProjectSystem#354
• Best way to detect target framework(s) in a CPS project VsixCommunity/Community.VisualStudio.Toolkit#430 (comment)

Or requiring reflection to access modern features like:

• MissingMethodException UnconfiguredProject.get_Services() in VS2019 when referencing ProjectSystem.15 #4608
• https://github.com/unoplatform/uno/blob/49ce9c0cf5570981261a010c3a24252974aa94fb/src/Uno.UI.RemoteControl.VS/DebuggerHelper/ProfilesObserver.cs#L326

half contemplating spending a weekend to get this to build, publish it to the official nuget feed under a slightly different name, while making a slight modification. Maybe just insert some MSIL shell code to open this ticket in the browser on March 9th every year for anyone consuming the dll ;)

You folks do good work stop hiding it from anyone but FTEs.

[MagicAndre1981]

8. Install fails, deps on Microsoft.CodeIndex.EnvVarDump which cannot be found. ALR I mean aware that we might need additional beta feeds lets google where that comes from. Literally 0 results on google.

This package can be found in this feed:

<!-- Used for the Rich Navigation indexing task -->
<add key="richnav" value="https://pkgs.dev.azure.com/azure-public/vside/_packaging/vs-buildservices/nuget/v3/index.json" />

[mitchcapper]

8. Install fails, deps on Microsoft.CodeIndex.EnvVarDump which cannot be found. ALR I mean aware that we might need additional beta feeds lets google where that comes from. Literally 0 results on google.

This package can be found in this feed:

Thanks! I don't think I ended up needing that feed for my latest run but good to know if I hit that specific block again.

In slightly other news, https://www.nuget.org/packages/CI.Microsoft.VisualStudio.ProjectSystem.Managed/

Look a nuget.org package with no special feed requirements, will not go stale and invalid (as nuget.org packages cannot be removed / have deps removed), and has the features from the last 7 years the old one is missing. I hope 17.11.1 was stable, as I marked it as such.

On the plus side only took me a few hours not a weekend.

We will be ingesting this for our deps, maybe you folks will figure out a real solution before too many others do the same. This release should be pretty clean though no binary changes to the dlls only minor nupkg config updates.

also did 17.7.37 for older VS compat options.

[MiYanni]

I haven't been on this team since 2023. After I left, @smitpatel had gotten the tagging mechanism working. You can look in this repo at the tags as those are stable commits to this repo. Meaning, those commits are the ones that go into Visual Studio. The Project System team would simply need to publish a build from this commit to NuGet.org if they wanted to do so. But it is up to them to decide that.

[mitchcapper]

Perfect I will attempt to start using the GH tags until they do.