ASP.Net project bin\dll's and source control

MidnightHawk

I am trying to settle a bet.

I say that one should never check in ASP.Net project DLL's into source control (SVN/SourceSafe) as part of your daily commit, since this is rebuild by Visual Studio in any case. The only exception is when you need to retain a 3rd party DLL that is part of your project, and you do not have the original source.

What is the general consensus?

Colonel Panic

Only if the 3rd party stuff is binary only, as you say. I hate checking out code only to have to dig out dependencies elsewhere. With .Net stuff I try to reduce it down even more by using Nuget to fetch dependencies.

For stuff that has source, I use the subrepository feature of Mercurial. Works with git and svn repositories too.

srsly78

As above, only 3rd party binaries should be committed. And even then this is just to cut down on build time really.

What makes me rage: when full retards check in *.*, which also happens to include the 100+MB visual studio intellisense file -.-

COYW

Third party dlls and nothing more on the dll front.

Daily commits, :eek:, brings me back to my first job where we were obliged to check in before home time, no matter what. The software development manager liked to review our code every morning. Countless hours were lost trying to rollback and remove incomplete code blocks. Shelving just never caught on there!

Giblet

I handle third party through nuget or if I've sourced it elsewhere, I have a folder which stores them all and it is commited.

Here's part of my gitignore

*/bin*
*/obj*
*_ReSharper*
*_TeamCity*
*PublishProfiles*
*.suo
*.user

Never ever commit something that will be rebuilt, CI Server should handle the building and deployment.

srsly78

Giblet you should not have the .user files in your ignore list.

Strangely visual studio keeps some project specific settings in there, like the debug environment setup. You can make this apply to ALL users by renaming the file (remove the specific username, and just have project.user). It is really weird how VS uses this file... This is the case in vs2008, may behave differently in other versions.

Also note to get VS to use the generic .user file you must first delete any specific project.your_username_goes_here file first.

MagicRon

I don't add .user files and I don't believe they should be committed either. They contain settings and configuration specific to 1 developer.
If there are settings that should be available to everyone such as port numbers and whatnot, these should be in the project file, not in the user file.

MagicRon

And there shouldn't be any need to check in the bin dir at all. Third party dlls should be stored in a directory common to all projects and referenced then in the applications that use them. Visual studio will then pull them in when building. That way you won't be committing the same third party dlls in the bin directory of every application.

Giblet

.user is bad because the CI server needs agnostic configs, and if you're depending on user specific settings, then CI won't work. Either it's available for everyone, or not. CI servers usually don't have VS installed.

awec

So long as you can check out a project and build it there and then without having to go hunting for missing dependencies that's the main thing.

Don't check in any of the output of your build.

There is nothing worse than checking something out, trying to build and realising that a third party dll is missing and then spending hours trying to find the specific version of it you need.