Bin vs. Obj Folders?

[Mike_R]

I was hoping that someone could explain the difference between the Assemblies found in the /Bin Directory and the /Obj Directory?

 

The /Obj Folder seems pretty clear: It has /Debug and /Release sub-folders and contains the EXE or DLL according to my Build settings. But what Assembly is in the /Bin Directory? It seems to have the same size as the Release version, yet there is a .pdb file present, which would be for a Debug version.

 

I suppose that my best guess is that the /Bin Directory holds whatever build type (Release or Debug) that was most recently built? (And if the most recent build was a Release Build, I guess any .pdb's that are present are not deleted.)

 

But this is pure guesswork on my part; I was hoping that someone could tell me what is going on. Related is: in what way I should be using the /Bin folder (if at all)? That is, I currently Reference the DLL in the /Obj/Debug Folder for Testing & Debugging the project, but DLLs & EXE's that use it are referencing the /Obj/Release version. This makes sense to me, but I'm open to any advice, esp. if or when I should be considering the /Bin version in all this.

 

Thanks in advance! :),

Mike

[IngisKahn]

Actually the bin (binaries) folder is the one you should be using. The obj folder is used to hold temp build files and for debugging purposes.

The bin folder has seperate directories for your build types and generally you want to build .pdb files with your release build in case you have to do any remote debugging.

[Mike_R]

Ingis,

 

I thank you for your comments here, that was a big help.

 

I've now opened up the Alt|ProjectProperties... ConfigurationPropreties|Build... and see that the default Output Path for both the Debug and Release versions is to the /Bin directory. So it seems that the mechanics that I described were 100% correct, but I have to give thought to your advice, that is, that the /Bin directory is the *Real Deal*.

 

What bothers me is that using the default settings, the /Bin directory is constantly being over-written, regardless of which Build (Release or Debug) was used. I suppose I could/should split up the output paths to be /Bin/Release and /Bin/Debug, although I'm not 100% sure of the advantage of that versus directly referencing the /Obj/Release and /Obj/Debug versions. I know you told me that they are "Temp" files, of sorts, but if they are written every time, then I don't see the harm?

 

Maybe I'm making this overly complicated, but what I like to do is to debug a new feature in the DLL before compiling as a Release Build. So I have a Solution that includes a Testing EXE that references the Debug version of the DLL. All other *real client EXE's* access the Release version. The *real clients* won't witness any change until enough testing has been done to consider the new feature fully tested, at which time I compile to a Release Build. But, if instead, the /Bin folder's DLL version is being overwritten during the debugging process (which seems to be the default setting), then referencing that version could result iin my temporarily corrupting EXE's trying to use the DLL before it is fully tested.

 

So, do you guys think I should create separate folders within the /Bin directory, that is, /Bin/Debug and /Bin/Release, or should I simply directly reference the EXE's within the /Obj/Debug and /Obj/Release directories (which is what I currently do). Or none of the above, because maybe I'm looking at this all wrong?

[IngisKahn]

It's very strange, to me at least, that both debug and release are getting built in the same directory. That is not the deafult setting forn any version of VS (2k1, 2k3, or 2k5x). They should be going to bin\Release and bin\Debug.

[Mike_R]

Ok, playing around, I have been able to prove that what you are telling me is true: Using the /Obj/Release and /Obj/Debug/ folders is flawed. The problem I hit is that these folders are what you say: temp folders. The key aspect they lack is that they do not copy-in any dependency DLL's, so if I have a cascading chain of A.EXE refereces B.DLL which references C.DLL, then the chain will break, because the B.DLL within the /Obj/Release/ and /Obj/Debug/ folders will not contain copies of the C.DLL. The DLL's within the /Bin folder, however will.

 

So I did decide to split up the Build locations to create /Bin/Debug and /Bin/Release/ manually by going into Alt|ProjectProperties... And it works great. :) I could not find any option within Alt|Tools|Options..., however, to make this the default/automatic setting though. :(

 

But now seeing your reply, I guess it should be automatic!? I certainly wish it were! Ok, kicking this around some more...

 

... OMG, I don't believe it: For C# it defaults exactly as you describe. For VB.Net, they both have the same default location: "/Bin". How friggin' dumb is that?

 

As if the C# community needs yet another reason to stay away from VB.Net, lol. Seems to be the same setup in the VB.Net 2k5 beta version as well... unbelievable.

 

Ok, well, I thank you very much for your help. It seems that much time and effort was wasted because MSFT was being dumb. I guess I can make a template to handle this automatically in the future, as I don't see a global setting for this.

 

Thanks again :)

[IngisKahn]

... OMG' date=' I don't believe it: For C# it defaults exactly as you describe. For VB.Net, they both have the same default location: "/Bin". How friggin' dumb is that?[/quote']

 

Wow, that is dumb. I guess they figure all that debug/release stuff would scare away VBers.

[Mike_R]

Yeah, this really is bad. This might be the only issue though that I know of where the VB.Net setup is worse-off than the C# setup. The VS 2003 C# IDE is just awful, I don't know how you guys can stand it. The 2005 Beta however is vastly improved, pfew. :) I might even switch when it comes out...

 

Thanks again for your help,

Mike