baseclass / Contrib.Nuget

Extending nuget with nuget packages
MIT License
30 stars 21 forks source link

Clean gets slowed down, when many files exist in bin\debug #58

Open StarWars999123 opened 5 years ago

StarWars999123 commented 5 years ago

Hello,

we have a visual studio project, consisting of many different assemblies (>30) together with some binary files. The assemblies are normal nuget packages or referenced projects. However, the approx. 50 binary files get loaded from a nuget packet and get copied via Nuget Output (version 2.3.0) into our bin\debug directory. Furthermore we have thousands of log files within that folder that get created, when running/debugging the visual studio project.

Whenever we clean now out project, nuget output tries to remove all files it copied before. Thereby it seams that it can not find the *.dummy files. As a result it seams like VS is searching through the whole \bin\debug directory. So it searches for every single binary file added by Nuget.Output through thousands of files/folders. It sums up to about 15 seconds for every project that contains this many log files together with a package referencing NugetOutput.

I suspect, this might be related to the following line: https://github.com/baseclass/Contrib.Nuget/blob/2c31239aa473b9c17745fcb5ed9c8d6afbdf0d1b/Baseclass.Contrib.Nuget.Output/build/net40/Baseclass.Contrib.Nuget.Output.targets#L30

Do you know any kind of fix, or do you have a better solution? Do you really need to iterate over every file within bin\debug?

Thank you in advance!

Edit: The build jobs 'Clean' theirby shows on highest log level the following Output (for every nuget-output binary):

46>Building target "CleanEmptyFolder" completely.
46>Output file "....MyBinary1.bin.Dummy" does not exist. 
46>Task "RemoveDir" skipped, due to false condition; ('@(EmptyCheck)' == ''' AND '%(NugetOutputFiles.RecursiveDir)'!='') was evealuated as ('bin\debug\file1.abc;bin\debug\LogFolder1\log\Today\Afternoon\theLogFile.txt; [... I shortened the >1.000.000 char long line here...]')