ansaurus

Question

How can I prevent Visual Studio 2005's "Clean" command from removing 3rd party binaries?

Answer 1

+1 A:

I believe that if you put these files in a subdirectory other than bin, Visual Studio won't remove them. You can still make the new subdirectory part of your deployment.

Robert Harvey 2010-02-23 02:52:47

Answer 2

+4 A:

Put the dlls in a different directory. You will probably not want them as part of the project. Reference the dlls from the new directory. When you compile the dlls will be copied to the bin directory.

I work with lots of projects and keep a bin directory at the root of my projects to store 3rd party dlls for exactly this reason.

Example directory structure:

MyProjects
 - bin
   - 3rdParty.dll
 - Project1
 - Project2
 - ProjectN

This allows all the projects to have a well-known reference location for 3rd party dlls without having to copy the dll into each project.

If you are working on a team you should all agree on a standard directory structure for your code. This will save you lots of headaches beyond just this.

Brian 2010-02-23 03:43:01

Yes, this would work great if these DLLs were actually referenced by my project and I wasn't working on an ASP.NET application.

Bryan 2010-02-23 20:53:05

Answer 3

+2 A:

In case of Sitecore, just make sure to set the property of the reference(Sitecore.Kernel, Sitecore.Client, etc): 'Copy Local' = false.

Alex de Groot 2010-02-23 09:00:19

This good sir is your answer, Sitecore docs and training call this out.

techphoria414 2010-03-02 08:31:35

Answer 4

+5 A:

The correct answer to your problem will depend on how you are referencing the assemblies and how you include them in your project output.

The bin and obj folders generated by a project are best considered "output" folders; these folders should only contain files produced by the project build.

When you perform a clean or rebuild of a project, all intermediary and compiled files are deleted from these folders.

You should be comfortable this is happening.

You should be able to restore these folders by running the build process at any time. If you have added files to these folders directly, it breaks the purpose of these folders and means you ought to rethink how you're adding those files.

The preferred way to reference compiled assemblies is to add them somewhere inside your source folders. From there, they can be added to a source control system as easily as any other file and can be referenced/copied by projects which depend on them. In my work, we have a "Libraries" folder which contains numerous third-party assemblies referenced by multiple projects in our solution hierarchy.

Try using a source tree like this and seeing if it works for you:

/Projects/My Solution/
/Projects/My Solution/Libraries/
/Projects/My Solution/Project A/
/Projects/My Solution/Project B/

Programming Hero 2010-02-23 11:42:37

Hero... your answer makes sense on the surface... at least, it's possibly how Visual Studio *should* behave. But it's clearly not, as the clean/rebuild leaves plenty of other DLLs in the bin dir that are not built or referenced by my project. My project is set up like Sitecore recommends.

Bryan 2010-02-23 20:50:38

If you manually delete the `bin` directory and perform a Rebuild, what's the outcome?

Programming Hero 2010-02-23 21:36:09

Disaster. Sitecore recommends that your project root be the root of the website... where it has installed many DLLs into the \bin directory. Deleting the bin dir would remove all of these and destroy your web app.

Bryan 2010-02-24 00:21:36

I've come to realize that the default Sitecore project set up is just broken. You are right, I should be able to delete the whole bin dir and rebuild from scratch.

Bryan 2010-04-23 21:14:10

Answer 5

+1 A:

We always add an AfterBuild event to the project file containing Sitecore.

<Target Name="AfterBuild">
    <CreateItem Include="$(SolutionDir)\Third Party\Sitecore\*.*">
      <Output TaskParameter="Include" ItemName="FilesToArchive" />
    </CreateItem>
    <Copy SourceFiles="@(FilesToArchive)" DestinationFolder="$(TargetDir)\%(FilesToArchive.RecursiveDir)" />
  </Target>

Where the CreateItem Include is the path to where you have placed your Sitecore binaries.

pbering 2010-02-23 11:44:39

+1 For prudent use of msbuild. You might want to add some detail on where to put this piece of configuration though :)

Jørn Schou-Rode 2010-03-22 21:01:32

Answer 6

A:

Well, I'm going to go ahead and answer my own question, since it seems like the simplest answer so far. I marked the assemblies in question as Read-only. Now they don't get cleaned.

Still wondering why most of the others don't get deleted.

Bryan 2010-02-24 00:37:39

ansaurus

tags:

views:

answers:

How can I prevent Visual Studio 2005's "Clean" command from removing 3rd party binaries?

related questions