This project is read-only.

Binaries in Trunk?

Dec 1, 2007 at 11:50 PM
I decided to start working on Doppler today. First 2 issues I want to bring up to the team..

bin folder checked in

Why is the bin folder checked into the trunk directory? When you get the files they are now read only and the project fails to build. In general we should not be checking in things that are to be built from source except perhaps to archive official releases. Would anybody object to deleting the Doppler\bin folder from source control?

Binary Dependencies on 3rd Party Components

I noticed that ID3.dll and log4net.dll are also checked in. We need a strategy for dealing with 3rd party components.
  • We need to have the source for the version we are using
  • We need to be able to build the version we are using
  • We need to track the projects we depend on so we can submit bugs, pick up their latest bug fixes and source as necessary


Dec 2, 2007 at 2:54 AM
IMHO it is a bad idea to check in the bin folder, so I am happy for it to be deleted from source control. I would expect to be releasing either an MSI or an EXE and simply tagging the source when an official release is done. I've never been involved in this sort of project before so I am not sure what the standard practice is in this area.

I like the idea of having a Binary Dependencies folder of some sort, that contains all of the compiled references for the project. This keeps them out of the main project folder, yet available for download with the rest of the source code. I was looking at the castle project source folders and they appear to have a SharedLibs folder to keep their dependencies in.
Dec 3, 2007 at 3:16 PM
Agreed - bad idea - we do need to get the source for the version of dependencies we are using as well. We need to consider what happens if the project goes away suddenly and we can't get source for it.