Notes from Daily Encounters with Technology RSS 2.0
 
# Saturday, March 18, 2006

Never forget to disable simple file sharing (Explorer menu, Tools > Folder Options..., View tab, Use simple file sharing (Recommended)) when attempting to set permissions for certificate private key file on a machine with a fresh Windows XP install, not joined to a domain. In this case the option is enabled by default which hides the Security tab in all properties dialogs and consequently disallows any explicit setting of permissions.

It is a good practice to disable the option anyway but it is easily forgotten when setting up the machine for the first time. This reminder should prevent me from losing another half an hour wondering why I can't set the desired permissions using the WSE X.509 Certificate Tool the usual way in case I am once again given a task of preparing a demo machine for an application using certificates with service accounts.

Saturday, March 18, 2006 11:49:06 AM (Central European Standard Time, UTC+01:00)  #    Comments [1] - Trackback
Software | Windows
# Saturday, March 04, 2006

Yesterday I tried committing some changes to one of the websites I am maintaining into my CVS repository. To my surprise the operation failed or to be more exact, the TortoiseCVS client just kept performing the command for several minutes without failing until I cancelled it.

After some investigation I realized that it’s been almost two weeks since my last CVS usage and that in the meantime the only noticeable change on my server machine where I have the CVSNT service running was the change of the antivirus software. I started trying out NOD32. It became the primary suspect for the problem.

To make my further investigation easier I decided to try if the CVS works when used locally from the server:

cvs -d :pserver:damir@localhost:/Root login
Logging in to :pserver:damir@localhost:2401:/Root
CVS Password: ******
cvs [login aborted]: Error reading from server localhost: -1

Obviously it didn’t work even locally so it wasn’t a simple problem of firewall blocking the port (although this would be strange without having any firewall enabled at all). Some googling quickly uncovered the program responsible: NOD32 IMON service. Disabling it and restarting the server solved the problem.

But I wasn’t satisfied with that. I didn’t want to disable the internet monitor completely to make the CVSNT work. This would mean that I’d have to go on looking for another antivirus solution while I was completely satisfied with this one up till now. After some more investigation I found a hint that brought me to my final solution: re-enabling the IMON service and excluding the CVSNT executable from the monitoring. The exclusions list can be reached by opening up the NOD32 Control Center under Resident modules and filters > IMON. Setup button in the following window opens up another window with Miscellaneous tab, inside the Exclusion group there's an Edit... button which displays the list. The file that has to be added is cvsservice.exe from the C:\Program Files\CVSNT directory in the case of default installation.

Saturday, March 04, 2006 1:27:59 PM (Central European Standard Time, UTC+01:00)  #    Comments [2] - Trackback
Software | Antivirus
# Tuesday, February 28, 2006

One of the most common tasks when analyzing performance and optimizing code is measuring the time it takes to execute the code in question. Before .NET 2.0 you had to develop you own high resolution timer for the job by wrapping the unmanaged calls to QueryPerformanceCounter and QueryPerformanceFrequency.

I kept using the same class in .NET 2.0 but just the other day I stumbled across the Stopwatch class in the System.Diagnostics namespace. It implements the same high resolution timer functionality out of the box, so there’s no need to use unmanaged calls to achieve it anymore.

And the basic usage couldn’t be simpler:

using System.Diagnostics;
// ...
Stopwatch sw = new Stopwatch();
sw.Start();
// do some processing here
sw.Stop();
Debug.WriteLine("Time elapsed:" + sw.ElapsedMilliseconds.ToString());

One wonders what other hidden treasures lie in the class library yet to be discovered.
Tuesday, February 28, 2006 10:21:00 PM (Central European Standard Time, UTC+01:00)  #    Comments [0] - Trackback
Development | .NET
# Friday, February 24, 2006

I’ve spent a few hours today hunting down a mysterious bug which caused the program to keep reporting failed connections to database server although it was already available for hours. In the end it was a problem of incomplete exception handling but it’s interesting how the problem manifested itself. Let’s look at the following sample code.

using System;
using System.Collections.Generic;
using System.Text;

namespace DamirsCorner.Samples.StaticConstructor
{
   class Program
   {
      static string source;

      class Static
      {
         static Guid problem;

         static Static()
         {
            // will cause an exception if not a valid guid
            problem = new Guid(Program.source);
         }

         public static void Write()
         {
            // will only succeed after successful type initialization
            Console.WriteLine("Success!");
         }
      }

      static void Main(string[] args)
      {
         // setup invalid GUID source value
         source = String.Empty;
         Console.WriteLine("Invalid source value: \"" + source + "\"");
         try
         {
            // type initializer will fail here
            Static.Write();
         }
         catch (Exception e)
         {
            Console.WriteLine("Exception: " + e.Message + "\n\t" + e.InnerException.Message);
         }
         // setup valid GUID source value
         source = Guid.Empty.ToString();
         Console.WriteLine("Valid source value: \"" + source + "\"");
         try
         {
            // type initializer should succeed here
            Static.Write();
         }
         catch (Exception e)
         {
            Console.WriteLine("Exception: " + e.Message + "\n\t" + e.InnerException.Message);
         }
         Console.ReadKey();
      }
   }
}

Ok, there’s no database access here but just imagine that the Guid constructor call is the database access attempt. As you can see, the first call simulates that the server is down while at the second call the server is back up. Keeping that in mind the first call should fail while that second one shouldn't. (For those of you not familiar with static constructors: they get executed before the first (static or instance) property access or method call. As such they take care of type initialization.) Let’s take a look at the program output then.

Invalid source value: ""
Exception: The type initializer for 'Static' threw an exception.
        Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
Valid source value: "00000000-0000-0000-0000-000000000000"
Exception: The type initializer for 'Static' threw an exception.
        Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

Obviously both calls have failed. Why is that so?

It turns out that the static constructors are executed exactly once. If they throw an exception, it gets wrapped as an InnerException of the TypeInitializationException. Any attempts to use this class afterwards don’t cause the constructor to execute again, but just make it throw the same exception once again. Therefore the method call still reports an invalid GUID value (or in my case failed database connection attempt) although the problem has already been remedied. This makes the class effectively unusable within the AppDomain.

The lesson to be learned: no matter what you’re doing in the static constructor, never allow it to throw an exception unless the problem is indeed fatal and you intend to quit the program immediately. In all other cases provide reasonable defaults and handle changed circumstances elsewhere in the code.

You can find some additional technical details in Chris Brumme’s blog entry.

Friday, February 24, 2006 12:19:47 AM (Central European Standard Time, UTC+01:00)  #    Comments [1] - Trackback
Development | .NET
# Sunday, February 12, 2006

It’s almost half a year since security update 896358 has been released which prevents viewing HTML help (CHM) files from network drives. It should be noted that the file actually can be opened only the containing HTML files don’t get displayed.

Until now it wasn’t really an issue for me as I was always opening help files from local disks. But in the last few weeks I am managing help development at work and with company policy having latest files on file server shares I keep having to copy the files to my local disk before testing and reviewing them which soon gets annoying.

To avoid the repetitive tedious task of copying files around I decided to look more closely into the issue. It turned out that you can set the maximum trusted zone in the registry to avoid the problem. Since I trust the complete local network zone at work I raised the trust level by adding the following to the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001

Problem solved.

Sunday, February 12, 2006 10:40:34 AM (Central European Standard Time, UTC+01:00)  #    Comments [0] - Trackback
Software | Windows
Sponsored Ads

About Me
Twitter
@MladenPrajdic @andrejt use the middle mouse button then 2 days ago
Great #DotNetRocks show: Troy Hunt Secures http://t.co/oxClbXLe http://t.co/MiMasNuZ PDF is worth checking out as well http://t.co/z4BHAzqh 3 days ago
Hazards of Converting Binary Data To A String http://t.co/lb8kRSsU via @haacked 5 days ago
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

All Content © 2012, Damir Arh, M. Sc. Send mail to the author(s) - Privacy Policy - Sign In
Based on DasBlog theme 'Business' created by Christoph De Baene (delarou)
Social Network Icon Pack by Komodo Media, Rogie King is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.