Unable to update solution - MSBUILD : error MSB1008: Only one project can be specified.

[shanselman]

Oddly unable to update my two project razor solution (Test->Website). I'm getting an odd MSBUILD error which usually means there's a path/trailing slash issue?

111→ C:\github\hanselminutes-core\hanselminutes.core [main ≡ +1 ~0 -0 !]> nukeeper mode=update dir="c:/github/hanselmin
utes-core/hanselminutes.core/"
Using 'update' for 'mode'
Using 'https://api.github.com' for 'github_api_endpoint'
Using '3' for 'max_pull_requests_per_repository'
Using '10' for 'max_repositories_changed'
Using 'Info' for 'log_level'
Using 'Major' for 'allowed_version_change'
Using '7d' for 'min_package_age'
Using 'PreferFork' for 'fork_mode'
Using 'Off' for 'report_mode'
Using 'nukeeper' for 'github_labels'
Using 'c:/github/hanselminutes-core/hanselminutes.core/' for 'dir'
Running NuKeeper in update mode
Found 8 packages in use, 8 distinct, in 1 projects.
BuildBundlerMinifier, LazyCache, LazyCache.AspNetCore, Markdig, Microsoft.ApplicationInsights.AspNetCore, Microsoft.AspNetCore.App, Microsoft.Extensions.Http.Polly, Microsoft.NET.Test.Sdk
Found 6 possible updates
BuildBundlerMinifier from 2.7.385 to 2.8.391 in hanselminutes-core.csproj
Markdig from 0.15.0 to 0.15.1 in hanselminutes-core.csproj
Microsoft.ApplicationInsights.AspNetCore from 2.3.0-beta2 to 2.3.0 in hanselminutes-core.csproj
Microsoft.NET.Test.Sdk from 15.7.0 to 15.7.2 in hanselminutes-core.csproj
Microsoft.Extensions.Http.Polly from 2.1.0 to 2.1.1 in hanselminutes-core.csproj
Microsoft.AspNetCore.App from 2.1.0 to 2.1.2 in hanselminutes-core.csproj

Selection of package updates: 6 candiates, filtered to 4, capped at 3
Updating Microsoft.ApplicationInsights.AspNetCore to 2.3.0 from 2.3.0-beta2 in 1 place since 2 months ago.

Unhandled Exception: System.Exception: Exit code: 1

MSBUILD : error MSB1008: Only one project can be specified.
Switch: Files

For switch syntax, type "MSBuild /help"



   at NuKeeper.Update.ProcessRunner.ExternalProcess.Run(String workingDirectory, String command, String arguments, Boolean ensureSuccess) in C:\Code\NuKeeper\NuKeeper.Update\ProcessRunner\ExternalProcess.cs:line 46
   at NuKeeper.Update.Process.DotNetUpdatePackageCommand.Invoke(PackageInProject currentPackage, NuGetVersion newVersion, PackageSource packageSource, NuGetSources allSources) in C:\Code\NuKeeper\NuKeeper.Update\Process\DotNetUpdatePackageCommand.cs:line 34
   at NuKeeper.Update.UpdateRunner.Update(PackageUpdateSet updateSet, NuGetSources sources) in C:\Code\NuKeeper\NuKeeper.Update\UpdateRunner.cs:line 27
   at NuKeeper.Local.LocalUpdater.ApplyAnUpdate(IReadOnlyCollection`1 updates, NuGetSources sources) in C:\Code\NuKeeper\NuKeeper\Local\LocalUpdater.cs:line 52
   at NuKeeper.Local.LocalEngine.Run(SettingsContainer settings) in C:\Code\NuKeeper\NuKeeper\Local\LocalEngine.cs:line 54
   at NuKeeper.Program.Main(String[] args) in C:\Code\NuKeeper\NuKeeper\Program.cs:line 28
   at NuKeeper.Program.<Main>(String[] args)

[skolima]

Looks a lot like #243 , but, well, that one is now covered by a tests and works.

If you can't share the project code (just .csproj with the folder structure would be enough - but that one isn't public, is it?), could you please post the log when running with log=Verbose and also the results of dotnet --version and dotnet --list-sdks? I'd suspect NuKeeper might be picking up an unexpected dotnet version.

Most of all, welcome!

[skolima]

Oh. Found the issue. Passing in NuGet sources doesn't quote the arguments - this doesn't trigger when adding them from command line, but when they're read from NuGet configuration, it does.

[shanselman]

I think it's here? It's not the quoting (could be...but) it seems that the project file goes at the END after the -s options.

18ea767#r29680916

[skolima]

I'm getting this generated as command line: dotnet restore SampleProject.csproj -s https://api.nuget.org/v3/index.json -s http://internal-server/nuget -s file:///C:/Program Files (x86)/Microsoft SDKs/NuGetPackages/ when settings are being auto-loaded from nuget.config files.

[shanselman]

Is it not supposed to be dotnet restore -s https://api.nuget.org/v3/index.json -s http://internal-server/nuget -s file:///C:/Program Files (x86)/Microsoft SDKs/NuGetPackages/ SampleProject.csproj ? with the project at the end? It works for me when I swap them and end on the project file.

[skolima]

No, that version fails (at least in some versions of dotnet command line). It's a bit picky. But if I quote the local cache to be -s "file:///C:/Program Files (x86)/Microsoft SDKs/NuGetPackages/" the restore works. We've got this bug in 3 places.

[shanselman]

Yep, you're right. My bad. I was confused. You are correct.

[shanselman]

So, now, having fixed that locally for myself, I now see multiple updates, but one run only updates one reference? Is that to be expected?

Selection of package updates: 4 candiates, filtered to 3
Updating BuildBundlerMinifier to 2.8.391 from 2.7.385 in 1 place since 2 months ago.
dotnet update package BuildBundlerMinifier in path c:\github\hanselminutes-core\hanselminutes.core hanselminutes-core.csproj from source https://api.nuget.org/v3/index.json
DEBUG1: dotnet restore -s https://api.nuget.org/v3/index.json -s file:///C:/Program Files (x86)/Microsoft SDKs/NuGetPackages/ hanselminutes-core.csproj
DEBUG2: dotnet remove hanselminutes-core.csproj package BuildBundlerMinifier
DEBUG3: dotnet add hanselminutes-core.csproj package BuildBundlerMinifier -v 2.8.391 -s https://api.nuget.org/v3/index.json

It stops there. Just updates the one. I have to run it n times?

[skolima]

Uhm, right - @AnthonySteele ? :-) The mode=update is a bit experimental, I'm fully not clear on the use case. But currently it does stop after applying the first update, so that you can commit it yourself. For GitHub-connected modes, you can control how many PRs are created with maxpr=NUM parameter, and that's the more battle-tested mode.

[shanselman]

Cool, thanks! I expected it would iterate. Even if it needed to dotnet restore or whatever. I'll keep this up to date as things continue! Thanks for your time!

[AnthonySteele]

Hi.

yes, the first way that NuKeeper worked was to tell it to "raise n Pull Requests, each containing 1 update" and NuKeeper would do the rest; including, if there are lots of possible updates, choosing the most important updates based on some heuristics. We do not yet support any Batching of updates in PRs since working out what to batch together is not trivial.

Local modes are newer, and might be expanded in future. Right now it exits after applying 1 update.

[shanselman]

Gotcha. I like the LOCAL idea of creating n commits, each containing 1 update. I'm still getting emotionally used to the bot idea ;)

[skolima]

It's a bit scary at first, indeed. Especially when something like https://www.nuget.org/packages/Microsoft.NET.Test.Sdk/ has a new stable release and ALL the projects in your organisation get a PR.

[AnthonySteele]

The initial idea was taken from greenkeeper - the generated PR ties into whatever existing branch build and test automation you have. So if the PR passes the test suite, you should have some confidence for a person to press the "merge" button.

Or if it's not a good PR, just close it, it hasn't actually broken anything :)