views:

6639

answers:

5

When adding a DLL as a reference to an ASP.Net project, VS2008 adds several files to the bin directory. If the DLL is called foo.dll, VS2008 adds foo.dll.refresh, foo.pdb and foo.xml. I know what foo.dll is :-), why does VS2008 add the other three files? What do those three files do? Can I delete them? Do they need to be added in source control?

+3  A: 

foo.pdb is the debugger symbols file for foo.dll, you'll want it or you won't be able to set a breakpoint in that code.

FlySwat
+11  A: 

The pdb is there for debugging and symbols. If you get an exception thrown from it, you'll be able to get stacktraces, etc. You're in control of choosing whether or not the PDB is built. The xml file is there for XML comments and intellisense. Visual Studio will parse that and display the XML comments that were added when you call methods in those DLLs.

I don't know about the refresh file.

David Mohundro
+2  A: 

VS2008 adds several files to the bin directory [...]Do they need to be added in source control?

Nothing in the bin directory needs to be added to source control. One of the first thing when initially checking in a project is to ignore the bin and obj directories. So yes, you can delete these files, but Visual Studio will recreate them.

OregonGhost
+12  A: 

The refresh file (since no one's hit on that yet!) describes where the DLL came from. This is for auto-refresh references; whenever you do a full build, VS will look in that path and copy that version of the DLL.

Why is this a good thing (sometimes)? Let's say you're in a team environment. Someone checks in code for foo.dll, and your build system builds a new DLL, outputting it in a file share on a server. Your refresh file points to that server copy of the DLL. Next time you build, VS will auto-magically grab the latest and greatest copy of that DLL.

John Rudy
Very cool, didn't know about that. Thanks!
David Mohundro
+14  A: 

Source Control:

Ben Straub said in a comment to this post: The .dll.refresh files should be added to the source control if required, while the .xml, .pdb and of course the .dll files should not be added.

John Rudy explained when to add the .refresh file:

Why is this a good thing (sometimes)? Let's say you're in a team environment. Someone checks in code for foo.dll, and your build system builds a new DLL, outputting it in a file share on a server. Your refresh file points to that server copy of the DLL. Next time you build, VS will auto-magically grab the latest and greatest copy of that DLL.

.xml like David Mohundro said:

The xml file is there for XML comments and intellisense. Visual Studio will parse that and display the XML comments that were added when you call methods in those DLLs.

.pdb like David Mohundro said:

The pdb is there for debugging and symbols. If you get an exception thrown from it, you'll be able to get stacktraces, etc. You're in control of choosing whether or not the PDB is built.

.refresh from a blog post about .refresh files:

It tells VS where to look for updated versions of the dll with the same base name. They're text files, you can open them and see the path it's using.

Their purpose is to prevent you from having to copy new versions yourself. In VS2003, the project file would contain the source location of the reference, but since VS2005 doesn't use project files for ASP.NET projects, this is the replacement for that particular functionality.

xsl
The only thing I'd add is that the *.dll.refresh files *SHOULD* go in source control, unlike anything else in the bin directory.
Ben Straub
Added it to the post.
xsl
Regarding putting .dll.refresh into source control - what happens if the DLL is not on some file server, but stored locally, with each developer having his own copy? I guess that's why John Rudy says "sometimes" :)
OregonGhost
@OregonGhost: Thank you for pointing that out, I changed the post.
xsl