So I got my mark for my project design, and it's a B. That will do very nicely, thank you. I've long since put away any thoughts of getting an A: still less an A*. A bare pass will suit me just fine.

I spent last evening suffering from the effects of eating too much, so the work on my technical specification has slowed to a crawl - if not a full stop. Still, I did manage to get an ASP.NET capable Web server (XSP) running on my Linux box at home last night. It's not the one I really planned on using, but it will act as a good backup if I can't get mod-mono working.

So we're hanging in there.

Did I wish everyone a merry Christmas and a happy New Year? If not, I do so now. Nadolig llawen, a blwyddyn newydd dda iawn ichi i gyd.

Still don't have a mark for the design. I suppose tutors have to have a Christmas break as well. It would have been nice to go into the New Year knowing what I had, though.

I've managed to push on a bit, however. Today I completed a Statement of Requirements for the software I'm writing. It isn't brilliant, but it should do the job. There's no mark for it, but I've submitted it to my advisor just in case she feels like making any comment. Heh! I need all the help I can get.

Tomorrow I'll start on a technical specification. This is where the rubber hits the road, really, in software development. It's just a hard, detailed slog; taking the requirements and translating them into a set of rules for the developer to implement. Once this is done, it only remains for me to produce a set of UML diagrams that will model the finished application, and to code it up.

Only!

Of course, after that I have to test it; then I have to install it at work and make it available to my users; then I have to collect the results and analyse them and write it all up and ...

And it all has to be ready by the end of April.

Happy New Year to one and all.

Well, I got my design in at last.

It isn't really adequate as a design for my software, but it is adequate for what the university wants in order for me to get a mark. I hope!

There were sixteen powerpoint slides by the time I'd finished. My advisor wanted more graphics than text so I sweated away with some CASE tools, graphics packages and other utilities to conform to what she asked for. She seemed happy to mark it anyway.

Things are really hectic at work, so motivating myself to do anything on the MSc is very hard at the moment. I'm hoping that over Christmas, once family duties have been performed, I'll be able to spend some quality time with my dissertation.

So, back to work.

The marks for the MSc go like this:

• Specification - 10%
• Design - 10%
• Dissertation - 80%

I've now had a mark for the specification, and it's a B.

My advisor says I only just missed an A, but I'm not bothered. Getting to this point has been a long, hard struggle. I've averaged an A all the way through so far. Now I just want to get it over with, so any kind of pass is OK.

My design has to be in by the end of this week and my advisor seems happy with the way it's going, so we're still on track. We are. Honest we are.

Sometimes you just have to be grateful for your friends.

I was intending to go into work this weekend to set up the two servers I need for my project. Actually, I was intending to go in and do as much as I could to set them up; but I knew I wouldn't get it all done. There's just too much I don't know - like the IP address of the proxy server and the password for it. I am a programmer after all and not a sysadmin.

Craig, on the other hand is a sysadmin. I spoke to him this lunch time to try to pick his brains about a few things, to try to ensure I at least made some progress when I came in. We talked for a while, and he told me how to get IP addresses allocated, and wrote down some stuff about gateway addresses and such, before I had to leave for a meeting.

When I popped back in to see him at four o'clock this afternoon to confirm a couple of things, he said, "Oh! I've just started them off. There didn't seem any point in your coming in this weekend when I could get it done in an hour or two."

By the time we left at four-thirty, the XP box was set up and the Linux box was busily updating itself with all the patches published since I bought the discs, some months ago. When we get back in on Monday there should be very little left to do.

What a pal. I think that's earned him a bottle of wine this Christmas.

The fact we both speak Welsh probably didn't hurt matters, either.

The weather.

Yes, even Cardiff is cold today and that's pretty unusual. Still, it does mean that the temptations to do all the other things that are currently looking more interesting than working on my dissertation are that bit less powerful than they were. Heck! Even ironing shirts is looking more attractive at the moment.

The project specification has been submitted and it's pretty much what I had before. My dissertation adviser said she was happy with it, so I didn't argue. I just submitted it. So that's some percentage of 10% of the final mark now in the bag.

The next step is to submit a project design, for another 10% of the total marks. As far as I can tell from the guidelines that pretty much means the software specification in the case of my project. Which is fine, except that they want the thing on 4 pages of A4 or 12 - 15 Powerpoint slides. My experience from work is that software designs run to tens if not hundreds of pages. How I'm going to stick to the limits they set here, I've no idea.

But sitting around worrying about it won't help. I'll just have to do what I can. And quickly.

Just shows what a family drama and a heavy cold can do to your schedule.

Still, I have got some feedback from my supervisor on the project specification that I've been working on: and it's positive. That's quite a relief, because I wasn't too sure about it myself. With any luck then, I'll finish the specification off tomorrow and then I can get on with the design.

I had hoped to install my servers last weekend, but what with one thing and another... And it's probably best for me to concentrate on the spec this weekend. I'm not enjoying writing it, so best to get it out of the way.

With any luck, I should be able to install the servers next weekend. That's the plan anyway.

Right. Back to the steam, the Night Nurse, and an early night.

I've been away at a conference for a couple of days, so the blog's not been updated as much as it should. There is some news, though, and it's all pretty good.

Firstly, I've now got the two computers I needed. Temporarily, I've stashed them away in our office with the legend, "Peter's research machines. Don't even breathe on them" plastered all over them in thick, black felt tip pen. They're still there as of 17:00 today, so it must be working.

I've also found out two more things about .NET and Mono. Getting a Linux/Unix daemon to start at boot time was one of the problems I had to solve; and thanks to help from Robert Jordan, who supplied a script, I've managed to get this working. The script is SuSE Linux specific, but should be easy enough to change for other distributions.

The other thing I've found out is that you can use configuration files with remote proxies instantiated from interfaces. The app.config file is a bit different and you can't use the new keyword to instantiate the proxy, but it does work - and may be better in many circumstances. I'm indebted once more to Robert for this.

I've written up what I know about remoting in two documents: one for metadata proxies and one for interface-based proxies and asked for comments from the people on the Mono mailing list who'd expressed interest. If they don't come back with comments or questions by the end of the week, I'll submit the documents to the Mono project.

My dissertation advisor reminded me that I have to have the project specification ready by the end of the month, so I did a lot of work on that this weekend and submitted what I have so far to my advisor for comments. When I've had the comments I'll try to press on and finish it this Sunday - all being well.

Before that, on Saturday, I'll try to set up my test machines with all the necessary software. That should keep me busy.

One of the things you need to do in order to expose remote objects on an application server is to provide a host for the object. The host listens for communications on a specified port and then creates the object that the client specifies in the communication. In .NET this is done via a URI, which is a generalisation of the kind of string you type into a web browser to find a particular web page:

<protocol>://path/to/the/resource

For a web page, the protocol is http, usually, but for remoting it can be other things like tcp (transport control protocol). But I digress.

If you want to, you can use an ordinary program that you start manually as the host for the remote object, but this has a number of drawbacks. Firstly and most obviously, you have to start it manually. Secondly and not quite so obviously, you have to be logged in in order to start the program. Furthermore, the program is likely running in the foreground (e.g. in a terminal window), so it could accidentally be terminated.

What we would really like is to host the object in a program that starts automatically when the server boots and continues to run in the background without any user intervention. This type of program is called a "Service" in Windows, or a "Daemon" in the Unix/Linux world.

The Windows version of .NET provides a lot of help to allow you to host your remote object in a Windows service - including Installer objects that you can include in assemblies containing class(es) derived from ServiceProcess.ServiceBase, and which can be used by a .NET tool called installutil to install the Windows service.

The Mono team have managed to transfer much of this to a Unix/Linux environment: but the process is a little different. You have to use a tool called mono-service whose usage is not immediately obvious - to me at any rate.

Thankfully Robert Jordan and Jörg Rosenkranz from the Mono mailing list provided me with enough help and advice to see me through. Robert, in particular, provided me with a script that installs the service by calling mono-service with the required parameters.

I had a lot of trouble getting it to work even then, until Jörg suggested i check /var/log/messages to see what was being output (Doh!). It gave a perfectly clear message telling me that I had an element attribute mis-configured in my app.config file. Windows requires:

<customErrors mode="Off">

Mono required:

<customErrors mode="off">

Spot the difference? It's the difference between a small and a capital 'O'.

Robert has now made Mono case insensitive, but my installation has not yet been updated with his patch.

I'm still not done, though. The above means I can start the daemon process in the background such that it will persist even if I log off. At the moment there is nothing to make it start when the machine is switched on. I've asked for advice and expect this will not be a problem. I don't think so, anyway.

You know, there's always the temptation to think you know more than you do. You work away at your job and you find solutions to problems and you think you've learnt all there is to know.

Then you meet someone who knows more than you do. Comes as a shock.

I've spent a good part of today "talking" to the people on the mono-list mailing list, about .NET remoting. In particular we've been discussing the ins and outs of hosting remote objects in services (Windows) or daemons (Unix/Linux). Now, these are the people - some of them, at least - who've coded the Mono implementation of .NET. The breadth of their knowledge is breathtaking.

What's more, when you look at what they've achieved with the Mono project, you just have to forget your pride and satisfy yourself with "sitting at the feet" for a while. I'm full of admiration for what the Mono team has achieved.

So plaudits and kudos to the Mono team. Absolutely amazing.

Today my employers finally gave permission to set up my experiment on their LAN. I don't think there was ever seriously any objection: but there is always a fear of the unknown. I doubt anyone has ever made this sort of request before.

So now I just have to find the machines I'm going to use as my servers and set them up. Looks like a job for the weekend to me, especially since my wife is teaching all day Saturday in a Saturday school.

What I have to do now is to get some serious work done firming up the exact nature of the experiments I'm going to conduct. At the moment all I can think of is problems and difficulties. The best way to overcome that, I think, will be to get a design put down on paper. That way I'll be starting from something positive.

Still no final answer from my employers about the resources I've asked for. I'm a bit disappointed by that, but still hopeful I'll get what I want. It's hard to see how they could reasonably object - but then, I've been disappointed before.

On the positive side, my literature review is coming along fairly well, I think. I'm up to 3,350 words anyway

I've also moved a little way along the path of defining the nature of the application I want to develop. It's actually fairly clear in my mind what I want to do, but without the go-ahead from work, I'm reluctant to move too far. What I am pretty sure about is that the application will ask testers to input some student data, and perhaps update it and maybe also delete it.

There's a specification called IMS Enterprise that defines in XML format the data required concerning students in an e-Learning context. I've downloaded the specification and also some XML tools for Eclipse that should make it easier for me to work with it. With luck, one of the things that I'll be able to do is to generate some student data in an XML file which I can upload programmatically using both MS .NET and Mono. The comparison between the two in a batch-processing environment should illuminate that work I do in the interactive environment. It may be that performance between the two is pretty similar in an interactive environment, but more favourable to MS .NET in a batch environment. This is what I'm expecting, anyway.

Ah well. Back to the literature review.

Yesterday I met the VP to discuss the resources I'd like in order to carry out the experimental part of my project. The upshot is that he is fine with it, provided our Systems Manager has no qualms about security.

I couldn't contact the Systems Manager directly because he was in a meeting, so I emailed him with the details. His reply, which I received yesterday evening indicates that his only concern is with viruses. This should be absolutely no problem at all, but I may have to convince him of this fact: which may not be totally straightforward. Still, the ball's still in play and I ought to be able to keep it that way - even if it means making the odd compromise with my experimental design.

Since I'm on holiday this week, I'm sat at the computer on tenterhooks waiting for news.

More immediately productive yesterday was a meeting with the Librarian at Colchester Avenue Campus, for guidance on doing a literature review. The first pleasant surprise was that the Librarian turned out to be Welsh-speaking, which made communication a bit easier. All-in-all her advice was very useful. It's up to me to use it wisely now.

Having sobered up a little following the success of the test remoting program, I wrote a tutorial that explains how to produce .NET remote objects, clients and servers. Firstly this means that I ought to be able to reproduce the results. Secondly, it could be a useful document for others who want to build applications of this kind.

With this in mind, I offered to send the document and the program source and executable files to anyone on the mono-list mailing list who might be interested. There was a more enthusiastic response than I had imagined to the offer and the tarballs have been sent directly to a couple of people. On top of that Miguel de Icaza (no less) has offered to set me up with an account on the mono Wiki so that I can post the document there.

Let's just hope that they're happy with it once they've read it.

Looking forward, Carole and I are off to Stratford-on-Avon for a couple of nights, including a visit to the Royal Shakespeare Theatre to see A Comedy of Errors. We've not seen it before, so we're looking forward greatly.

The next entry looks like being on Monday, at the earliest, then. By that time I should know whether or not I've been successful in getting the resources I'm after.

Fingers crossed.

Yesssss!

I managed to get down to work pretty early this evening, and since my day job involves writing n-Tier applications it didn't take me long to write a small application - a calculator actually - that has a Windows Forms front-end that calls methods on a remote object hosted in a console application.

The real triumph, though, was to copy the finished application over to my Linux partition and try to run it from there. It didn't work at first. Initially the server wouldn't start because of an error in the server .config file, but it was only a character case error in the <customErrors> element (see below), and easy to fix.

It was more difficult to fix the client. It also gave an error on trying to load its .config file, but this time I couldn't see why. Fortunately, Rob Jordan of the mono-list mailing list spotted immediately that I hadn't given the fully qualified class name for the remote object. Windows doesn't require the fully qualified name in this context, but mono does.

Once that was fixed, it all worked like a dream.

So, here are the things I have to remember for cross-platform remote config files:

• In the server .config file, mono wants <customErrors="off"> whereas Windows wants <customErros="Off">
• mono needs the fully qualified class name every time in the .config file
• mono throws an exception if there are errors in the .config file. Windows doesn't

That's enough for today. Great stuff.

Some weeks ago, I sketched out for my advisor the general outline of the submission I intended to make. It looks like this (apologies for the formatting, which I haven't the time to tidy up):

1 Project

2 Introduction
2.1 General
2.2 Problem statement
2.3 Summary of conclusions

3 Statement of the problem

4 Literature review
4.1 .NET Framework
4.2 Cross-platform .NET implementations
4.3 n-Tier software development
4.3.1 Rationale
4.3.2 Characteristics
4.3.2.1 Security
4.3.2.2 Distributed computing
4.3.2.2.1 RPC
4.3.2.2.2 Web services
4.4 Technology specific resources
4.4.1 Microsoft’s .NET implementation
4.4.2 Mono
4.4.3 Other .NET implementations
4.4.4 Tools
4.4.4.1 Visual Studio
4.4.4.2 monodevelop
4.4.4.3 Apache and mod_mono
4.4.4.4 XSP
4.5 Software development management
4.5.1 Development models
4.5.2 Capability Maturity Model

5 Project design (outline and justification of a proposed solution)
5.1 Discussion of methods for comparing .NET implementations
5.1.1 Completeness
5.1.2 Standards compliance
5.1.3 Fitness for use in developing n-Tier, secure, distributed solutions
5.1.4 Benchmarking
5.2 Hardware components
5.3 Software components
5.3.1 Windows
5.3.2 Linux
5.3.3 Web servers
5.3.4 Databases
5.3.5 Development environment
5.4 Benchmark requirements
5.5 Application requirements

6 Application framework development and testing results
6.1 Application framework
6.2 Test results

7 Discussion of results
7.1 Suitability and applicability of the application
7.2 Applicability of the benchmark tests to real-life situations

8 Recommendations for future work and conclusions

I'm currently working on section 2.1, which I'll post next.

The news was a mixed bag towards the end of the week. The bad news was that the Vice Principal has postponed our meeting for a few days. I'm not suprised. He's a very busy person and I can't be the most important thing on his mind at the moment. I still think I'll get what I need, though.

The good news is that I discovered that mono now includes a complete implementation of System.Runtime.Remoting. Up until someone on the mono-list mailing list put me right I had thought that only Web services and direct remoting were possible; but apparently this is not the case.

I'd been misled by what I'd read on the gotmono.com website. Stupidly, I'd not checked the date on the article and it turned out to be two years old. It seems that the gotmono site is not being maintained. This is a pity, since others may make the same mistake as me, and perhaps be dissuaded from using mono as a result.

Now I really must get on with some background reading.

Well, the Vice Principal has agreed to meet me to discuss resources on Wednesday next (19.10.2005). I've spoken to a couple of people who are closer to the VP than I am, and they think I should get what I want. So fingers crossed.

I also had a word with our SysAdmin to see if he'd be happy to have this stuff on his network and perhaps give me a hand with setting it all up. Fortunately he's an OSS advocate. He was more than happy with what I wanted: even suggesting it would be helpful to him, personally, in gaining experience with heterogenous networks.

So it's just a matter of waiting now, until Wednesday, and hoping that all will be well.

I'm doing some background reading too, and this is leading me to the conclusion that I'll probably be best using Web services to connect the presentation and business logic layers. I don't actually think that this is a good idea from a security point of view: but given the state of development of remoting in mono, it may be the only sensible way. We'll see. I need to do some more investigation first.

After the project proposal was accepted, it struck me that doing the benchmarks on a dual-boot machine was probably not a very good idea. So I'm asking my place of work to let me have some resources to do the testing at work, and to do rather more sophisticated tests than I had originally envisaged. Here's what I've asked for:

MSc proposal for benchmarking .NET implementations

Introduction

The project aims to determine whether or not the .NET platform can be used to develop distributed, cross-platform, n-tier, secure applications (Enterprise-class applications) with an acceptable performance. The results of the project will tell C# developers what steps they need to take to write platform agnostic code and what performance implications these may have.

(From the Project Proposal)

To this end, it is proposed to develop some benchmark tests that will help developers determine the sorts of performance differences that might be expected in real-life situations between code running under the Microsoft CLR and the same code running under the mono CLR.

Hypothesis

Real-life industrial-grade code running in a distributed environment is subject to many latencies the most obvious of which are network latencies and database latencies. It is expected that any slight differences that there might be between the two .NET Framework implementations will be dwarfed by these other factors.

Experiment design

Hardware

It was originally envisaged that a single dual-boot machine could be used; however this gives rise to the following problems:

• Network latencies will not be present
• A database instance would be required on both partitions. Since the performance of the same database might vary depending on the operating system platform, any measurements might be measuring nothing but this difference in database performance.
• Similarly, there will be differences in web server performance under different operating systems
• The test application would not be widely or conveniently available to testers.

A better solution would be to use a dedicated database server accessed by two web servers over a LAN. The test program would be accessed by testers using workstations running a web browser, located elsewhere on the LAN. Such a solution will not isolate differences in web server performance, but will address the other issues. It could, in any case, be argued that web server integration was a part of the overall .NET implementation.

It is proposed that the following hardware/software combinations be used for the servers:

• Database server running MySQL or PostgreSQL under either Windows or Linux. The operating system platform is not important.
• Web/Application Server running Apache2 on Windows 2000 (or better) and the Microsoft .NET Framework v1.1.4.x
• Web/Application Server running Apache2 on Linux (Red Hat Fedora or SuSE Linux Pro v9.3 or better) and the mono .NET implementation v1.1.9.x

None of these servers need be particularly powerful. Reasonably modern PCs would be perfectly adequate. It is however important that the two web servers are running on hardware that is largely similar (identical if possible).

Test software

It is proposed to develop a test ASP.NET application based around the IMS specification for a person. A person is probably best thought of as a student in this context. The program would time testers performing the task of entering details for a reasonable number of students. The expected duration of each test would be around 10 minutes.

The application would connect, from its front page, to one of the web servers at random thus ensuring that a more-or-less equal number of tests would be carried out for each configuration. Users would be unaware of which web server was being used.

Each tester would be timed for the overall task.

In addition, the program would provide facilities for uploading student details from an XML file, in bulk. The times taken for bulk uploads would also be compared.

It is hoped that testers could be found from work colleagues. It makes no difference whether the testers are fast or slow at data entry, or that they complete the task any number of times – as long as a sufficient number of tests is carried out with a sufficient number of people.

As promised, here is my MSc project proposal (slightly edited):

Application to Commence Dissertation Project

Project Title:

Casting the .NET: is the .NET platform a cross platform environment for secure, distributed, n-Tier applications?

The Project Aims:

The project aims to determine whether or not the .NET platform can be used to develop distributed, cross-platform, n-tier, secure applications (Enterprise-class applications) with an acceptable performance. The results of the project will tell C# developers what steps they need to take to write platform agnostic code and what performance implications these may have.

Project Outline

It is known that not all C# code will run unchanged across platforms. The limits need to be explored and strategies developed for writing enterprise-class platform agnostic applications. The project will describe the .NET platform and explain how the framework can be used to produce cross-platform code using one of the currently available non-Windows CLRs.

Through a literature search, criteria for enterprise-class applications will be developed that will be used to develop benchmark functionality for performance tests.

Performance tests will be carried out that exercise that functionality.
A search will be undertaken for existing enterprise-class platform-agnostic .NET applications. A cursory search suggests that no commercially available, non-Microsoft CLR applications exist that span all application tiers.

An application will be developed using C# consisting of at least three tiers (presentation, business logic, data). It will be used to compare the performance of the same code on Windows and Linux, in a more holistic environment than that provided by isolated tests. Code will also be produced optimised for the two platforms to compare platform-specific code performance compared to platform-agnostic code performance.

Literature Survey / Resources’ List:

The literature survey will cover at least the following:

Software development

A good way of assessing software process management is the Capability Maturity Model outlined at http://www.sei.cmu.edu/cmm/

Cross-platform development:

Microsoft have produced a seminal work on ASP.NET security called Building secure Microsoft .NET applications, and published by Microsoft Press.
A great deal of useful information concerning ADO.NET, remoting and the use of web services is contained in the excellent MCAD Training Guide 70-320: Developing XML Web Services and Server Components with Visual C#.NET and the .NET Framework by Amit Kalani

An interesting overview of portability problems and the role of standards is contained in Standard View Vol 4, No2, Jun 1996 (available from: http://ezproxy.liv.ac.uk:2480/10.1145/240000/235000/p80-rowley.pdf?key1=235000&key2=4874446211&coll=portal&dl=ACM&CFID=54388240&CFTOKEN=78782950)

One method of achieving cross-platform functionality is through the use of Web Services. A useful assessment of the value of Web Services can be found in Journal of Software Maintenance and Evolution: Research and Practice
Volume 16, Issue 1-2, Date: January - April 2004, Pages: 31-50
S. Tilley, J. Gerdes, T. Hamilton, S. Huang, H. Müller, D. Smith, K. Wong – available from: http://www3.interscience.wiley.com/cgi-bin/fulltext/107582371/PDFSTART

Technology-specific resources

The .NET Framework specification.

There is a great deal of literature on this subject including the literature provided by Microsoft at http://msdn.microsoft.com/netframework/gettingstarted/default.aspx and the ECMA standards linked to from http://msdn.microsoft.com/net/ecma/
Similar information is available from mono at http://www.mono-project.com/.NET_Framework_Architecture

.NET technologies

Many books and web sites deal with specific .NET technologies:

• The C# programming language
• ASP.NET
• Development tools

Many resources are available for Microsoft's Visual Studio, including a wide variety of books, online help materials and web resources (especially MSDN).
Fewer resources are to be found for mono development environments, but some documentation is available for monodevelop, both online and on the web at http://www.monodevelop.com/tutorial.aspx

Resources specific to mono and other non-Microsoft implemetations

There are a growing number of mono-specific and cross-platform resources

Books

Dumbill, Edd, and Bornstein, Niel M., Mono: a developer's notebook
King, J., and Easton, M.J., Cross platform .NET development: using mono, Portable.Net and Microsoft .NET.
Geschwinde, Ewald, Mono kickstart.

Websites

www.go-mono.com
www.gotmono.com
www.cross-platform.net

Scholarly Contributions of the Project:

It is known that C# code compiled to CIL will run on any computer where a CLR is installed: just as Java code will run wherever there is a JVM. However, ECMA standards for C# do not, on a first examination, appear to cover every aspect of what a Windows programmer would associate with the .NET Framework programming environment. For example remoting does not appear. Is remoting possible, therefore, in a platform-agnostic environment? A technique called direct remoting may be a possible solution, but the infrastructure of SAOs and CAOs available under Windows is not available elsewhere.

The project will make the following contributions to knowledge:

• benchmarks for enterprise-class application functionality
• test results from the application of these benchmarks in code snippets and in a full application
• a set of standards that can be consistently applied in order to develop platform agnostic code
• advice to developers of non-Microsoft CLRs as to where their efforts might best be concentrated.

Description of the Deliverables:

The deliverables will include:

• A survey of relevant literature
• A comparison of the facilities available to developers under Microsoft .NET and under other .NET implementations
• An example application, code samples and performance test results
• A recommended, reproducible framework to follow when developing a cross platform product, intended for enterprise deployment
• Summary and conclusions

Evaluation Criteria:

The features of a complete .NET implementation should be enumerated and their presence or otherwise in other implementations set out. This will be achieved by comparing the features of implementations with those set out in the ECMA standards documentation, and in the Microsoft .NET Framework.

Code samples and a .NET application will be developed in sufficient detail to determine the ease or otherwise of running it, unchanged under Windows and Linux, and the performance implications of doing so.

Resource Plan:

A dual boot PC will be required running Windows 2000 or better with IIS 5 or better, the .NET framework and Visual Studio.NET; and SuSE Linux 9.3 or better with Apache2, mono 1.1.7 or better.

All these resources are available.

Risk Assessment:

All the necessary hardware and software is available. I also already possess the necessary C# programming skills, as well as experience in .NET programming in a Windows environment.

A risk would be a failure to install all the necessary mono components successfully.

Most of the risks in this project are actually opportunities. A failure to implement some functionality in non-Microsoft environments should contribute to the understanding of the platform's completeness and maturity. A failure to install some component would also contribute to an understanding of the problems likely to arise in cross-platform development.

Quality Assurance:

I intend to monitor the project using the Imendio project planning software included with SuSE Linux. The basic framework has already been produced and will be updated and refined as the project progresses.

OK, let's see what this blog thing is all about.

I'm starting a blog to try to record my progress as I struggle to write a dissertation for my MSc degree in IT. The project is about writing cross-platform code in C# for the .NET virtual machine. I'll post the project proposal next.

If all goes well, whoever reads this will be able to share my joy when the project passes, sometime in late spring/early summer of next year (2006). If it doesn't go well... But let's not think about that.

Writing an academic paper is something completely new to me, so you can imagine that I'm fairly worried about it - and I could worry for Wales. If everything works out, though, my hope is that the final document will be useful; both to C# programmers who are considering writing for more than just the Windows platform, and to the people who are performing miracles implementing free versions of the .NET Framework.

My prejudices are towards free software, but of course I can't let those prejudices influence what I find. I can, though, GPL the code for the test application necessary for a successful completion of the project: and I will. But more of that later.