So far, my experience with dotnet is pretty much what I expected.
I knew I’d have to do a lot of Google searches for tips/insider tricks, existing .net framework bugs, etc.. which is fine.
I knew I’d have to start organizing a Firefox bookmark folder with all of the subtopics like DataBinding, XML, the GC, etc. so that I could have a permanent pointer to stuff I’ve found helpful on the net.
It’s all good, actually. I’d have to say my favorite thing about it, is OO-ness of the whole thing, everything being created from objects.
- I tried to make progress with the small app I’m writing right now, without having to know the Ins and Outs of Dispose, and the difference between Dispose and the Finalizer.
In my App, I have a configuration dialog box, with some tabs on it, and I have a total of three PictureBox’s. I was mistakenly led (by my own ignorant assumptions) that I could just use these objects and not have to worry about disposing of them.
After cross-reference reading through three of my books:
Professional C#,
CLR VIA C#,
Programming .NET Components
….I realized I’ve there’s more to Disposing than I thought, especially if you’re the one designing a custom type that needs to release resources. But as a user of a component or type, it’s not exactly complicated to know that if in the Visual Studio code completion popup window, if you see Dispose, it’s meant to be called.
But I also saw a forum post from a programmer who noticed memory leaks from his PictureBox component, and that he had to set the Image property, to null when he was ready to dispose of it. So now I have an IF statement for all three of mine, which set this property, and then call Dispose(). ( the if is to check if the Image property is null )
I also start using the “Using” syntax, that allows you to not have to the try/finally code, where the .Dispose gets called from the Finally area. This can be used for any object that implements the IDisposable interface.
Unit Testing
I realize this is meant to be a new way to program all in itself.
Write a Test, Make it Pass with your code, and then Refactor. But I’m eager to start writing unit tests for a small C# Windows App I’m writing. However, I’m not sure what tests to write, for this mostly GUI app.
However, I do have a routine that gets called even before the Main Form even shows up, so maybe this qualifies as something to write a test for. It reads an XML file into an ArrayList of objects. But then again, one of the main reasons to use unit tests is to writes test for code that you know you’ll be continually changing, or adding to. As you make each change/improvement, the Unit Tests are there to make sure that the expected output from the functoin(s) stay that way, and you thus didn’t break anything.
For this routine just mentioned, I know I don’t have to do anything else with it. It would be kind of a waste to write a test, given that I’d never need to run that test again in the future, especially when it wouldn’t be a trivial-size testing routine to write:
I’d have to first create a test XML file whose contents are known and never changes. And then, in this test routine, look at each arraylist element to make sure it got populated correctly.
Xml Serialization (and Generics)
This works very nicely. I’m impressed. For the User Configuration Settings that I save permanently on the hard drive, I can literally just save the Config object to an XML file.
An article that helped me with this and gave me the idea: Use XML to store configuration settings
But my config object has an ArrayList, so I had to do some more searching for information on how to do this.
One caveat, is that I had originally implemented this ArrayList as an IList instead, so I could start using the new Generics. However, I quickly found out that the XML Serialization doesn’t (yet) support serializing structures using Generics.
Next
Log4Net is probably my next development tool to get installed.
Logging, in general, was one of the first things as a matter of fact, when I began learning Python, that I made sure to really embrace. I When you’ve got a lot going on, all kinds of structures with all kinds of data behind the scenes, instead of going crazy with the breakpoints and using Watches everywhere, drop that craziness and start logging the activity to a file — pure gold in minimizing debugging time when you’re trying to catch an intermittent bug, especially the data-related bugs!