NuGet.Commands embedded copy of FileSystemGlobbing is now public

[analogrelay]

Because preprocess code is not available in RC2, the code that "internalizes" the copy of FileSystemGlobbing that NuGet.Commands embeds isn't in effect. As a result, the classes are public and conflict with the real FileSystemGlobbing. I've worked around it in CLI, but it should be fixed.

/cc @emgarten @yishaigalatzer @davidfowl

[yishaigalatzer]

We can probably move to consume the official FileSystemGlobbing

[emgarten]

The FileSystemGlobbing package does not support net45, only net451. NuGet still needs net45 for Visual Studio.

[emgarten]

@anurse is it possible to get a version of FileSystemGlobbing with support for net45 on nuget.org?

[analogrelay]

What is the context that requires .NET 4.5? Both .NET 4.5 and 4.5.1 are outside the extended support date according to the support lifecycle (https://support.microsoft.com/en-us/lifecycle/search?sort=PN&alpha=.net%20framework%204). So even on older (supported) versions of Visual Studio we'd be expecting users to have updated from 4.5 to 4.5.2 (at least)

[emgarten]

nuget.exe is net45 and changing it could break some users

[yishaigalatzer]

Is there anything requiring it to be 4.5.1?

[analogrelay]

Technically, I don't think so, but .NET 4.5 is not supported by Microsoft so it's not really my decision :)

[analogrelay]

nuget.exe is net45 and changing it could break some users

True, but they're already on an unsupported framework.

[rrelyea]

@anurse I'd prefer to minimize the engineering work here to use this package, and we still have a business need to not require people to have to update their .NET Framework versions just to continue to use the latest version of NuGet.exe.
Targeting 4.5 in your package, if your api usage allows, should be easy...and doesn't mean that microsoft now needs to do security patches for 4.5.
Wanted to talk to you in person, but you aren't at your desk.

[analogrelay]

@rrelyea As I said, there's no technical issue that I'm aware of, so if it gets approval from our PMs we can do it.

[rrelyea]

Filed request on aspnet team: aspnet/FileSystem#212

[Eilon]

Can NuGet just change all their types to be internal? Does NuGet still take drops of new FileSystemGlobbing source code? Or is it just using some particular version that can essentially be forked?

[emgarten]

The types could be changed to internal to work around this, but ideally we want to stop maintaining a fork and just use the official package.

Currently NuGet has a submodule which references the NuGet/SubModuleIntegration branch of FileSystemGlobbing.

[Eilon]

If we change it in the official package, the next official build won't be until a few months from now. Will you use nightly builds or wait for 1.1.0 RTM?

[emgarten]

We need a stable version, but NuGet can work around this as needed until 1.1.0 is out.

[Eilon]

Ok. We will try to get this updated for 1.1.0, barring any issues we run into.

[rrelyea]

Should be ready for us to fix in 3.6beta.

[BrennanConroy]

This is done on our side

[koliyo]

I just bumped into this exact problem.

Package.cs(404,31): error CS0433: The type 'Matcher' exists in both 'Microsoft.Extensions.FileSystemGlobbing, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' and 'NuGet.Commands, Version=5.10.0.7240, Culture=neutral, PublicKeyToken=31bf3856ad364e35' [/Users/nils/Work/bravo/Bml/Bml.csproj]

And I think going forward this could possibly cause more problems if not fixed, compared to the potential backward compatibly problems with dropping support for legacy .NET 4.5 users.

[nkolev92]

@jeffkl the checklist confused GH :D
Closing this given that you fixed it.

[erdembayar]

Reverted the merge NuGet/NuGet.Client#4595, so I'm reopening the issue.
See https://github.com/NuGet/Client.Engineering/issues/1581 for details.
Fyi @jeffkl @nkolev92