I've been working off-and-on with the activation service portion of Algenta's licensing block. I say "off-and-on" because I'm pretty disgusted with the available server technologies right now, and I can only stand to work on it for a couple of hours at a shot, and I can only stand to take another shot every couple of days.
IIS 5.1 stopped allowing me to connect to it with Visual Studio .NET. So far as I can tell, this happened for no reason at all. It acted flakey a couple of times during the short time that I was actively developing the server portion, refusing to allow me to open to the project (although never giving trouble to web service client connections), but a reboot fixed it every time. Then I worked on the client portion for a while, using a solution that did not even contain the server project. Instead, one project referenced the web service, and it connected without a hitch. The time came for me to work on the server portion again. Nothing I tried would allow me to either connect to any existing web service project or to create a new web service project from VS.NET. And, being the detail oriented, methodical type when it comes to problem solving, I've tried a lot.
I've since uninstalled and reinstalled IIS on my machine, and now it seems that I'm going to have to reinstall unknown portions of the .NET 1.1 SDK and/or runtime so VS.NET will recognize IIS has access to the the correct version of .NET.
Really annoying. And time consuming.
Today I had what I hoped would be a breakthrough in another area: Mono on FreeBSD. Now the Mono port is hopelessly out of date, and the newer Mono versions have not been working on FreeBSD for a while. There are a couple of cosmetic issues that are simple to resolve, but the garbage collection is still a show-stopper.
The first cosmetic issue with FreeBSD is that after running ./configure, the referenced libc version found in data/config must be changed from libc.so.6 to libc.so.5 for FreeBSD 5.x and to libc.so.4 for FreeBSD 4.x. The other cosmetic issue only applies when ./configure specifiecies the Boehm garbage collector from the port. The configure utility looks for libgc.so in /usr/lib rather than in /usr/local/lib, which is where the port puts it. Simply adding a symlink to the library in /usr/lib resolves this issue (not in the best way, but...).
As of Mono Beta 3 (version 0.96), using either the included gc or the Boehm gc causes the same behavior: gac assembly registration hangs during installation. Configuration and compilation work as expected (after dealing with the previously mentioned cosmetic issues), but installation fails. This was documented at least as early as Beta 1, and the mono developers don't seem to be worried about FreeBSD compatibility, so I can't say that I was surprised to see the behavior unchanged in Beta 3. In light of some recent reading on the mono-devel list, though, I was a little disappointed.
I've been lurking on the mono-devel mailing list for the past few weeks hoping to see some discussion of the FreeBSD gc issues. Today I was rewarded for my patience. It seems that Mono Beta 3 will install on some FreeBSD systems. And, from the same thread, sometimes deleting a particular scratch directory will fix the hanging installation issue. Having been given new hope, I proceeded to dash it. None of this discussion helped me with my vanilla FreeBSD 4.8 box. Same story, different version.
It was worth a shot.
So I'm left with my previous ideas which are:
Finish fixing IIS 5.1. Hope that it doesn't stop working for no reason again.
Compile Mono on FreeBSD with no gc. Use NuSOAP to create a PHP web service which calls into mono (meaning that a new process spawns every time, reducing memory leaks to a non-issue).
Yeah, it's annoying.