Cannot build 0.9 locally - Package are not restored properly #6664

Closed
opened 2026-01-31 00:44:14 +00:00 by claunia · 5 comments
Owner

Originally created by @tebeco on GitHub (Feb 29, 2020).

Environment

Windows build number: Microsoft Windows [Version 10.0.19041.113]
Windows Terminal version (if applicable): origin/release-0.9
VS2019 Preview 16.5.0 preview 4

Steps to reproduce

> git reset --hard
> git clean -fdx
> git submodule update --init --recursive
> start ./OpenConsole.sln

image

then press Ctrl+Maj+B

Expected behavior

Build should pass

Actual behavior

  • Visual Studio does not load lots of project even though it let you beleibe it did restore "packages"
  • Right click on Solution > Restore > does nothing / does not fix anything either
  • dotnet restore > probably noop > does not fix anything

Workaround

Should the doc be updated and inform users that they need to download nuget.exe from nuget.org and manually run /path/to/nuget.exe restore
(This is what fixed it for me

Originally created by @tebeco on GitHub (Feb 29, 2020). # Environment ```none Windows build number: Microsoft Windows [Version 10.0.19041.113] Windows Terminal version (if applicable): origin/release-0.9 VS2019 Preview 16.5.0 preview 4 ``` # Steps to reproduce ``` checkout origin/release-0.9 > git reset --hard > git clean -fdx > git submodule update --init --recursive > start ./OpenConsole.sln ``` ![image](https://user-images.githubusercontent.com/2266487/75611036-f40b2280-5b16-11ea-9e09-2fc674a44a74.png) then press `Ctrl+Maj+B` # Expected behavior Build should pass # Actual behavior * Visual Studio does not load lots of project even though it let you beleibe it did restore "packages" * Right click on Solution > Restore > does nothing / does not fix anything either * `dotnet restore` > probably noop > does not fix anything # Workaround Should the doc be updated and inform users that they need to download `nuget.exe` from `nuget.org` and manually run `/path/to/nuget.exe restore` (This is what fixed it for me
claunia added the Resolution-Duplicate label 2026-01-31 00:44:14 +00:00
Author
Owner

@zadjii-msft commented on GitHub (Mar 2, 2020):

Hey so since you filed three issues that are all fundamentally about "getting the build to work", I'm gonna close these two as a /dup of #4754, since that one has more discussion in it. Thanks!

@zadjii-msft commented on GitHub (Mar 2, 2020): Hey so since you filed three issues that are all fundamentally about "getting the build to work", I'm gonna close these two as a /dup of #4754, since that one has more discussion in it. Thanks!
Author
Owner

@ghost commented on GitHub (Mar 2, 2020):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Mar 2, 2020): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Author
Owner

@tebeco commented on GitHub (Mar 2, 2020):

hello @zadjii-msft

sorry about that, depending of the maintainers of repositories, some prefer having dedicated issue and some don't
As it was 3 completely different erros, i made the choices of 3 issues are they are unrealted and each fix are also probably independant (if such fixes to do, not even sure)

@tebeco commented on GitHub (Mar 2, 2020): hello @zadjii-msft sorry about that, depending of the maintainers of repositories, some prefer having dedicated issue and some don't As it was 3 completely different erros, i made the choices of 3 issues are they are unrealted and each fix are also probably independant (if such fixes to do, not even sure)
Author
Owner

@zadjii-msft commented on GitHub (Mar 2, 2020):

Typically, yes we'd prefer separate issues for separate bugs. The build is a bit of a different beast though, usually issues in the build from one part will cause seemingly unrelated issues in other parts of the build, and they all end up being the same root problem. For those, I'd rather have one big issue with all the build errors in it to be able to track down easily which is the actual problem. That's my 2c.

@zadjii-msft commented on GitHub (Mar 2, 2020): Typically, yes we'd prefer separate issues for separate bugs. The build is a bit of a different beast though, usually issues in the build from one part will cause seemingly unrelated issues in other parts of the build, and they all end up being the same root problem. For those, I'd rather have one big issue with all the build errors in it to be able to track down easily which is the actual problem. That's my 2c.
Author
Owner

@tebeco commented on GitHub (Mar 2, 2020):

fine for me
can you take a look at this comment then : https://github.com/microsoft/terminal/issues/4754#issuecomment-593456054 ?
I'm trying to understand how/what is your "typical workflow", and if you do/how use Visual Studio since i do have to edit files, or do manual restore in order to be able to build

we can continue the discussion over there to have only on big thread as you stated

@tebeco commented on GitHub (Mar 2, 2020): fine for me can you take a look at this comment then : https://github.com/microsoft/terminal/issues/4754#issuecomment-593456054 ? I'm trying to understand how/what is your "typical workflow", and if you do/how use `Visual Studio` since i do have to edit files, or do manual restore in order to be able to build we can continue the discussion over there to have only on big thread as you stated
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#6664