Archive for January 2007
The NAnt buildfile is part of the source if you want to build it yourself (use the release or debug target.) The buildfile is still a little raw, but it does what’s needed right now.
I haven’t tested the mono version on Windows, so it may not work.
Want to be able to launch a terminal window from the current directory in Ubuntu? I did. Read this. Problem solved.
I ran into another issue with the nspectre Mono adventure I posted about yesterday. In order to load the assemblies in the bin folder, I passed the Location property of the assembly of a given type (ResourceLocator in this instance) to the constructor of FileInfo. I then used the Directory property to get a DirectoryInfo object with the intention of looping through the files in said directory. I was able to do this but the location of the directory was /home/user/files:/home/user/somefolder/someotherfolder (you get the gist.) As a short term measure I wrote a line (or two) of code to strip out the colon and all that precedes it. So I succeeded in getting it to work, but I’m sure there’s a better way or that I’ve missed something.
I have to say that I am mightily impressed by Mono. When I think of what nspectre is doing, only running into one real issue (Assembly.Load) is quite something.
Over the last couple of days I’ve got nspectre working under Mono. I hope to be able to release a patched version later this month. Here’s how I got it to work. I installed NAnt 0.85 on Ubuntu 6.10 (which I run in Parallels.) I found this link via Cory Foy that shows how simple it is to install NAnt on Mono.
UPDATE: At this point I built TemplateEngine. I used MonoDevelop to build it – no issues to report.
With Nant up and running, I created a build script for NSpectre. To get started, the build script only builds NSpectre.Core, NSpectreExample and NSpectreExample.Entities. Once I had these compiled (on my set up, the csc task in NAnt targets gmcs by default – very impressed), I ran them.
And ran into problem number 1. It appears that Mono implements Assembly.Load differently to .NET. See here for further detail. As a short term fix, I modified ResourceLocator by adding a type initialiser to load all assemblies in the bin directory. I’ll take another look at this, there may be a better way of doing it, but for now it works.
Problem number 2. I set NAnt to use dynamic prefixing for the resources. The namespaces it uses are different to those that VS .NET would use – VS .NET would use the project namespace as the root namespace, whereas Nant uses the name of the folder that contains the project (for subfolders the behaviour is the same.) Pretty easy to fix – modified references in code and config files to use the NAnt generated namespaces.
Problem number 3. One hardcoded (a constant) backslash (used in Engine.) Oops. Modified to a forward slash for the purposes of getting it to work.
Problem number 4. NSpectreExample uses Win32 API calls to change the foreground colour of the console (.NET 2.0 supports this in managed code, so this won’t be a problem in the future.) Unsurprisingly, Win 32 API calls don’t work in Linux. So, I commented these lines out for now.
And that’s it. OK, so there were a few more issues along the way. But the other issues were about getting the build script “right” – in this case getting the csc tasks to build nspectre as closely to the way VS .NET does as possible.
So, a little more investigation, some minor modifications, some clean up of the build script and I’ll be able to release a Mono’ed version of nspectre.