I have downloaded the Microsoft SQL Server Desktop Engine to allow me to study for my MCSD (Which is going swimmingly at the present).

Anyway, when I installed it, I did as usual and selected the easiest install options available. It all worked as expected and I was accessing Northwind with ease.

However, one of the examples I was working on entailed returning a Dataset object of Customers details via a Web Service. Suddenly, I could no longer connect to northwind database.

My guess was that this was something to do with the fact that the Web Service runs under a different guise than the interactive user. So far all of my connection strings had used the "Integrated Security = SSPI", so I changed this to be the SysAdmin account and password that I had created when I installed MSDE.

My Web Service then returned the error "not associated with a trusted sql server connection". A quick pump of this error message into Google, informed me that I had to use the "SQL Server Enterprise Manager " tool and change the security model to be SQL Server and windows and not windows only.

I did not have SQL Server Enterprise Manager installed on my computer, I believe it is an optional download. I relayed this relatively (ZZzzz...) interesting story to a colleague at work, who subsequently reminded me that basically all of the settings were in the registry anyway and all we had to do was find them. After a quick (1 hour or so) trawl through regedit, we came across a key named "LoginMode" that was currently set to "1". We set this to "0" and SQL Server did not like it very much and refused to start, so we tried changing it to "2". This time the server started and it also recognised my SysAdmin user ID and password.

Full Key Spec is

HKLM/Software/Microsoft/MSSQLServer/MSSQLServer/LoginMode

Obviously I cannot promote hacking the registry when there are controlled tools available to do it for you, but every now and then, it is good fun!

I was recently evaluating the Silverfrost Fortran 95 compiler compiler for .NET. This appears to be a capable implementation of a fortran compiler for the .NET platform. One of my main test piece of code was a smallish fortran routine (approx 360 lines) that calculated a geodetic height. The fortran functions were provided with an input latitude and longitude and calculated the geodetic height above the earths surface.

Not much of real interest there, apart from the fact that the front end was written in C# and the back end which was all fortran was compiled into a DLL which was referenced from the front end project. However, to perform the calculation, the fortran function had to open and read coefficient data into memory from a file containing 65338 records and each record contained 2 integers and 4 doubles.

Thats 2*4 + 4*8 bytes per record = 40 Bytes per record.
65338 records * 40 bytes = 2, 613, 520 bytes or 2552Kb or 2.5Mb

Both projects (client and backend) compiled ok, as expected. The Client was run and some data was entered. Once the C# code called the Fortran backend, an unhandled exception was immediately raised of type "System.StackoverflowException"

The help text for System.StackoverflowException states that it is typically thrown in the case of very deep or unbounded recursion. However I had no recursion, so it must have been due to the amount of data that the fortran backend was allocating to store these large coefficient arrays.

A bit of research on the net did not really help very much, so a bit more searching around MSDN found a tool named EDITBIN. This tool (The Microsoft COFF Binary file Editor) allows you to modify certain characteristics of COFF binary files, including executables and DLL's.

It has an associated tool named DUMPBIN to obtain information about COFF files.

After examination of my .NET generated fortran backend DLL, the size of stack reserve was shown to be 100000.This number is in hex and is therefore 1048576 bytes or 1024Kb.

I ran the editbin command on my 2 files in my assembly

editbin/stack:3000000 GEOIDBackEnd.DLL
editbin/stack:3000000 GEOIDFrontEnd.EXE

So I have now increased my default stacksize on my 2 executables and am able to run my magnificent fortran coefficient mathematical engine.

To automate this process if you are debugging, you can create a .BAT file containing the above lines and reference that from within the Visual Studio .NET project Options/Build Events/Post Build Step field.

I was writing a smallish application to parse a file on a network accessible share and display in human readable form, the contents of the file.

I previously had the program 90% complete on a previous platform configuration, but since then we have changed configuration, still XP Desktops, but different Server Infrastructure. On this new configuration, the program failed with an exception as soon as it attempted to perform directory listing of files in the network share.

string[] RevFiles = Directory.GetFiles(@"\\VMS\DREADM\","*")

Exception raised was System.Security.SecurityException
Additional information: Request for permission of type System.Security.Permissions.FileIOPermission, mscorlib ... Failed.

I have read about, only lightly Code Access Security, I guess now is as good a time as any to find out what the problem is by some further analysis.

First thing to do is isolate the problem into as small a chunk of code as possible, this ended up as just a simple console Application with 2 lines of code, the first being shown above and the second being merely to output all of the returned strings to the console window. I subsequently found that I could then no-longer evenlist files on my own C: drive, the following fragment still raised the security exception.

string[] RevFiles = Directory.GetFiles(@"C:\","b*")

After further investigation into how the .NET Code Access Security worked, the following was my situation:

1. Application was stored on a Network Accessable Share
2. Application was attempting to perform direct file IO
3. Being on a Network Share, my application inherited the "LocalIntranet" Permission Set
4. "LocalIntranet" Permission set did not allow the "FileIOPermission" by default.

There appeared to be no way to modify the default settings of the "LocalIntranet" security zone (More in a later blog if I find out how)

The next thing was how was my code evaluated to use the "LocalIntranet" Permission Set ?
That was found out by examining the Runtime Security Policy. The "User, All_Code" code group, if you look at its properties, has a permission set of "Full Access" so this was not stopping anything.The "Machine, All_Code" code group has a sub-code group of "LocalIntranet Zone". Its properties showed that its permission set was "LocalIntranet". I believe that this was the link I was looking for.

A quick step back to Permission Sets for the Machine, I am allowed to create a new Permission Set. Called "Mikes"for simplicity, I copied the contents of the "LocalIntranet" Permission set and merely added "File IO", Unrestricted Access for simplicity. Now hopping back into the Machine/LocalIntranet Zone Code group, I could assign the Permission Set "Mikes" to the"LocalIntranet" code group. Logging off as Administrator and back on as lowly user account, my small test harness started finally to display files in its console window.

Result!

So, what have I learnt ?

1. Do not automatically assume that apps will work when migrated from one system to the other.
2. .NET Code Access Security is a very large subject area.
3. I think that I have probably frigged a solution to my problem, given more time, I may re-visit.
4. Why did this work on my previous platform ? Answer, It was stored on a local drive.
5. It is a pain to keep logging out of Non admin account and into administrator and back. Fortunately my friendly System Administrator showed me how to access the .NET Config via command line command (MMC) and use "Run-As". Good job I am trusted with the Administrator password!
6. I believe that I may focus some of my .NET time and energy into this area.

Wish me luck!

Welcome to my very first Blog post

We (The family and I) have just returned from a 2 week holiday in France in a Caravan site called Le Bois-Tordu near St Hilliare De-Riez.

Had a fab time, thoroughly recommend the site if you have young children. The weather was fabulous, we even went swimming in the sea on the 1 rainy day that we had. A bit surreal, swimming in the sea when it is raining.