Plunging into .NET Development

Weblog Pieter Gheysens
Microsoft .NET Development - C# - Enterprise Library - Visual Studio 2005 Team System - Compuware DevPartner - ...

Monday, August 29

Unsecure Wireless Networks

Many people nowadays buy a wireless router and install it at home without thinking about the security-settings. Hey, it works, so?!

Last week I was in Antwerp (Belgium) where my girlfriend has a little apartment and I was surprised to see that there were so many wireless networks in the neighborhood. Two out of 6 were unsecure and I could easily connect to them, get a valid IP-address, surf the web, ...

Shouldn't the manufacturers of those wireless routers pay more attention towards security? There will always be people who won't see the benefit of a secure network. Shouldn't they be protected against themselves? In my opinion security should be enabled by default.

Secure your Wireless Network
  • Change default name of your network (SSID)
  • Turn off SSID broadcasting
  • Block unknown devices (MAC-address restriction)
  • Enable WEP (Wired Equivalent Privacy)
No matter how secure we make our (wireless) network today, there will always be somebody who figures out some day how to break it but this does not mean that we should make it easy for an intruder to break into our system/network.

Saturday, August 27

Responsive User Interface

Everyone has probably experienced it already : client applications that freeze after starting a particular operation of an application. Control is only given back to the user interface after the operation has done its work. Very frustrating indeed!

When developing an user-interface for a client applications, you should always prevent that the main thread of your application executes long-running tasks. The main thread is responsible for starting up the application and does control the user interface from start to finish. That's why it's often called the main UI thread and blocking it means serious trouble.

A small example : a Windows Form application that displays the date and time of the day. The time is each second updated with a Timer-conrol. When clicking the Start-button an operation is started that takes 5 seconds. If you code this in a single-threaded application, you will notice that the time won't be updated on the form for 5 seconds. After the operation has finished, the main thread will be able again to update the date and time. Conclusion : not good! Don't slow down the user interface or your users will freak out.

The non UI-operation of 5 seconds should be seen as a background operation and should therefore be placed on a separate thread (multi-threading). In that way, the main UI thread won't be blocked and the time can still be updated on the form during the operation.

The easiest way to run code on a separate thread is to use asynchronous delegate invocation. I won't dig deeper into what delegates precisely are - but it's ok for now to say that delegates enable you to call/invoke other methods. To invoke a delegate asynchronously (delegates are usually invoked synchronously), you should call the BeginInvoke method. This will queue the method to be run on a thread from the system thread pool. The main thread will return immediately without waiting for the method to finish.

      private void doWork()




            if (System.Threading.Thread.CurrentThread.Name == null)


               //Give BackgroundThread a name

               System.Threading.Thread.CurrentThread.Name = "WorkerThread";



            //Sleep for 5 seconds

            Console.WriteLine(System.Threading.Thread.CurrentThread.Name + " will sleep for 5 seconds.");



            MessageBox.Show("Work is done !");


         catch (Exception ex)





For this example it was maybe better to use the MethodInvoker Delegate because MethodInvoker provides a simple delegate that is used to invoke a method with a void parameter list (see doWork-method) but it works the same way.

         MethodInvoker methodInvoker = new MethodInvoker(this.doWork);

         methodInvoker.BeginInvoke(null, null);

It's also a good practice to give your threads a name. I gave the main thread the name "Main UI Thread" and the worker thread the name "Worker Thread" (straightforward isn't it) ...

         System.Threading.Thread.CurrentThread.Name = "Main UI Thread";

Doing this means that you can check the thread [Threads Window] you're dealing with while debugging.

So now the main UI thread won't be blocked and the actual processing is done on the background/worker thread. That's what we want! I will go a little bit deeper in a next post : passing parameters to a delegate, exception handling, callback methods, AsyncResult, updating GUI-controls from a worker thread, BackgroundWorker in .NET 2.0, ...

Thursday, August 11

Looping in a Hashtable

A hashtable is a class in the System.Collections namespace and represents a collection of key-and-value pairs that are organized based on the hash-code of the key. Hashtables are very useful when storing temporary key-value data in memory for quick access. The key of the hashtable is processed through a hashing function that is designed to generate a unique value that is then used as an index into the hashtable to the specific location containing the value. Hashtables strike a balance between resource usage and speed.

You can loop through the Hashtable in various ways (like a number of stuff in .NET). I will show two ...
  •       private void loopWithEnumerator(Hashtable hashTable)


             //Set the enumerator for the elements of the dictionary

             IDictionaryEnumerator enumerator = hashTable.GetEnumerator();

             //Loop into collection

             while (enumerator.MoveNext())


                Console.WriteLine("key : " + enumerator.Key.ToString());

                Console.WriteLine("value : " + enumerator.Value.ToString());



  •       private void loopWithDictionaryEntry(Hashtable hashTable)


             //Loop into HashTable

             foreach (DictionaryEntry dictionaryEntry in hashTable)


                Console.WriteLine("key : " + dictionaryEntry.Key.ToString());

                Console.WriteLine("value : " + dictionaryEntry.Value.ToString());



I prefer the one with the DictionaryEntry because you can immediately start looping through the hashtable without creating an enumerator (= extra line of code). The foreach statement is actually a wrapper around the enumerator but this won't make a difference in performance I guess ...

Wednesday, August 10

Free hosting ASP.NET 2.0 (Beta 2)

Hostbasket offers free ASP.NET 2.0 hosting until the ASP.NET 2.0 official release (somewhere in November 2005)!

I signed up last week and in a few minutes my free account was set up with 50 MB Webspace and a SQL Server 2000 Database (10 MB). Very cool!

Now I still have to found some stuff to upload and see it in action ;-)

new Compuware Blogger

Steven Wilssens joined the .NET Group of Compuware Belgium in February 2005 and has now officially published his blog. As he worked with .NET from the early betas, he has built up a lot of technical knowledge. He posted already a few posts about his favorite topics : Software Configuration Management, Generics, Testing, ... More will certainly follow!

Subscribe here.

Sunday, August 7

What makes a great developer?

This week-end I finally completed my non-technical list of which skills a great developer should have.

A great developer ...
  • knows his preferred programming language and the underlying framework inside and outside. He easily finds his way through all documentation documents.
  • is able to quickly switch to another (unknown) programming language. In fact a great developer views his skills outside the scope of programming languages and platforms, and applies the best solution.
  • doesn't immediately jump into coding. Planning how to do stuff is very important before writing a single line of code and can save a lot of precious time in the long run.
  • always recognizes his coding lines and is able to quickly re-live the situation when he produced the code.
  • writes quality code : compact, well organized, documented, self-explaining, simple and solid.
  • is very cautious while fixing bugs. Changing/fixing code may cause instability elsewhere in the application. A great developer relies on unit-testing.
  • knows all debugging tricks to find the ultimate bug.
  • knows all the tools that make him more productive. It starts with knowing when to use which tool.
  • knows his own limitations and isn't ashamed to ask/cry for help. Knowing who to ask for help is also a great skill. A great developer also shares code to discuss best development practices.
  • is not only active during "project hours". Trying out new tools/software is part of the job. A great developer never stops learning.
  • sticks to coding guidelines/standards (best practices) - no matter what situation he's in.
  • feels responsible for his own coding. Bugs are taken personally and all power is used to trace them and fix them.
  • fully understands the business logic and impact of the application he's developing.
  • is able to produce quality code under difficult circumstances.
  • makes precise judgments based on previous experiences. A great developer also meets deadlines and has excellent communication skills.
Any suggestions/remarks on this list are highly appreciated!

If you feel like you're a great developer ... You should work for us! Compuware Belgium is looking for new .NET talent and I'm looking forward to meet you!

Monday, August 1

Windows Vista beta 1

Over the week-end I downloaded [almost 2.5 GB !!] and installed Windows Vista (beta 1) on my laptop. Oh boy : it takes a while! I followed the instructions on the blog of Bart Desmet to install Windows Vista on a Virtual PC.

After installation, it was clear that my graphic card (ATI Mobility RADEON 9000) did not support the Longhorn Display Driver Model (LDDM). In this case you should install the Virtual Machine Additions because this will install a default driver to enable the rendering of the graphics.

Read this if you want to know more about the Graphics Hardware and Drivers for Windows "Longhorn".

So far so good ...