search

dotnet / project-system

The .NET Project System for Visual Studio
MIT License
967 stars 385 forks source link

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

Open nkolev92 opened 3 years ago

nkolev92 commented 3 years ago

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 commented 3 years ago

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

nkolev92 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

will those packages be ever published to nuget?

drewnoakes commented 3 years ago

@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 commented 3 years ago

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 commented 2 years ago

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

chris-codeflow commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 IActiveDebugFrameworkServicessupport. I need this to get the selected framework version when you have multiple TargetFrameworks set in the csproj.

MiYanni commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 Targetframeworkin a project with multiple TargetFrameworks in the cproj.

drewnoakes commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

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

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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:

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 commented 1 year ago

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 commented 1 year ago
  • 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 commented 5 months ago

@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)
    1. 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.
    2. No worries, close all VS instances.
    3. New installer so installer updates.
    4. 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.
    5. Relaunch project, back to nuget beta feed. Preview2 is tagged a944c3f2ff276a4bbbb97e608afd47658ba3112d 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).
    6. 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.
    7. 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.
    8. 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.
    9. 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.
    10. Womp womp failure, even this super old tag requires the mysterious Microsoft.CodeIndex.EnvVarDump package.
    11. 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:)
    12. 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.
    13. 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:) https://github.com/microsoft/VSProjectSystem/issues/354 but no other help
    14. HRM. Ok lets start scouring tickets see if we can find something relevant around it. https://github.com/dotnet/project-system/issues/8019 looks juicy. Link to a package artifact from build off devdiv.VS.com crap its authed for FTE.
  3. @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:

Or requiring reflection to access modern features like:

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 commented 4 days ago
  1. 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 commented 2 days ago
  1. 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 commented 18 hours ago

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 commented 17 hours ago

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