-1

I have seen answers to similar questions but I still don't understand this... I have scripts that place all dependencies into a common BIN directory, which is outside all the projects directories.

  • solution.snl
  • BIN
  • ProjectAFolder
  • ProjectBFolder

All projects reference everything from BIN and they build into BIN. This way builds are faster and SO MUCH CONFUSION is avoided, among many-many other benefits. But why the heck VS removes some unreferenced files from bin?! I have a ThirdParty.dll that references other files (so dlls have to be in the same folder with ThirdParty.dll). When I rebuild these other files are deleted! What a bright idea! Or is it a bug?

My build complains like so if I make the files read only: 43>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3969,5): warning MSB3061: Unable to delete file "C:\Projects\GITBranches\trunk1\EDA\bin\tibrv.dll". Access to the path 'C:\Projects\GITBranches\trunk1\EDA\bin\tibrv.dll' is denied.

and this is the line in Microsoft.Common.targets that tries to do this:

<!-- Delete the orphaned files. -->
<Delete
    Files="@(_CleanOrphanFileWritesInIntermediate);@(_CleanOrphanFileWritesInOutput)"
    TreatErrorsAsWarnings="true">

  <Output TaskParameter="DeletedFiles" ItemName="_CleanOrphanFilesDeleted"/>

</Delete>

Does anyone know how I can win?

Thank you

AlexeiOst
  • 574
  • 4
  • 13

2 Answers2

0

I think your best bet is to have third party files stored in a separate directory, e.g. A Lib directory.

Then you can copy them to your bin directory as part of a pre build event perhaps?

samjudson
  • 56,243
  • 7
  • 59
  • 69
  • Marked this as an answer cause eventually this is what I did with slight modification: place the artifacts into a sub-directory of the BIN folder and then in pre-build action copy that into BIN. I like the idea of removing BIN completely in CI. Not a principal difference though. I also was hoping for some option in VS... Thank you. – AlexeiOst Apr 28 '15 at 22:26
0

This is your problem:

"All projects reference everything from BIN and they build into BIN. "

This idea of how to do your build should be consigned to the "it was a good idea at the time and might have worked for another build platform but it's not so good now" category.

Previous comments/answers are somewhat correct - you shouldn't store resource or dependency type files in the folder that is the target for your build - the first thing MSBuild does is to clean out the target folder ready to receive the results of the build.

Dependent files can be stored anywhere else you like. You can add them to the project as a link1, then set their Build Action to Content and the Copy to Output Directory to Copy Always or Copy if newer.

1 Add -> Existing Item, browse and select the dependent file, then drop down the Add button and choose Add as link

slugster
  • 49,403
  • 14
  • 95
  • 145
  • "it was a good idea at the time and might have worked for another build platform but it's not so good now" - this is because someone unwittingly decided to delete things that do not "belong to him"? Sounds like an elephant in a china store. Besides, as I said, there are numerous benefits to this approach. I remember those days when "old" copies of things left around would cause VS do strange things, causing me pull my hair out. These problems are mostly gone with this approach (except for today :) ). Thanks for the answer, though. – AlexeiOst Apr 28 '15 at 22:20
  • Nope, it's because that is the way MSBuild and TFSBuild have always worked - $(TARGETDIR) gets cleaned before it receives anything. You are taking a somewhat antiquated approach. If you've got external scripts as part of your build you can possibly do without those too - VS can execute pre and post build commands (you could shell to your current scripts from there). Additionally you can override various stages of MSBuild by adding your own targets to your proj files. – slugster Apr 28 '15 at 22:57