Visual Studio fails to restore PackageReferences when bin and obj folders have been deleted #4528

Closed
bording opened this Issue Feb 8, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@bording

bording commented Feb 8, 2017

NuGet product used: VS UI
NuGet version: VS 2017 integrated version
VS version: VS 2017 RC4 (15.0.0-RC4+26206.0)
OS version: win10 v1607 (14393.693)

When using PackageReferences with one of the project formats that support them (WPF, WindowsForms and UWP Projects), if the bin & obj folders are deleted while Visual Studio has the solution open, VS fails to properly restore any referenced packages and the build will fail. A second build attempt will then properly restore the packages and everything builds properly.

When the build fails, the package disappears from the References list in Solution Explorer.

Before:
package

After deleting the folders and getting the failed build:
failed-build

After the second, successful build, the package reappears in the References list.

Seeing how the bin and obj folders are not typically committed as part of a repo, this means that this problem can be hit rather easily, especially when using something like git clean -xdf to remove all untracked files. This was never a problem in Visual Studio 2015 and earlier. I have also verified that this doesn't happen in VS 2017 when using packages.config instead of PackageReferences.

Repro steps

  1. Create a new Windows Form App
  2. Add a NuGet package (for example, NewtonSoft.Json) via a PackageReference
  3. Add some code so that building depends on the new package: var serializer = new Newtonsoft.Json.JsonSerializer();
  4. Delete the bin and obj folders.
  5. Build the project. At this point the build will fail because of the code added in step 3.
  6. Build the project again. Everything will be built successfully.
@nkolev92

This comment has been minimized.

Show comment
Hide comment
@nkolev92

nkolev92 Feb 8, 2017

Member

We throw an exception if the obj folder is not created in:

https://github.com/NuGet/NuGet.Client/blob/a192c0d2c0a627642211e04ba9808f840e205d94/src/NuGet.Clients/PackageManagement.VisualStudio/ProjectSystems/LegacyCSProjPackageReferenceProject.cs#L191

Not sure why we do that.
Investigating the impact of removing this check

Member

nkolev92 commented Feb 8, 2017

We throw an exception if the obj folder is not created in:

https://github.com/NuGet/NuGet.Client/blob/a192c0d2c0a627642211e04ba9808f840e205d94/src/NuGet.Clients/PackageManagement.VisualStudio/ProjectSystems/LegacyCSProjPackageReferenceProject.cs#L191

Not sure why we do that.
Investigating the impact of removing this check

@nkolev92

This comment has been minimized.

Show comment
Hide comment
@nkolev92

nkolev92 Feb 8, 2017

Member

The only repro that I have found for this problem is doing a git clean while the solution is open in VS.

Doing an msbuild clean does not touch the obj nuget assets.
Opening a newly checked-out solution does not cause problems because VS would create the obj/bin folders.

Member

nkolev92 commented Feb 8, 2017

The only repro that I have found for this problem is doing a git clean while the solution is open in VS.

Doing an msbuild clean does not touch the obj nuget assets.
Opening a newly checked-out solution does not cause problems because VS would create the obj/bin folders.

@bording

This comment has been minimized.

Show comment
Hide comment
@bording

bording Feb 8, 2017

@nkolev92 Thanks for taking a look at this!

Doing an msbuild clean does not touch the obj nuget assets.

It does look like it's being considered for this behavior to change: #4476

bording commented Feb 8, 2017

@nkolev92 Thanks for taking a look at this!

Doing an msbuild clean does not touch the obj nuget assets.

It does look like it's being considered for this behavior to change: #4476

@nkolev92

This comment has been minimized.

Show comment
Hide comment
@nkolev92

nkolev92 Feb 8, 2017

Member

@bording Good catch.
#4476 would only clean up the data inside the folder though so it should not cause a problem.

What I should've said is:
Doing an msbuild clean does not delete the obj folder.

Member

nkolev92 commented Feb 8, 2017

@bording Good catch.
#4476 would only clean up the data inside the folder though so it should not cause a problem.

What I should've said is:
Doing an msbuild clean does not delete the obj folder.

@rrelyea rrelyea modified the milestones: 4.0.1, 4.0 RTM Feb 8, 2017

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Feb 8, 2017

Contributor

Post RTM.

Contributor

rrelyea commented Feb 8, 2017

Post RTM.

@nkolev92

This comment has been minimized.

Show comment
Hide comment
@nkolev92

nkolev92 Mar 2, 2017

Member

@rrelyea Should we merge this to 4.1?

Member

nkolev92 commented Mar 2, 2017

@rrelyea Should we merge this to 4.1?

@SimonSDA

This comment has been minimized.

Show comment
Hide comment
@SimonSDA

SimonSDA May 24, 2018

This is still an issue. We are converting our monolithic solution to use a more microservices architecture using NuGet packages. When I switch git repositories back to the monolithic versions (which just had project references), the obj folders remain and it messes up Visual Studio until the obj folders are manually deleted.

This is still an issue. We are converting our monolithic solution to use a more microservices architecture using NuGet packages. When I switch git repositories back to the monolithic versions (which just had project references), the obj folders remain and it messes up Visual Studio until the obj folders are manually deleted.

@nkolev92

This comment has been minimized.

Show comment
Hide comment
@nkolev92

nkolev92 May 24, 2018

Member

@SimonSDA That doesn't sound like this issue.

What you're facing is likely dotnet/project-system#3164

The current recommendation is that you delete the obj folder when you do these branch switches.
Git clean is probably the best option.

Member

nkolev92 commented May 24, 2018

@SimonSDA That doesn't sound like this issue.

What you're facing is likely dotnet/project-system#3164

The current recommendation is that you delete the obj folder when you do these branch switches.
Git clean is probably the best option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment