Well so much for regular updates to this web log. I seem to be getting worse at it! My Warminster-Online site is up and running well now. I get on average 90 page loads per day which I think is reasonable considering. I am finding that I am the only one entering the services into it though. Maybe I ought to do some kind of advertising in the local area. In my day job I am writing lots of C# for a Windows Application for the MoD. So, C# code in the daytime, websites and ASP.NET in the evenings. Kinda like nirvana if your that way inclined. Got a couple more websites in the pipeline, will update more when I have firm committment to proceed with them. If anyone is interested in learning Web site design and/or Windows application programming, then you could do a lot worse than visiting the new Microsoft Beginner Developer Learning Center This is a new site and having looked at some of the resources available, I am highly impressed, the blurb says that it will take you from a novice to becoming a "Software Developer". Unsure whether any job interviewer would agree, but its a very good start if nothing else (And its free).

I have been reading up a bit now on Windows Presentation Foundation (Formerly Avalon). It is very difficult to know where to start, there are numerous articles sprinkled around the web, but it is not easy finding some kind of coherant learning experience.

From what I have found so far, it seems that there are 3 main selling points for WPF

1. It frees up the CPU and effectively passes graphical responsibility to the Graphics card. This advantage of course only pays off if you have a good graphics card. I have yet to find out if there are any minimum specification of card or if there is a switch at which point the graphics card is ignored and the CPU has to handle the graphics.

2. It will provide the richness of Windows Forms development within a browser windows, bringing with it all of the benefits associated with applications presented withing a browser window. However, this will mean that the host PC will require a Windows OS and browser to support it. So to reap the benefits of WPF all of your clients will require the WINFX runtime.

3. The GUI design of the application can be split out from the business code. I am unsure how much of an advantage this really is. In WPF, you can define your GUI in XAML (A specification over XML) and this is compiled somehow into the application. I remember learning about .NET Remoting and how you could contain all of the configuration information in an XML config file if you hosted the service in IIS. I am unsure if the benefits that this approach gave .NET remoting are the same as what XAML gives the WPF. Of course WPF GUI definition does not require XAML, it can be programatically defined via any .NET language (C#, VB.NET etc).


Whilst writing this, it was just reported on the news that the UK womens Curling team have been knocked out of the competition. Ho hum, 1 silver it is then.

Just by attending one of the Visual Studio 2005, Sql Server 2005 and Biztalk 2006 Launch events, Microsoft kindly sent me the following free software.

Visual Studio 2005 Professional
SQL Server 2005 Standard
Biztalk 2006

Thats nearly £2,500 for just the first 2. (Biztalk 2006 has not yet been released).
There is also a free exam voucher for one of the new Microsoft Certifications.

Thanks Bill.

 

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!