vcpkg upgrade --no-dry-run no-longer functioning properly - Value was null

Created on 5 Feb 2020  路  20Comments  路  Source: microsoft/vcpkg

Describe the bug
When I try to do a _.\vcpkg upgrade --no-dry-run_ it deletes all the packages and the required downstream package dependencies but vcpkg fails to continue and reinstall the upgraded packages and any other related packages with the upgraded packages features.

Environment

  • OS: [Windows 10 x64 Version 1909 OS Build 18363.628]
  • OS: [Linux openSUSE x64 Version 15.1]
  • Compiler: Windows vs2017 v15.9.19 and vs2019 v16.4.4
  • Compiler: Linux gcc (SUSE Linus) v7.5.0

To Reproduce
Steps to reproduce the behavior:

  1. On windows - .\vcpkg upgrade --no-dry-run
    On Linux ./vcpkg upgrade --no-dry-run
  2. Errors

_On Windows:_

  • VS2017:
    SYSTEM@ANDROMEDA 02/04/2020 20:44:36 D:\Git\vs2017.prod
    ->vcpkg upgrade
    The following packages will be rebuilt:

    • mpi[core]:x64-windows

    • msmpi[core]:x64-windows

      Additional packages (*) will be modified to complete this operation.

      If you are sure you want to rebuild the above packages, run this command with the --no-dry-run option.

SYSTEM@ANDROMEDA 02/04/2020 20:46:24 D:\Git\vs2017.prod
->vcpkg upgrade --no-dry-run
The following packages will be rebuilt:

  • VS2019:
    SYSTEM@ANDROMEDA 02/04/2020 20:44:58 D:\Git\vs2019.prod
    ->vcpkg upgrade
    The following packages will be rebuilt:

    • mpi[core]:x64-windows

    • msmpi[core]:x64-windows

      Additional packages (*) will be modified to complete this operation.

      If you are sure you want to rebuild the above packages, run this command with the --no-dry-run option.

SYSTEM@ANDROMEDA 02/04/2020 20:47:31 D:\Git\vs2019.prod
->vcpkg upgrade --no-dry-run
The following packages will be rebuilt:

_On Linux:_
tim.autry@galactica:[~/git/vcpkg]

$ vcpkg upgrade --no-dry-run
The following packages will be rebuilt:

Expected behavior
vcpkg should delete packages to be upgraded along with downstream dependencies and then reinstall them.

Failure logs

  • There are no failure logs, only above output to console screen.

Additional context
Happens on Windows and Linux, I've tried Windows vcpkg built as x86 and x64, and Linux as x64.
It started a few days ago, I thought my vcpkg installs were corrupt, so I deleted and cloned them again from scratch. Then I thought maybe my fork on github was corrupt, so I delete my fork and recreated. I then delete my local vcpkg repositories and cloned them directly from microsoft/vcpkg. So then I tried another machine and the same thing happens - on windows I get Value was null and on linux I get a CMake Error: Error processing file: /home/tim.autry/git/vcpkg/scripts/get_triplet_environment.cmake.

I can recreate by manually increasing the version number in a package's _Control_ file,

Also on windows it started putting the "asterisk" in front of all packages, where before only the downstream packages had the "asterisk" and all the upgraded packages did not.

_I'm at a loss at what could be the issue - I deleted and cloned vcpkg at least a half dozen times this past few days I think I'm about to lose it???_

vcpkg-bug

Most helpful comment

Still having the "Value was null" problem (even with a fresh rebuilt vcpkg).
Isn't this considered high priority for a fix? Not being able to upgrade (and also outputting the error after having removed all the libraries, so in an undesired state) is a major inconvenience...

All 20 comments

Additional info: On Linux, after I removed the old vcpkg env from my .bashrc profile I now get the same message as windows on the ./vcpkg upgrade --no-dry-run Value was null.

So at least it is consistent now between x64-windows and x64-linux...

Confirmed, this issue reproed. @timautry, thanks for reporting this issue,
@ras0219-msft, this issue seems vcpkg bug that invoved in recently changes, could you help have a look?

Thank you @PhoebeHui @ras0219 !!!

A work-around would be to do the vcpkg upgrade omitting the --no-dry-run and capture that output, so you can build a script to do a vcpkg remove "_ports_" and then to do a vcpkg install "_ports_".

The remove may need you to add the --recurse option if there are ports depending on the ports being removed.

Just submitting I have the same error.

I am getting this as well.

Me too, on two different Windows systems.

Just wanted to point out that as a temporary workaround, you can read the list of new packages from upgrade without --no-dry-run, and then pass the packages to first remove and then install. This works fine for me.

Also seeing same bug. Is there a way to script this? I have about 50 packages involved.

As it uninstalls cgal, my workaround is to simply reinstall it, which picks up the missing dependencies (except tbb).

I'm also having the same issue on Windows 8.1 x64 with the latest Visual Studio 2019 build installed. Yesterday I set up an entirely "fresh" vcpkg installation hoping this would resolve the issue, but unfortunately without success. Please fix this - critical - bug as soon as possible, thank you very much!

Also seeing same bug. Is there a way to script this?

Put your dependencies in a vcpkg-install.txt file and you can simply reinstall everything from scratch whenever needed.

I am also having this issue. As of 2/14/2020, did a new pull, update, upgrade --no-dry-run. It removes boost (and others), although they still show up in "list". Fixing is a tedious process.

Latest error message:
Starting package 107/212: boost-modular-build-helper:x64-windows
Building package boost-modular-build-helper[core]:x64-windows...
CMake Error: Error processing file: E:/Libs/vcpkg/scripts/get_triplet_environment.cmake

My system does not have the mentioned cmake script.

Sorry, disregard previous comment. Looks like running the bootstrap script fixed the issue (for now).

Still having the "Value was null" problem (even with a fresh rebuilt vcpkg).
Isn't this considered high priority for a fix? Not being able to upgrade (and also outputting the error after having removed all the libraries, so in an undesired state) is a major inconvenience...

me too . win10

Had to remove AppVeyor caching because then packages are upgraded, and this fails. Also confirmed on Ubuntu 18.04 that I just rebuilt my project on.

@acgetchell exactly. This problem has huge problems for automated ci for downstream projects. I don't want to delete cache

I was trying to diagnose this issue and I made a tool to help me repeatedly reproduce the error:

https://github.com/rkitover/vcpkg-binpkg-prototype/

this is still a work in progress, and I need to check a few things for accuracy, but I may start using this.

But anyway, with this you can make a package of the outdated package, and when the failed upgrade operation deletes it, you can reinstall it to allow repeating the error.

I will try to do some more diagnosis of this, I've read most of the core vcpkg C++ sources already.

me too :(
win10, msvs - last version

Thanks everyone for identifying this regression so quickly and providing awesome repro steps!

It should be fixed on master via PR #10202.

@ras0219-msft @PhoebeHui
Thank you for fixing this!! I appreciate the hard work, and I don't know if this is a problem or not?

  • In the past before this last vcpkg code upgrade, vcpkg would show the ports needing to be upgraded without any symbol preceding them
  • Only the ports needing to be rebuilt due to the upgrades would be shown with an asterisk preceding it
  • In the example below, llvm and xlnt are to be upgraded
  • llvm is going to be upgraded, but halide depends on llvm so it too must be recompiled and it would show it with an asterisk proceeding it

->vcpkg upgrade
The following packages will be rebuilt:

  • halide[core,opencl,opengl,utils]:x64-windows
    llvm[core,example,test,tools,utils]:x64-windows
    xlnt[core]:x64-windows

Additional packages (*) will be modified to complete this operation.
If you are sure you want to rebuild the above packages, run this command with the --no-dry-run option.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

F0I0l0I0P picture F0I0l0I0P  路  3Comments

tzbo picture tzbo  路  3Comments

invy picture invy  路  3Comments

PhilLab picture PhilLab  路  3Comments

oahzuw picture oahzuw  路  3Comments