Ernst Kuschke

After reading a quote by Mark Twain today, I couldn't help smiling - it perfectly fits the mad day I'm having!

When we remember we are all mad, the mysteries disappear and life stands explained. -Mark Twain

..are over here. I know that many people have a different opinion! Convince me if you can.

It is impossible to abort a suspended thread! (A “known” CLR bug). It's safe to add “Never abort threads!” to what I thought about it a while back. I recently saw code (for a windows service) that fires up threads marked as background threads. Background threads are automatically aborted when the spawning thread terminates. If this service is stopped, these particular ones leak unmanaged handles... Fixed it by adding an infinate loop to the “outer” try-block in the spawned thread, which enables you to catch the exception raised on termination.

Brad Abrams has a new site up, which he plans on becoming a place where smart people know they can find high quality, accurate advice. He has a few *good* articles up already, and Brad is a pretty smart guy too. Check it out.

[UPDATE] Whoops, that would be Brad Wilson's site, and not Brad Abrams! So many Brads in this world :)

...is here in the form of Release Candidate 1.

[Listening to: Emit Remmus - Red Hot Chili Peppers]

Since I wrote my articles on Garbage Collection I've been getting comments from people regarding Finalizers. Reading the articles, it seems (to some!) as if it is recommended to implement Finalize, while in fact I'd recommend you not to. I'm currently writing on why not to implement Finalizers, as well as some interesting engineering strategies to circumvent the issues related to finalization.

If any of you guys & girls have any comments relating finalization techniques, please post them here. To give you a taste, I can't think of a single scenario that enforces you to implement Finalize, and I thus recommend everyone to stay away from it!

So cool having a long-weekend, really! I've been at it getting my surfing up to speed. (It's far from speed. It's closer to standstill!)

We try making code safe by cleaning up in finally blocks, because we are guaranteed of their execution, right? Uhmmm.... well.... almost... Let me illustrate:

using System;
using System.Threading;

class Test
{
    public static void Main()
    {
        Thread t = new Thread(new ThreadStart(Oops));
        t.Start();
        Thread.Sleep(1000);
        t.Abort();
        Console.ReadLine();
    }

    static void Oops()
    {
        try
        {
            try
            {
                Console.WriteLine("Entering INNER try-block");
            }
            finally
            {
                Console.WriteLine("Starting INNER finally-block...");
                Thread.Sleep(5000);
                Console.WriteLine("Done with INNER finally-block...");
            }
        }
        catch(Exception e)
        {
            Console.WriteLine("Exception of type {0} caught!", e.GetType());
        }
        finally
        {
            Console.WriteLine("Starting OUTER finally-block...");
            Console.WriteLine("Done with OUTER finally-block...");
        }
    }
}

If you call Abort() on a thread, an exception of type ThreadAbortException is thrown on the thread being aborted. Great, this is expected. But there seems to appear a “race” condition when this type of exception is caught while executing a finally block. Executing the listed code yields:

The inner finally-block starts execution, but in fact never completes! This could result in unpredictable results, especially relating memory leaks, and is good to be aware of.

In yesterday's seminar Kim created a strong-named assembly, and dropped it into the GAC. When he wanted to reference this assembly in a new project, he had to browse for it - it wasn't listed.

Now, to make your life easier, know that Visual Studio.NET doesn't check the GAC when you add references to projects. It checks a registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders

If you add a key below that key with a default value (string) of the path of where your assemblies are located, the next run of VS.NET will check that folder and your assemblies will show up in the dialog of the .NET references.

Ian Griffiths had this to say about having your web-server compromised - a pretty good read.

[UPDATE] - After thinking about it, I agree 100%. There is no way out using provided architectural solutions.

Using integrated security to get to your DB means nothing when your server is compromised in such a way that code can run on it. The injected code will pass the integrated security check, regardless of where the DB resides physically.

Using user-accounts will mean that your credentials need to reside somewhere on your web-server. If your server is compromised, these credentials will be “open for anyone to look at”.

Catch 22... The only way out that I can think of right away is obscuring your credentials in some way, and hope they aren't discovered. On second thought, your /bin directory will be compromised, and your obscure credentials will mean *nothing* since they will be available via reflection on your binaries... Any other suggestions?

For MSDE administration we've had to use Visual Studio, 3^rd party tools, or SQL Server tools. All people who use MSDE do not have a spare SQL Server package lying around, though. Fine, they could download the SQL Server Demo, and use the Query Analyzer that is included. However, it was always a bit of a messy business in getting there...

Finally Microsoft has made available a frontend to MSDE: the SQL Server Web Data Administrator can be used with MSDE as well as SQL Server. In fact, it offers all of the following:

I can do with that :)