Archive for September, 2008

A Case Insensitive Hashtable for .Net

Wednesday, September 17th, 2008

I recently needed a case insensitive hashtable to store various types of values so I created one by wrapping the .Net hashtable. This hashtable works with any “object” type, but when the key is a string the value is not case sensitive. This is useful for:

  • Reading profile settings from multiple sources.
  • Reading XML elements where the attributes are not case sensitive.Here’s a link: CIHash.vbIn composer free nokia ringtones | 24 free ringtones | nextel ringtones | yahoo ringtones free download | 3g for free ringtones | 24 theme ringtones | music ringtones | 3g for free ringtones | free hindi ringtones | cell cingular free phone ringtones | 24 fox ringtones | ringtones converter | download new ringtones free | boost free ringtones | real tone ringtones | make your own free ringtones | yahoo ringtones | free mobile phone ringtones | samsung polyphonic ringtones | christian music ringtones | ???????? ????? ???????? addition to the .Net hashtable methods, I added some new methods.
  • The Overlay method adds one hashtable to another and if a key already exists it’s value is updated.
  • The Swap method (as it’s name implies).
  • Why Visual Studio 2005 debugger is broken

    Wednesday, September 17th, 2008

    Visual Studio 2005 is a pretty big improvement over Visual Studio 2003. So what’s wrong with it? The debugger is broken, that’s what! And that’s no small thing either!

    I suppose that I should be more precise. The debugger is broken for all the code that I work on, and those projects are all mixed mode (managed / unmanaged) projects. I have many projects that I work on that predate the emergence of .Net when it came out in 2002 with Visual Studio. That’s why I have written so much about porting legacy (unmanaged) code to .Net.

    I was eager to use VS2K5 so I downloaded it a week before the official release date in November 2005. Right away I could see that the debugger was broken for my mixed mode project so I created a bug report on the MS website. Here’s a link:
    VB File locked while Debugging Mixed Mode project
    (You might need an MSDN license to view this link)

    The gist of this report is this:

    In VS2K5 it is not possible to both edit and debug a source file while debugging a program. That is, you can either:

  • Set a breakpoint in your project and the debugger will stop there, but you cannot modify the code while you are stopped.
  • Or change the VS2K5 options and the breakpoint will never be hit, but you can edit your code at any time.Changing modes requires going to the “Tools > Options” menu and changing the debug mode.
  • I want to be clear, I am not talking about that truly marvelous feature that MS calls “Edit & Continue” where you can, on the fly, edit and recompile code in a single debug session. I am talking about just editing the code without a recompile.

    The most frustrating thing about communicating this to MS tech support was that EVERYTIME the MS tech support kept saying that E&C is not supported in mixed mode. And EVERYTIME I had to explain that I wasn’t talking about E&C at all!

    So, debugging legacy code with VS2K5 becomes very time consuming and I choose to forgo using it until MS fixes it. However, it looks like they won’t acknowledge that the bug exists, even though at least one MS tech confirmed it for me (I burned one of my MSDN incidents to get at least some traction on it).

    .Net and the falacy of security

    Wednesday, September 17th, 2008

    .Net purports to be a secure platform, but when I create a .Net setup package and used a custom action I found that I could not run the setup package on a network.

    I have a VB.Net installer. The installer program I created
    (System.Configuration.Install) handles the various events
    like MyBase.AfterUninstall, etc. This program works fine
    but when I run the installer on a network resource (a UNC
    path) it generates a System.Security.Security exception
    before the program even starts. The .MSI installer kicks
    off just fine, but throws the exception just when the .EXE
    program starts.

    The installer works fine if the UNC drive is mapped, or if a
    local drive. Any idea on what may be happening?

    The solution may surprise you. It surprised me! The setup package created in VS.Net has to be given permissions to execute from a UNC path, but not from a mapped drive! My users would never go for having to do that. They want to click a link in the email I send or on a web page and have the installer run. Fortunately, there is an easy work around, but it shows just how crummy the .Net security is.

    Here’s the trick: Create a batch file named setup.bat that gives the user all the permissions the setup package needs to run on the network. Here’s the contents of the batch file used to set security on .Net 1.1:

    /* $Date: 2006/06/09 17:51:05 $ */
    /* $Revision: 1.1 $ */
    /* $Author: mike $ */
    IF NOT "%1" == "/?" GOTO :TESTOS
    	ECHO CONFIGNET.BAT - Sets up the .NET configuration
    	GOTO :END
    IF "%OS%" == "Windows_NT" GOTO :SETLOC
    rem Trim the command line to be only a drive letter and path only
    rem Test the SETUP DIR to see if we are on a UNC path. UNC paths start with "\\"
    rem A UNC path requires us to run caspol to give .NET permissions to run the setup
    	IF "%MYROOTDIR:~0,2%" == "\\" GOTO :TESTCAS
    rem At this point we have assumed that the batch file is run from a UNC path
    rem This requires that we SET the .NET permissions using CASPOL.EXE
    rem Verify that CASPOL.EXE is on the system
    	SET CASPOL_EXE=%SystemRoot%\Microsoft.NET\Framework\v1.1.4322\CasPol.exe
    rem Run CASPOL and see if the permissions are already SET for this UNC.
    rem CASPOL has the nasty habbit of creating permissions each time,
    rem regardless if they are already present or not.
    rem Change the "\" to "/" which is what caspol likes to see
    ECHO Testing .NET security: "%MYROOTDIR%"
    "%CASPOL_EXE%" -lg 2>NUL | findstr /I /C:"%MYROOTDIR:\=/%" >NUL
    rem CASPOL is required for this UNC Path. Add it to the .NET configuration
    ECHO Setting .NET security
    "%CASPOL_EXE%" -q -machine -addgroup 1 -url "file:%MYROOTDIR%*" FullTrust -n "mmGrasp" >NUL
    	ECHO !!! ERROR: Setting .NET for "%MYROOTDIR%"
    	ECHO.NET security OK
    	GOTO :END

    So there it is- one of the ways that .Net security falls short and an easy way to beat it.

    .Net and Legacy Code

    Wednesday, September 17th, 2008

    As you can see from my previous post I am interested in recycling my old “C” code for use in .Net. I don’t want to rewrite the code in C# or VB so I am wrapping it with a C# DLL. The good thing about .Net is that it already has much of the functionality that I put into some of these old C libraries. However, there is a lot that I didn’t write that I would like to wrap, in particular: GSL gets wrapped here: Gnu.dll.

    One of the big problems I have had with wrapping old DLLs is with arrays. .Net managed arrays are quite different from C arrays. Consider the following from GSL:
    // double gsl_stats_mean (const double data[]
    // , const size_t stride
    // , const size_t n);
    exact spelling=true,
    CharSet = CharSet.Ansi,
    public static extern double mean
    ( [In] [MarshalAs(UnmanagedType.LPArray, SizeParamIndex=3)]
    double [] data
    , [In] int stride
    , [In] int n);

    It seems to work OK, so what’s the problem? Try using this on a bunch of 1,000,000 element arrays and see what happens to the resources on your PC and you’ll soon see!

    The MarshalAs class copies the data in the .Net array into a new C array. Here is a better implementation that uses the GCHandle:

    public class gsl_stats {
    internal static unsafe GCHandle _gch_pinned_ptr(double[] data, ref double *p)
    	GCHandle gch = GCHandle.Alloc(data, GCHandleType.Pinned);
    	IntPtr ip = gch.AddrOfPinnedObject();
    	p = (double*)ip.ToPointer();
    	return gch;
    public unsafe static double mean (double [] data
    	, int stride, int n)
    double *p = null;
    	GCHandle gch = _gsl._gch_pinned_ptr(data, ref p);
    	double d = gsl_stats_DLL.mean(p, stride, n);
    	return d;
    } // mean()
    } // gsl_stats
    public class gsl_stats_Dll
    	, ExactSpelling=true
    	, CharSet = CharSet.Ansi
    	, CallingConvention=CallingConvention.Cdecl
    	, EntryPoint="gsl_stats_mean")]
    	public static extern unsafe double mean
    		( [In] double *data, [In] int stride, [In] int n);
    } // gsl_stats_DLL 

    Version 0.0

    Wednesday, September 17th, 2008

    Well here we are on! I’ve been writing code for a very long time now and I have a lot to share. I am working on a .Net wrapper for the GNU GSL (See GSL it here) Here’s what I’ve got so far: Gnu.dll. It is a bit generous for me to use the namespace Gnu, but there is a lot of open source legacy “C” code that I’d like to wrap for use in .Net, and the “Gnu” namespace seemed the most appropriate.

    I really like .Net and think that it is long overdue. I have been writing code pretty much entirely on MS-DOS and Windows since 1986 and I have used Microsoft products pretty consistently the entire time. As far as MS code development, the only MS products I haven’t used are COBOL and Fortran (although I have use Fortran on other platforms). I have also had the pleasure of dealing with MS for support over the years. When MS came out with Visual Studio 1.0 for use on Windows 3.0 in 1992 they really took a step backwards from Programmer’s Workbench. PWB was almost as good as emacs as a code development platform. But heck, VS 1.0 didn’t even have regular expressions in the editor- how lame is that? Plus it came on 22 floppies and took over 3 hours to install! But the telephone tech support was pretty good, and VS did improve over the years. I was really happy when VS 5.0 came out and had incremental compiles and “Edit & Continue” for C+. I thought that was just soo coool!

    When .Net came out in 2002 I thought that VS took another leap forward. I really liked VS 6.0, but VS.Net was missing something I always took for granted in VB: Edit & Continue! How could they take it away??? At least they still had it in C++, which was really killer. When VS.Net 2003 came out I was happy with it too. But when VS.Net 2005 came out I was immediately disappointed!

    Sure, VS.Net 2005 had lots of great new features and it claimed to have Edit & Continue, but the debugger was broken! At least the debugger was broken for use in “mixed mode” development (managed/unmanaged solutions). Back in the day, a mixed mode project was using different development platforms like C, assembly, and VB, and then linking them together, something I have done since ‘93 when I got VB 3.0. I still like to use VB as the GUI and C++ Dll’s for the implementation. The legacy code I use interfaces quite nicely with .Net, if you know how to do it (thus the port of GSL).

    You see in VS.Net 2005 in the unmanaged code you can either set a breakpoint or edit the code during a break in a debug session, but not both! And it is a hassle to switch the modes.

    One week before the official release of VS.Net 2005 I created a bug report on this at the MS web site. The lame-o’s at MS tech support kept insisting that this was a feature not a bug, since Edit & Continue was not supported in mixed mode. My point was that I didn’t care if the code didn’t compile and run on the fly, I only want to edit it while I stepped through the code, so as to correct and improve it during the debug session!