CodeInsight.com

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:

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 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:

@GOTO :START
/******************************************/
/* $Date: 2006/06/09 17:51:05 $ */
/* $Revision: 1.1 $ */
/* $Author: mike $ */
/******************************************/

:START

IF NOT "%1" == "/?" GOTO :TESTOS
	ECHO.
	ECHO CONFIGNET.BAT - Sets up the .NET configuration
	GOTO :END

:TESTOS
IF "%OS%" == "Windows_NT" GOTO :SETLOC
	ECHO.
	ECHO !!! ERROR: SETUP PACKAGE REQUIRES A WINDOWS NT TYPE OS
	GOTO :ERROR

:SETLOC
SETLOCAL ENABLEEXTENSIONS
	IF ERRORLEVEL 1 GOTO :SETLOCERR
	GOTO :TRIMCMD

:SETLOCERR
	ECHO.
	ECHO !!! ERROR: COMMAND EXTENSIONS NOT AVAILABLE
	GOTO :ERROR

:TRIMCMD
rem Trim the command line to be only a drive letter and path only
SET MYROOTDIR=%~dp0
IF "%MYROOTDIR%" == "" GOTO :RUNSU

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
	GOTO :RUNSU

: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
	IF EXIST "%CASPOL_EXE%" GOTO :RUNCAS
	ECHO.
	ECHO !!! ERROR: MICROSOFT .NET v1.1.4322 PACKAGE NOT INSTALLED
	GOTO :ERROR

:RUNCAS
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
	IF ERRORLEVEL 1 GOTO :NEEDCAS
	GOTO :CASOK

:NEEDCAS
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
	IF ERRORLEVEL 1 GOTO :CASERR
	GOTO :RUNSU

:CASERR
	ECHO.
	ECHO !!! ERROR: Setting .NET for "%MYROOTDIR%"
	GOTO :ERROR

:CASOK
	ECHO.NET security OK
	GOTO :RUNSU

:RUNSU
	GOTO :END

:END

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

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);
[DllImport("libgsl.dll"
exact spelling=true,
CharSet = CharSet.Ansi,
CallingConvention=CallingConvention.Cdecl,
EntryPoint="gsl_stats_mean"]
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);
	gch.Free();
	return d;
} // mean()
} // gsl_stats

public class gsl_stats_Dll
{
	[DllImport("libgsl.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 

Well here we are on CodeInsight.com! 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!