Suppose that you write code without tests that compile. Suppose that those parts do not have any user interface or tests. Then what you’re doing is actually pushing development cost over to other parts of the project that make use of the code. This will probably mean that any cost/time estimates concerning dependent code needs to be adjusted in order to be able to pay for the additional cost.

Suppose that you write code without tests that compile. Suppose that those parts do not have any user interface or tests. Then what you’re doing is actually pushing development cost over to other parts of the project that make use of the code. This will probably mean that any cost/time estimates concerning dependent code needs to be adjusted in order to be able to pay for the additional cost.

On a 64 bit environment it's very important to make sure that all your projects have the same platform target. When creating console applications, the default is x86, that means that it's easy to get something that give you weird errors.

NDesk Options I started writing an argument parser without knowing about: NDesk.Options Where you have the following kind of syntax: string data = null; bool help = false; int verbose = 0; var p = new OptionSet () { { "file=", v => data = v }, { "v|verbose", v => { ++verbose } }, { "h|?|help", v => help = v != null }, }; List extra = p.Parse (args); FubuCore Since this post, there is a new option: Command line in FubuCore. Powershell If you’re using powershell it j[...]

NDesk Options I started writing an argument parser without knowing about:NDesk.Options Where you have the following kind of syntax:string data = null; bool help = false; int verbose = 0; var p = new OptionSet () { { "file=", v => data = v }, { "v|verbose", v => { ++verbose } }, { "h|?|help", v => help = v != null }, }; List extra = p.Parse (args); FubuCore Since this post, there is a new option: Command line in FubuCore.PowershellIf you're using powershell it just mig[...]