.NET refuses to update due to dual directories?

  • Thread starter Thread starter Beeeeeves
  • Start date Start date
B

Beeeeeves

Why whenever I create a project in c#, when I compile it, it has got the
resulting executable TWICE in TWO different directories - obj\debug and
bin\debug. WHY?
Sometimes when I'm trying to debug it, when I press F5 the one that's
running is obviously not the same one to the one that i've just made changes
to, as it doesn't seem to update my changes. Why does it do this stupid
behaviour?
 
yes, there are two different directories.

When you are running an EXE, it runs from the bin directory. If you want to
make a reference to an assembly (DLL) from another application, you should
reference the copy in the obj directory.

This is because the bin directory contains the EXE and a copy of every dll
you referenced. If you are making a DLL, then copies of the referenced DLLs
are copied in there as well. If you reference a dll from a bin directory,
and other dlls that you reference are also in that bin directory, your app
will use them instead of picking them up from their own directory. As these
are copies of the dlls, you could end up getting the wrong one.

This means you could make a change to a DLL, recompile just the dll you
changed, then switch over to the EXE to debug your change, and you EXE won't
pick up the change, because you referenced another object in the BIN
directory, and it had made a copy of the old dll, and that's what your app
is referencing.

These directories are on purpose. They are important. Don't confuse them.

On the other hand, if you are making a stand-alone exe, with no assemblies
that you wrote, and you are debugging it, I do not believe that it is
possible for the debugger to be placing a breakpoint in the wrong one...
which is how I interpret your complaint.

Not sure what you mean by referring to VS as "stupid."

I hope this helps,
--- Nick
 
When you are running an EXE, it runs from the bin directory. If you want
to
make a reference to an assembly (DLL) from another application, you should
reference the copy in the obj directory.
Click to expand...

OK, thanks - I didn't know this rule!
This is because the bin directory contains the EXE and a copy of every dll
you referenced. If you are making a DLL, then copies of the referenced DLLs
are copied in there as well. If you reference a dll from a bin directory,
and other dlls that you reference are also in that bin directory, your app
will use them instead of picking them up from their own directory. As these
are copies of the dlls, you could end up getting the wrong one.
Click to expand...

So, presumably if you have a DLL project and a main EXE project, then the
DLL project should have its output location set to the 'obj' directory of
the main exe?
This means you could make a change to a DLL, recompile just the dll you
changed, then switch over to the EXE to debug your change, and you EXE won't
pick up the change, because you referenced another object in the BIN
directory, and it had made a copy of the old dll, and that's what your app
is referencing.

These directories are on purpose. They are important. Don't confuse them.

On the other hand, if you are making a stand-alone exe, with no assemblies
that you wrote, and you are debugging it, I do not believe that it is
possible for the debugger to be placing a breakpoint in the wrong one...
which is how I interpret your complaint.
Click to expand...

I'm pretty sure it is still doing this... I have now got no DLLs and one
main EXE.

Not sure what you mean by referring to VS as "stupid."
Click to expand...

I'll do it to those rules and see if it helps. Thanks
 
Back
Top