Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop using FileSystem and Common submodules #4536

Merged
merged 6 commits into from
Apr 21, 2022

Conversation

jeffkl
Copy link
Contributor

@jeffkl jeffkl commented Mar 31, 2022

Bug

Regression? Last working version:

Description

Most of this was done by @nkolev92, I just continued his work. Removes the FileSystem and Common submodules in favor of package references. This gets rid of the classes being compiled into our assemblies so they don't conflict with other types.

PR Checklist

  • PR has a meaningful title

  • PR has a linked issue.

  • Described changes

  • Tests

    • Automated tests added
    • OR
    • Test exception
    • OR
    • N/A
  • Documentation

    • Documentation PR or issue filled
    • OR
    • N/A

@jeffkl jeffkl requested a review from a team as a code owner March 31, 2022 15:32
@jeffkl jeffkl changed the title Dev jeffkl stop using submodules Stop using FileSystem and Common submodules Mar 31, 2022
nkolev92
nkolev92 previously approved these changes Mar 31, 2022
Copy link
Member

@nkolev92 nkolev92 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love it.

Did RPS pass?
Not sure if we need to do anything special to ensure source build is good beyond the build passing given that we're adding new assemblies.

cc @crummel

cc @zivkan We're deleting lots of public APIs here, but I think this is a risk we're 100% willing to take?

.gitmodules Show resolved Hide resolved
erdembayar
erdembayar previously approved these changes Mar 31, 2022
crummel
crummel previously approved these changes Mar 31, 2022
Copy link
Contributor

@crummel crummel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

source-build already includes MS.Extensions so this should be fine by us. Thanks for the ping!

zivkan
zivkan previously approved these changes Mar 31, 2022
Copy link
Member

@zivkan zivkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're deleting lots of public APIs here, but I think this is a risk we're 100% willing to take?

I agree. Removing the submodules will unavoidably break ABI compat, but since file globbing isn't a primary feature of nuget, we can just hope that very few people took that dependency.

Unfortunately namespaces changed, so it also breaks API compat. But that was the ASP.NET team's choice when they changed the namespace of these APIs.

@aortiz-msft
Copy link
Contributor

So cool. Out of curiosity, does this reduce the build time, both locally and on our CI? If yes, by how much?

@jeffkl
Copy link
Contributor Author

jeffkl commented Apr 4, 2022

RESOLVED

Does anyone know why only this one test is failing? Or at least how to figure out why its failing? Thanks in advance!

NetCoreToolsVSandMSBuildNoOp

System.Management.Automation.ItemNotFoundException: Cannot find path 'C:\Users\TestUser\.nuget\packages\.tools\Microsoft.VisualStudio.Web.CodeGeneration.Tools\1.0.0-msbuild3-final\netcoreapp2.0\Microsoft.VisualStudio.Web.CodeGeneration.Tools.nuget.cache' because it does not exist.
   at System.Management.Automation.LocationGlobber.ExpandMshGlobPath(String path, Boolean allowNonexistingPaths, PSDriveInfo drive, ContainerCmdletProvider provider, CmdletProviderContext context)
   at System.Management.Automation.LocationGlobber.ResolveDriveQualifiedPath(String path, CmdletProviderContext context, Boolean allowNonexistingPaths, CmdletProvider& providerInstance)
   at System.Management.Automation.LocationGlobber.GetGlobbedMonadPathsFromMonadPath(String path, Boolean allowNonexistingPaths, CmdletProviderContext context, CmdletProvider& providerInstance)
   at System.Management.Automation.LocationGlobber.GetGlobbedProviderPathsFromMonadPath(String path, Boolean allowNonexistingPaths, CmdletProviderContext context, ProviderInfo& provider, CmdletProvider& providerInstance)
   at System.Management.Automation.SessionStateInternal.GetProperty(String[] paths, Collection`1 providerSpecificPickList, CmdletProviderContext context)
   at Microsoft.PowerShell.Commands.GetItemPropertyCommand.ProcessRecord()

https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5964223&view=ms.vss-test-web.build-test-results-tab&runId=36869364&resultId=100100&paneView=debug

@nkolev92
Copy link
Member

nkolev92 commented Apr 4, 2022

Did you try running the test locally?

There's some end to end instructions in the one note.

@jeffkl jeffkl dismissed stale reviews from zivkan, crummel, erdembayar, and nkolev92 via bd3e501 April 5, 2022 14:34
@jeffkl jeffkl force-pushed the dev-jeffkl-stop-using-submodules branch from 95352cb to bd3e501 Compare April 5, 2022 14:34
@jeffkl
Copy link
Contributor Author

jeffkl commented Apr 5, 2022

Did you try running the test locally?

There's some end to end instructions in the one note.

Thanks for the pointer, I was able to run them locally after some trial and error, turns out we were missing a binding redirect entry in the pkgdef. That fixed the problem locally, I've pushed the change.

nkolev92
nkolev92 previously approved these changes Apr 5, 2022
@jeffkl
Copy link
Contributor Author

jeffkl commented Apr 7, 2022

So cool. Out of curiosity, does this reduce the build time, both locally and on our CI? If yes, by how much?

@aortiz-msft It will reduce the build time by a little since its not fetching these submodules during build anymore and no longer compiling the sources into our assemblies. I doubt it's going to save minutes of time though. This change is more about reducing the overhead of cloning and building our repository. There's also a bug where the types from these classes are public and can mess up consumers of our assemblies.

@jeffkl jeffkl dismissed stale reviews from zivkan and nkolev92 via f2d4d50 April 7, 2022 15:01
@jeffkl
Copy link
Contributor Author

jeffkl commented Apr 7, 2022

@nkolev92 or @zivkan do you know if I need to update this?

folder InstallDir:\Common7\IDE\CommonExtensions\Microsoft\NuGet
file source=$(NuGetTargetsBasePath)NuGet.targets
file source=$(NuGetTargetsBasePath)NuGet.props
file source=$(NuGetTargetsBasePath)NuGet.RestoreEx.targets
file source=$(ReferenceOutputPath)Microsoft.Web.XmlTransform.dll
file source=$(ReferenceOutputPath)Microsoft.Build.NuGetSdkResolver.dll
file source=$(NewtonsoftJsonPath)Newtonsoft.Json.dll
file source=$(ReferenceOutputPath)NuGet.Build.Tasks.dll
file source=$(ReferenceOutputPath)NuGet.Build.Tasks.Console.exe
file source=$(ReferenceOutputPath)NuGet.Build.Tasks.Console.exe.config
file source=$(ReferenceOutputPath)NuGet.Commands.dll
file source=$(ReferenceOutputPath)NuGet.Common.dll
file source=$(ReferenceOutputPath)NuGet.Configuration.dll
file source=$(ReferenceOutputPath)NuGet.DependencyResolver.Core.dll
file source=$(ReferenceOutputPath)NuGet.Frameworks.dll
file source=$(ReferenceOutputPath)NuGet.LibraryModel.dll
file source=$(ReferenceOutputPath)NuGet.PackageManagement.dll
file source=$(ReferenceOutputPath)NuGet.Packaging.dll
file source=$(ReferenceOutputPath)NuGet.ProjectModel.dll
file source=$(ReferenceOutputPath)NuGet.Protocol.dll
file source=$(ReferenceOutputPath)NuGet.Resolver.dll
file source=$(ReferenceOutputPath)NuGet.Versioning.dll
file source=$(ReferenceOutputPath)NuGet.Credentials.dll

@nkolev92
Copy link
Member

nkolev92 commented Apr 7, 2022

@jeffkl Yep.

That VSIX is for the build tools SKU and it needs restore to work.

@jeffkl
Copy link
Contributor Author

jeffkl commented Apr 7, 2022

That VSIX is for the build tools SKU and it needs restore to work.

@nkolev92 do you know if Apex, end-to-end tests, or anything else do anything with BuildTools SKU? Or do I just need to manually test it?

@nkolev92
Copy link
Member

nkolev92 commented Apr 7, 2022

They don't, but there are manual vendors tests for this, but they are not super detailed.

@jeffkl jeffkl force-pushed the dev-jeffkl-stop-using-submodules branch 2 times, most recently from 464e17a to 46873a1 Compare April 11, 2022 21:50
@ghost ghost added the Status:No recent activity PRs that have not had any recent activity and will be closed if the label is not removed label Apr 18, 2022
@ghost
Copy link

ghost commented Apr 18, 2022

This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.

@jeffkl jeffkl removed the Status:No recent activity PRs that have not had any recent activity and will be closed if the label is not removed label Apr 19, 2022
@jeffkl
Copy link
Contributor Author

jeffkl commented Apr 19, 2022

@NuGet/nuget-client please review

Copy link
Member

@nkolev92 nkolev92 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢

@jeffkl jeffkl merged commit cebb690 into dev Apr 21, 2022
@jeffkl jeffkl deleted the dev-jeffkl-stop-using-submodules branch April 21, 2022 13:32
@nkolev92
Copy link
Member

🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳 🥳

erdembayar added a commit that referenced this pull request Apr 27, 2022
nkolev92 pushed a commit that referenced this pull request Apr 27, 2022
jeffkl added a commit that referenced this pull request May 2, 2022
Revert "Revert "Stop using FileSystem and Common submodules (#4536)" (#4595)"

This reverts commit 5ac16d7.
jeffkl added a commit that referenced this pull request Nov 1, 2022
Revert "Revert "Stop using FileSystem and Common submodules (#4536)" (#4595)"

This reverts commit 5ac16d7.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants