NuGet / Home

Repo for NuGet Client issues
Other
1.49k stars 250 forks source link

NuGet & TFS (TFS14092 - Pending Delete) on Update-Package -reinstall #1401

Open aosgo opened 8 years ago

aosgo commented 8 years ago

When doing a Update-Package -reinstall

e.g. Update-Package -reinstall angularjs

TFS throws TFS14092 for each file that is under source control e.g. scripts, images etc.

yishaigalatzer commented 8 years ago

Can you provide a bit more feedback?

What version of NuGet are you using? What version of Visual Studio are you using? What version of TFS? Is it an offline or online scenario? Is it an offline worskspace?

How did you set up your project?

aosgo commented 8 years ago

VS2013 Update 4, NuGet 2.8.5 & TFS 2012. We use Local Workspaces and TFS is online.

yishaigalatzer commented 8 years ago

Looks very much like - http://nuget.codeplex.com/workitem/4037

yishaigalatzer commented 8 years ago

@zhili1208 can you please look into this (both in 2.9 and 3.2)

zhili1208 commented 8 years ago

will look at this

aosgo commented 8 years ago

Hi, http://nuget.codeplex.com/workitem/1690 and http://nuget.codeplex.com/workitem/4037 mention the same issues.

revel8n commented 8 years ago

Is there any update on this issue?

Since issues are move to github, and the corresponding issues from codeplex do not seem to be here currently, i am assuming this is the current standing of the investigation into this.

This is a very inconvenient error to have. It appears that since the source control monitoring of Visual Studio is active during nuget installs it is detecting the file removals, even though they are temporary, and setting them as pending changes.

it is essentially a race condition between how fast the nuget package installer can make file changes before the source control monitoring update check occurs in the background.

Fixing this would be very helpful.

Thanks in advance.

yishaigalatzer commented 8 years ago

We are currently investing in nuget 3.x in visual studio 2015, and don't expect to touch this in 2013 in the near future.

What version are you using?

revel8n commented 8 years ago

i have VS2012, VS2013 and VS2015 installed (as well as 2008 and 2010; blame VS's c-runtime, build tools, debug dll and legacy sdk dependencies...).

We have not fully migrated company wide from 2013 to 2015 yet, though that is in the works. So i technically use nuget in both 2013 and 2015 at the moment.

yishaigalatzer commented 8 years ago

Are you experiencing the same issue in 2015 (with the latest nuget which is 3.4.2 at the moment)

revel8n commented 8 years ago

i have version 3.4.2.830 installed. Well i see a different symptom of the issue now.

In 2015 it no longer outputs the error message that was present before, and it looks like it may have been able to copy the files, but the file are still marked as Pending Deletes.

As such undoing the Pending Changes replaces the files with those from the server again. So technically the package is installed but the dependent files must be updated manually after the fact once the Pending changes are resolved.

yishaigalatzer commented 8 years ago

Thanks, thats concerning, can you share what Version of tfs are you using (they all behave a bit differently).

revel8n commented 8 years ago

TFS 2015 Version 14.0.24712.0

rohit21agrawal commented 8 years ago

@aosgo @revel8n This seems to be fixed in Nuget 2.8.60723.765 and VS 2013 Update 5. If you are still seeing the issue, please attach a repro project if possible.

zhili1208 commented 8 years ago

checked with 3.4.3.885 in vs2015 update2, can't repro this issue

rohit21agrawal commented 8 years ago

Closing this bug due to no response, and no repros.

However, please feel free to reactive this issue if you hit this problem again

revel8n commented 8 years ago

Sorry, i have been busy at work. i definitely still see this issue with the latest builds. Unfortunately the project i am seeing it on is company related, so i cannot release it. i will attempt to recreate the issue with another project.

i guess i could also ask: What is the correct way to associate dependent files with a nuget package? Dependent files being things like extra dlls that are not referenced directly by the project, xml template/configuration files that are editable by the user thus cannot be placed as internal resources of the assembly, etc. (That also need to be copied to the build directory, etc.)

This could just boil down to our nuget packages simply not being created properly in a manner that is good for the current update process.

Does having multiple instances of Visual Studio open affect this? Does a slow connection to the nuget server affect this? (The packages are on our own remote nuget server)

i will run through a few of these scenarios and see what my findings are on our end. Our current project schedule is a bit hectic, so i apologize again for the delay.

rohit21agrawal commented 8 years ago

Reopening the issue. @revel8n thanks for your feedback. Multiple instances of Visual Studio or a slow connection to nuget server shouldn't affect this. If you find this to be the cause at your end, we would definitely want to fix the scenario.

In the meanwhile, could you tell us the exact versions of Nuget, VS and TFS that you are using? Would also help to provide some steps (doesn't matter what package it is).

Adding @rrelyea @yishaigalatzer to answer your questions on associating dependent files with a nuget package.

revel8n commented 8 years ago

VS2015 Update 2 14.0.25123.00 Nuget Package Manager 3.4.3.855 VS2013 Update 5 12.0.40629.00 Nuget Package Manager 2.8.60723.765 TFS 2015 Version 14.0.24712.0

Current testing shows that this may be related to interactions between when files are removed from the project and the file system and when they are added back.

If i delete the offending directories beforehand (in the file system, not from source control) and run the package update it appears to work fine. But would need to do more testing to confirm that is always the case, and not just a one off success. Also in this case the files in the content directory had not changed between packages, so i am not sure if when it added them back it would have picked up any differences had there been any.

i guess i should also clarify, just in case, since my original question as to whether this was the extension of the related codeplex issue was not technically responded to, to make sure we are all on the same page. https://nuget.codeplex.com/workitem/4037 That was the original item i was referring to, so if that is not similar enough to this one, that could be one thing causing confusion.

This mainly appears to be with additional files included in a nuget package content directory. There appear to be attempts during uninstall to remove the files from source control and the file system based on the Package Manager output in VS. i cannot tell whether the files still being present are from a failed deletion during uninstall or a successful copying during the install of the new package afterwards. But something is causing TFS to register the deletes before it can complete the process, then TFS has issues when adding/registering them again (for whatever reason source control does not support overwriting existing files on disk when reverting pending changes since it thinks they may be locally important i suppose).

rohit21agrawal commented 8 years ago

@revel8n Thanks for providing the details. It seems like @zhili1208 has been able to identify the issue at hand, and we are working to fix this for both 3.x and 2.x clients.

Will keep you updated!

zhili1208 commented 8 years ago

@revel8n I might found the issue, the issue is during uninstallation, nuget will call TFS pending delete to make all files into Pending delete status and remove all files from disk. then during installation, nuget will get the package from source, extract it and put all files on disk, then try to get all pending changes on those files and undo them before making all files into pending add status. But during undo pending delete, TFS will bring back all old files from TFS server and try to put them on disk, Now there already exist same files on same path, then TFS got error.

revel8n commented 8 years ago

Yes, that is about what i was thinking as well after i did a bit of looking through the source code.

It appears that Pending Deletes will be skipped if the file does not exist in the file system (FileSystem.DeleteFile), which could be why everything worked when i deleted the files before trying to update.

i am not sure if that is proper in all cases as it would mean if the files just happened to not be there already locally for whatever reason, removing the package without reinstalling it could leave the files in source control (if i am understanding the order of operations correctly).

While searching i came across other projects (git-tfs) that had to interact with source control that also experienced similar issues in the past. From their code it appears they made sure to get the current file from source control, before issuing the pending change to make sure the current file system was up to date.

But glad to see at least the initial cause has been found.

Hoplo commented 7 years ago

Hi, We are having the same issue and its causing a major headache at the moment. Is there any update or an ETA on a fix for the issue?

We are using: VS 2015 Update 3 (14.0.25431.01) NuGet Package Manager (3.5.0.1484)

Also see the same issue in VS 2012 and Nuget 2.8.

Thanks,

Adrian

rohit21agrawal commented 7 years ago

@zhili1208 did the fix for this go into 3.5?

jensotto commented 7 years ago

We also have the same issue:

Visual Studio 2015 Update 3 (14.0.25431.01) TFS 2015 Update 2.1 (14.95.25229.0) NuGet Package Manager (3.5.0.1484)

kpanshin commented 7 years ago

I also have the same issue Visual Studio 2015 Update 3 (14.0.25431.01) TFS 2012 Version 11.0.60610.1 NuGet Package Manager (3.4.4)

Hoplo commented 7 years ago

Hi @rohit21agrawal & @zhili1208 ,

Is there any update on this issue?

Cheers, Adrian

zhili1208 commented 7 years ago

@Hoplo the fix is not into 3.5, let me put it into our next milestone

johannes-schmitt commented 7 years ago

I'm facing the same issue while updating a NuGet package that contains source code transformations. The transformed source code will be in the subfolder _cs\any\some_othersubfolder

In this update scenario it first deletes the directory _cs\any\some_othersubfolder from the old package (this leads to a pending delete on TFS) and then it tries to install the (newer) package into the same folder again. But because of the pending delete, this won't work.

See screenshot for how the folder structure looks like (don't know if this helps...) capture

zhili1208 commented 7 years ago

@johannes-schmitt Can you share your TFS server Version? thanks

johannes-schmitt commented 7 years ago

@zhili1208 , I updated my previous comment accordingly

Hoplo commented 7 years ago

@zhili1208 do you have a rough ETA for the next milestone? If its awhile off is there any chance of it being included in a 3.5 patch?

This is a major headache for my development team as we have multiple updates of large NuGet packages multiple times in a day and at the moment the dev's need to manually re-add large numbers of files to TFS after each update causing them to waste a lot of time.

Thanks, Adrian

zhili1208 commented 7 years ago

@Hoplo I will try to land this as soon as possible, it will be in 4.0, can you share more detail about your scenario? what's your package structure and how you update it? I can try to find a workaround for you.

Hoplo commented 7 years ago

@zhili1208 Sorry was away last week and didn't get a chance to reply.

We have several custom packages that are causing this issue at the moment. One is used in class library projects and is very simplistic. The others are used in web application projects and contain lots of files.

The simple one has 3 sub-folders in the contents folder of the package each of which has a single file in them (In this case all 3 files are called Usage.md). The root of the content folder also contains 6 files (all .bat files). When a package update is complete the root files and sub folder files will be deleted from TFS instead of updated. this only happens when the files are changed from the previous package version. the sub-folders within the project normally contain additional file specific to the project. The package also contains a lib folder which is handled correctly.

The larger packages contain about 10-25 files in various sub-folders of the content folder along with lib files. These normally have the same files deleted rather then replaced in TFS even when the files have not changed.

In both cases it is also quite common in VS 2015 for the old versions package folder to not be removed form TFS leaving duplicate packages.

If you have any work arounds or suggestions then they will be most welcome.

Thanks, Adrian

zhili1208 commented 7 years ago

@Hoplo Can you try to do following steps for update?

  1. uninstall the previous package.
  2. checked in all delete changes to TFS.
  3. install the new version package.
  4. checked in all add changes to TFS.
upnxt commented 7 years ago

@zhili1208, I have the same issue as other have stated in this thread. The steps you provided is what we have to do, or alternatively this also works:

  1. update the package
  2. check in the wrongfully deleted project changes
  3. promote the "detected files added" changes
  4. check in the promoted files
JohnBergman commented 6 years ago

Any progress on including this in a build soon?

callmeocean commented 6 years ago

Guys, any updates on this one?

I'm having the same issue and it makes content nuget packages useless.

dee-see commented 6 years ago

Same problem VS 15.5.2 Nuget 4.5.0 TFS 15.112.26301.0

TiltonJH commented 6 years ago

I have the same issue.

Updating/Reinstalling an already installed package which contain any content files besides the assemblies is a nightmare with TFVC. (VS 2015.3 NuGetExt 3.6.0.2511 TFS 2017.3)

So far I have found only one workaround. Before updating/reinstalling one needs to remove the VS-project association to the TFVC and re-associate to it when done. To do this one needs remove the `SAK

SAK
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>` entries from the csproj-file and insert them back when done. So now the files get changed but not deleted (as far as the TFVC is concerned).

One has to make sure to handle all changes to the TFVC manually, but this is still easier than the current alternative. (IMHO)

Might NOT WORK WELL with "Server"-workspaces, since each file is marked as "read-only". (I did not yet try that.)