Fix empty combobox when package is not present in project file#4844
Fix empty combobox when package is not present in project file#4844
Conversation
|
|
||
| // Add installed version if the project is PackageReference | ||
| if (_nugetProjects.Any() && installedDependency != null && installedDependency.VersionRange != null && _nugetProjects.First().ProjectStyle.Equals(ProjectModel.ProjectStyle.PackageReference)) | ||
| if (_nugetProjects.Any() && installedDependency != null && installedDependency.VersionRange.OriginalString != null && _nugetProjects.First().ProjectStyle.Equals(ProjectModel.ProjectStyle.PackageReference)) |
There was a problem hiding this comment.
I'm trying to understand why original string would be null when a package is not in the csproj file.
Is the package not being in the csproj file the problem, or is it the fact that it's autoreferenced?
There was a problem hiding this comment.
I'm not sure if it is because is auto referenced but it could also be the problem. I was taking the .csproj as the only source for packages. When creating the versions from the project file we create the object from a string using VersionRange.Parse(string), this is the only way the attribute OriginalString is populated, so I think because this package is autoreferenced, im not sure how but probably using new VersionRange(Version)
There was a problem hiding this comment.
I'd find it surprising if we're generating the Version Range differently for autoreferenced package.
At least in the nomination workflow. Maybe there's something we do differently in the PM UI side?
There was a problem hiding this comment.
I'll double check this behavior
There was a problem hiding this comment.
I found that when the package is autoreferenced we use new VersionRange() and this doesnt populates the OriginalString attribute. https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.PackageManagement/BuildIntegratedPackageReference.cs#L91
There was a problem hiding this comment.
I see.
A few ideas:
- We can consider making sure that we have an original version there no? Just doing that is probably not the right fix, but it's a valid consideration.
- If OriginalString isn't an option should we show the normalized version instead?
There was a problem hiding this comment.
Please note that for an auto referenced version you should not be able to update the version through the PM UI.
There was a problem hiding this comment.
- OriginalString cannot be set, only by using VersionRange.Parse()
- The change in L170 is not affecting functionality, right we are displaying the version that the user wrote in the .csproj at the top and then all the versions, with this fix, if the OriginalString is null then we will display the latest version and then all the versions, like before but with filtering
There was a problem hiding this comment.
I tried considering using the normalized version when the OriginalString was null, but this created more issues when adding the blocking versions later in the code and would need more changes.
| foreach (var version in blockedVersions) | ||
| { | ||
| _versions.Add(new DisplayVersion(version, string.Empty, isValidVersion: false)); | ||
| _versions.Add(new DisplayVersion(version, additionalInfo: null, isValidVersion: false)); |
There was a problem hiding this comment.
I'm doing this to keep the same format like in https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Clients/NuGet.PackageManagement.UI/Models/PackageDetailControlModel.cs#L218
| get | ||
| { | ||
| return SelectedVersion != null && !IsSelectedVersionInstalled; | ||
| return SelectedVersion != null && !IsSelectedVersionInstalled && !InstalledVersionIsAutoReferenced; |
There was a problem hiding this comment.
If the package is autoreferenced then block the Update button
|
Manually debugging the fix appears to work. |
|
Initial look it doesn't seem related. I'll merge when the build passes. |
#4848) Co-authored-by: Martin Ruiz <martin.ruiz.mares@gmail.com>
Insert 6.4.0-rc.123 into rel/d17.4 on 11/07/2022 23:47:12 * tag '6.4.0.123': (60 commits) fix a logic error that caused AbandonedMutexException while executing migrations (release-6.4.x) (NuGet#4895) unblock source build failing due to fatal: transport 'file' not allowed error (NuGet#4867) (NuGet#4874) Signing: update to August 2022 CTL (NuGet#4791) (NuGet#4850) Merged PR 422933: Prefer BCL Directory create API over helper class (7.0.1xx-rc2) Fix empty combobox when package is not present in project file (NuGet#4844) (NuGet#4848) Fix component detection alert for microsoft.owin package (NuGet#4841) (NuGet#4845) Make release label RC, move to escrow mode Adds special case to include transitive origins in GetInstalledAndTransitivePackagesAsync API (NuGet#4824) Add longPathAware manifest to NuGet.Build.Tasks.Console (NuGet#4830) VsPackageInstallerServices should not post ProjectNotNominatedException faults (NuGet#4814) Skip test GetOrCreateAsync_WithUnhandledExceptionInPlugin_Throws (NuGet#4831) Improve OptProf pipeline job run names (NuGet#4825) Increase HttpClientHandler.MaxConnectionsPerServer to 64 to improve PM UI performance in Visual Studio (NuGet#4798) Suppress CA2213 warnings to unblock dev branch (NuGet#4823) Ensure IsVsOfflineFeed is calculated correctly on 64-bit machines (NuGet#4817) Add better handling of AggregateExceptions in static graph-based restore (NuGet#4809) Add Component Detection task into each pipeline (NuGet#4813) Localizes nuget.exe with default, embedded resource assembly lookup (NuGet#4773) Removes BrowseObjectBase class in NuGet Solution Explorer (NuGet#4807) Improve TryCreateContext (NuGet#4762) ...
Bug
Fixes: NuGet/Home#12057
Regression? Last working version:
Description
For some type of projects there are installed packages that are not listed in the project file (.csproj). This was not considered when developing the combobox version and breaks when trying to get the OriginalVersion.
Before:

After:

PR Checklist
PR has a meaningful title
PR has a linked issue.
Described changes
Tests
Documentation