Post-Build / Referece Misuse
-
Hi All, This is a bit of a rant as well as questions. What do you lot make of this? I'm joining a new project with a developer that has been working on his own for ages. He insits that all dlls are referenced from one single network share (with Debug\Release subdirs) and that everyone have a post-build event to dump their dlls in the same location ... This to my mind is utter madness and a dangerous practice ... We'll be constantly overwriting dlls as we debug and impacting the stability of each others debug sessions by potentially picking up buggy dlls every time we are trying to debug our own code ... Urgh!
Jammer My Blog | Article(s)
-
Hi All, This is a bit of a rant as well as questions. What do you lot make of this? I'm joining a new project with a developer that has been working on his own for ages. He insits that all dlls are referenced from one single network share (with Debug\Release subdirs) and that everyone have a post-build event to dump their dlls in the same location ... This to my mind is utter madness and a dangerous practice ... We'll be constantly overwriting dlls as we debug and impacting the stability of each others debug sessions by potentially picking up buggy dlls every time we are trying to debug our own code ... Urgh!
Jammer My Blog | Article(s)
Jammer wrote:
He insits that all dlls are referenced from one single network share (with Debug\Release subdirs)
I don't like to reference network shares from the code. What if network is not available. What if you want to work disconnected from the network? I work quite frequently disconnected from my network. How would I be able to reference them?
Jammer wrote:
and that everyone have a post-build event to dump their dlls in the same location ...
No that is sheer madness. Heck no. If the DLLs don't change regularly, then put them in your source control and get the latest from the source code. If the Dll change regularly, then include the source code (if possible) in your project and build it locally. Refresh your Dll code from source control frequently.
Yusuf Oh didn't you notice, analogous to square roots, they recently introduced rectangular, circular, and diamond roots to determine the size of the corresponding shapes when given the area. Luc Pattyn[^]
-
Jammer wrote:
He insits that all dlls are referenced from one single network share (with Debug\Release subdirs)
I don't like to reference network shares from the code. What if network is not available. What if you want to work disconnected from the network? I work quite frequently disconnected from my network. How would I be able to reference them?
Jammer wrote:
and that everyone have a post-build event to dump their dlls in the same location ...
No that is sheer madness. Heck no. If the DLLs don't change regularly, then put them in your source control and get the latest from the source code. If the Dll change regularly, then include the source code (if possible) in your project and build it locally. Refresh your Dll code from source control frequently.
Yusuf Oh didn't you notice, analogous to square roots, they recently introduced rectangular, circular, and diamond roots to determine the size of the corresponding shapes when given the area. Luc Pattyn[^]
-
Hi All, This is a bit of a rant as well as questions. What do you lot make of this? I'm joining a new project with a developer that has been working on his own for ages. He insits that all dlls are referenced from one single network share (with Debug\Release subdirs) and that everyone have a post-build event to dump their dlls in the same location ... This to my mind is utter madness and a dangerous practice ... We'll be constantly overwriting dlls as we debug and impacting the stability of each others debug sessions by potentially picking up buggy dlls every time we are trying to debug our own code ... Urgh!
Jammer My Blog | Article(s)
-
Does he know what 'version control' means? Or is he just a control freak?
Visit http://www.notreadytogiveup.com/[^] and do something special today.
-
Hi All, This is a bit of a rant as well as questions. What do you lot make of this? I'm joining a new project with a developer that has been working on his own for ages. He insits that all dlls are referenced from one single network share (with Debug\Release subdirs) and that everyone have a post-build event to dump their dlls in the same location ... This to my mind is utter madness and a dangerous practice ... We'll be constantly overwriting dlls as we debug and impacting the stability of each others debug sessions by potentially picking up buggy dlls every time we are trying to debug our own code ... Urgh!
Jammer My Blog | Article(s)
His first project?
Having a bad bug day? Find answers this way... --- Elle A Du Shell --
-
His first project?
Having a bad bug day? Find answers this way... --- Elle A Du Shell --
-
Hi All, This is a bit of a rant as well as questions. What do you lot make of this? I'm joining a new project with a developer that has been working on his own for ages. He insits that all dlls are referenced from one single network share (with Debug\Release subdirs) and that everyone have a post-build event to dump their dlls in the same location ... This to my mind is utter madness and a dangerous practice ... We'll be constantly overwriting dlls as we debug and impacting the stability of each others debug sessions by potentially picking up buggy dlls every time we are trying to debug our own code ... Urgh!
Jammer My Blog | Article(s)
Just create your own personal "DLL mirror" to work with, and then build very very frequently :cool: Seriously, publishing DLLs should be done only from a reproducable, archived build (read: label or archive sources, do a full build of the component(s)).
Don't attribute to stupidity what can be equally well explained by buerocracy.
My latest article | Linkify!| FoldWithUs! | sighist