From his website: "He holds a B.A. from Dartmouth College and an M.A., in English and American Literature and Language, from Harvard University" He has no scientific training so you should take any commentary he provides on scientific research as just that: the opinions of someone who is unskilled :laugh:

I've now done the same using perfmon and don't see a significant overhead after taking the difference in process memory size. Can you point to more information on this subject?

I just made a rough measure of this empirically: 1 class and 1 method DLL in release mode (4k on disk) vs EXE (5k on disk) 10 classes with 10 methods each in release mode gave DLL (7k on disk) and EXE (8k on disk) So the bloat increases far less than I'd consider to be significant. As for process start and CLR load.... remember we are just loading a library into an existing running CLR.

I was thinking: myProgram.exe -> runs a test suite myProgram.exe /run -> runs a traditional program if implemented or returns if it's a library

Dave Kreskowiak wrote:

Really? How often do you see that and how often are you going to use it?

True, you see it rarely. But it is a useful technique to some, and so might be useful to others. You wouldn't know until you tried it.

Dave Kreskowiak wrote:

Depending on what you mean by "operations", yeah, right. If you're talking about people, there's nothing they can't f*** up and there's always some situation that you're code isn't going to be able to recover from.

Of course, which is why we automate things in the first place but the point is that the deployed binary can run tests on itself 'in situ' rather than a test environment which may or may not be representative of the target production environment.

Or a compiler that bootstraps and tests itself? Or an installable that operations can't fuck up? There are always reasons for questions ;-)

Do you know how much and if so is it a constant amount?

Say, main() by default was required to call a bunch of test suites that executed unit tests. I once worked somewhere where they did this btw.

I wouldn't want to do either and nothing about my question implies I would.

What if you required that they tested and verified themselves?

My thinking was along similar lines i.e. writing small executables that did one thing but did it well a la UNIX. Except I would require that the default behaviour of a main() function was to run a test suite embedded in the assembly.

Whilst prototyping a console app the other day, it stuck me that the dynamically linked library seemed somewhat redundant in .NET and that was nothing I could do with one that could not be achieved by creating an executable. I can add a reference and reuse publically declared types whilst with both. But an executable has some obvious benefits, yet I've always created DLLs because I've been told 'it's best practice' or just followed other's examples. Can anyone think of a technical reason why you'd choose to build a library over an executable? Is a DLL an artefact simply for some legacy backwards compatibility that I'm unaware of? Thoughts?

That reminds me of some work I did with WiX which felt needlessly painful :(

C# is great, VB.NET not so much as I may as well slash £100 a day off my rate. Same for ASP.NET :(

With 10 plus years of software engineering under my belt, I've worked in many companies using a lot of different technologies. Whilst some were a joy to work with, there are some that I never want to see or be associated with again. To that end I tend to not list the following in the hope that no one expects me work with them: Web development (HTML, JavaScript, CSS) Visual Basic 6, VB.NET, VBA or any derivative language SSIS Perl Any in-house developed DSL LabView AutoSys What are yours?

Now I know why all my worst stuff gets nominated and the best stuff ignored :D

Is there a set criteria for inclusion in competition votes or is it based on moderator preference?

Mostly I've been using either efinancialcareers.co.uk or jobserve.co.uk recently, depending on the season I tend to get A LOT of calls and emails from agencies. I've taken to having a specific phone number with a recorded message stating my requirements and asking them to leave me a message if it fits. Those that do, get a call back. On the email side, I direct all job related spam into one email folder where I have a custom extension that bounces a reply with the same message as above and a copy of my cv to any email address listed in the mail. I'm starting to think however, that directly calling companies and making more use of LinkedIn might be a better way to go.

You can do that, but many HR departments have a preferred suppliers list which means they'll only accept applications from agencies :(

On the plus side: Eclipse allows you to browse backwards and forwards between code files more easily than VS. It also auto-compiles when you save. Customising perspectives is something that VS doesn't really do well.