Entity Framework will hit with VS2008 SP1

Finally its coming! With Visual Studio SP1, the final version of entity framework will be included.
I'm expecting the .NET 3.5 certification exam to go live shortly after, finally!

70-504 passed

Lets hope MS get that ADO .NET 3.5 done soon otherwise i'll have to do WPF!

Grab that icon with .NET

Many people just dont know there's a very easy way to get any program icon you need.
Here's the code
Icon icon = Icon.ExtractAssociatedIcon(@"C:\Program Files\Internet Explorer\iexplore.exe");
using (FileStream fs = new FileStream(@"c:\explorer.ico", FileMode.Create))
{
icon.Save(fs);
}

Embedded resources and clean folder structure - yes you can.

If you have a bunch of embedded resources in a folder, the single most efficient way to get a stream to them is to create a dummy class in that folder. Aside from it being internal or public, it doesn't have to do a thing.
You then use the type of this object in calls to get this resource, eg Assembly.GetManifestResourceStream. With this type, the namespace is looked up for the folder, and the embedded items in it are effortlessly resolved.
eg:
Assembly.GetExecutingAssembly().GetManifestResourceStream(typeof(ImageResourceResolver), "myicon.ico");

//You do not need to understand this

Maintenance programming... hated by most, yet essential.

Good things to do for the poor sod who has to maintain your code after you left:

• Comment clearly and not too much
• Put in a clear roundup what the function is supposed to do
• ... add some explanation for your parameters
• Keep speaking variablenames, but go easy on the length :)
• Be consistent in these names.. p preceeds a pointer, s a string, i an integer and so on
• Avoid pressing complicated statements into one line

Bad things to do:

• Ignore all of the above
• i is good, use often like nested for{} statements with i for the outer loop and ii for the next :)
• Take extremely good care of your pointers and never set them to NULL when you free()
• Place comments like //Taking care of X... when you do nothing the like

heheeh.... maintenance programming has its ups and downs. But you can make it hell if you like. If you happen to hop into a job where you get thrown at code that looks like the latter... I do not envy you :)

Electronic flyswatter: The Art of Debugging

Among the less popular things about programming in general is debugging. It is a hassle to most people I know, yet an essential skill to master.

The first step to find a bug is to think while coding. Hacking away without reason and just grinding code without exercising your brainmuscles is futile. Believe me when I say that a well thought through codeflow is saving you quite some headaches in debugging.

Before you start coding make yourself a clear picture of what you want, how it should look and how it should flow. Expect that to be hard :)
Do whatever helps you, don't rely on what others tell you too much, as there is no perfect way. Use what works for you.. diagrams, UML or Post-It notes. It saves you time and gives you an overview of the program-to-be.

Step two is translating that into code. Here I mostly choose to have my own collection of ironcode. WTF? 'Ironcode' is code I use all the time, well tested and throught through (...ehhehe... in most cases well though through). It minimizes the possibility of errors... most of the time :)
KISS. Keep It Simple Stupid. Don't optimize too much. It is easier to get a working program to run fast than a fast program to run.

Avoid one-liners in the first iteration. I love oneliners like:
string ASCII = Encoding.ASCII.GetString(Encoding.ASCII.GetBytes(srLogFile.ReadLine()));
While it surely is not the most complicated thingy to do, it is surely stupid to do that untested. Try, for debugging, to split that into three or more lines. It is easier to debug (yes, and to read, I hear you, but maintenance programming is another topic).
When your code is ready to be shooed out of the sandbox, you can always tighten up things.

Step three is 'Know your tools'. Know your tools. Know how the debugger works, when to hit which key and watch your locals. Locals is your friend, the callstack tells you quite a lot about what happened before you crash.. or did not crash.. also a possibility in a multithreaded environment.
Speaking of which.. create a decent logger that is alive in your debug build. In most of the cases you cannot just 'stop, drop and roll' your program, e.g. Games. There a good logger is making your live a lot easier.

Step four is 'know the 'usual suspects''. I, when programming, have a list in my mind of those things that can go wrong. I build and test every function I create for obvious errors then stuff in a few lines of loggingcode to be prepared.

And the last, most important, step: 'Don't give up'!
See it this way: At least you have the sourcecode, you know the one who committed the cirme and you know all the things that sourround your program. The worst thing that can happen to you is reverseengineering buggy code with not the slightest idea what that program needs... believe me.. been there, done that, got the T-Shirt.

All in all this is not the yellow brick road to follow in debugging. Never thought of it that way, but it should take away the highest hurdles. Of course it is easy to say such things while having quite a bit of experience in that field. As always. But then... I also started sometime... heheeh... most people forget that...

Division by Cucumber?

Today I let loose my latest thingy, which reads some logs and parses them into a FoxPro table. See my post on it here.

It was working fine while in the sandbox but screamed hell when I set it loose in the wild. It threw a 'DivideByZeroException' all the time. After a while of debugging and crawling through my code I ended up here:

1. System.Data.OleDb.OleDbCommand Com = new System.Data.OleDb.OleDbCommand(Instrucions[i]);
2. Com.Connection = conn;
3. Com.ExecuteNonQuery();

Line 3 threw the exception... but why? The instruction looked like 'insert into tablename (Col1, Col2, Col3) values ('One','Two','Three other things added here')'.
Thing was that the first round with another table went fine and that SQLstatement was a lot more complicated! So... what gives?

Took me about 2 hours of fiddling, cursing and sniffing through my code I found out the cause:
'Col3' is a FoxPro Memofield... sheesh.. which creates the need for the corresponding 'tablename.FPT' in the directory where the free tables reside. After that it worked like a charm.

So... all the crap in the web about some complicated parameteradding and such is safely discarded. The only thing is that you should chop your strings that should go into the memofield into 255 charater pieces as FoxPro works with stringlaterals that hold 255 chars max :)

Hope I could push you a step further to enlightenment :)