Runtime mapping of ASP.NET configuration settings - a new Mono feature

Recently, I've added a new feature to the Mono ASP.NET stack which allows one to modify the configuration settings on the application runtime, based on the operating system the ASP.NET application is executing on. This feature is Mono specific and is currently avaliable only from the svn trunk.

Why is it useful?
When developing ASP.NET applications which may be ran by the end user on either MS.NET/ISS or Mono/XSP/mod_mono, one may face a limitation of the .NET configuration system - the lack of conditional configuration constructs. Being unable to use different configuration settings for different operating systems/platforms, means that most of the time it is necessary to provide separate set of config files for every operating environment that differs to the other ones we support.

One example when such need arises is the usage of the WebParts feature of ASP.NET 2.0. As you may know, Mono currently does not support that feature and so applications which can optionally use it (like, e.g. MojoPortal) need to ship with a special configuration for Mono which excludes the WebPart configuration settings. Using settings mapping, it is possible to ignore the configuration sections related (and unsupported) by Mono.

Another, perhaps more common, scenario are file paths used in the Web.config file. Windows and Unix use different directory separator characters, Windows supports drive letters while Unix does not use them, a different character is (by convention) used to separate PATH-style variables under Windows (:) and Unix (;). While all those differencies can be dealt with easily in the application source code, it is not so for configuration files. A custom settings mapper can take care of the adjustments for you, seamlessly modifying "canonical" file paths used in the config file to the operating system the application runs on.

There's a pretty extensive document on how to use the feature in your application at http://mono-project.com/ASP.NET_Settings_Mapping

AJAX Control Toolkit: broken samples work now

Since the last update I have fixed all the remaining bugs and all the samples work now just the way they do on MS.NET. To run all the Toolkit samples, you will need mono from svn trunk, at revision 85628 or newer. As a reminder, the samples that didn't previously work were:

• CascadingDropDown. The reason it didn't work was that Mono's WebServiceParser incorrectly treated the paths passed to it.
  
• Filtered TextBox. The reason this one didn't work was a problem in the way TemplateControlCompiler treated arguments of type Type in the GenerateObjectInstance method: it would generate code to instantiate an internal type System.MonoType instead of the (correct) typeof expression.
  
• HoverMenu. Fix for this one was a change in the logic which dealt with controls inside templates (see this post)
  
• ListSearch. This one required implementation of the System.Web.Extensions.Design assembly as well as a few missing pieces of the System.Design one. I've added stubs for all of the missing pieces to mono svn trunk.
  
• NumericUpDown. This one was made to work by the same WebServiceParser fix mentioned above.
  
• ReorderList. Frankly, forgot what fixed this one :)
  
• AutoComplete. This sample deserves a special mention. It still doesn't work for me, but Daniel Nauck reported it works for him with FireFox 2, Opera and IE7 on both Windows and Linux, with Mono from svn trunk. So I'll assume it works too and that there's some client issue on my side.

Shown below is a screencast demoing all the above samples (except for the AutoComplete one, of course). You will also note a JavaScript error at the end of the screencast - it happens every now and then, but it is probably a glitch in FireFox (at least in my copy) and it doesn't affect the demo:

Linux+Gnome on TV?

Whenever I watch a movie or some TV series and they show a glimpse of a computer screen, I like to freeze the picture and take a look at what it might be (and how credible what they show is, sometimes :D). Recently, I've started watching the Numb3rs show and in the 2nd episode of the first season (Uncertainty Principle) one of the main characters, a genius mathematician, explains a certain search pattern to his colleague from the University using the well-known Mines game. When I saw the sequence, what was on the computer screen seemed familiar, so I froze the frame and I think what you see on screen is GNOME (my guess is that the OS is some version of Ubuntu), here's the screenshot:


Even though it is definitely not the version of Mines shipped with Gnome, I do think the notebook is running Linux. Cool :)

Update:
Most people seem to think it's MacOS/X, but I'm still not convinced (being stubborn as I am) :)

Update2:
It seems it really is MacOS/X... oh well :) Will keep trying!

AJAX Control Toolkit Update: what doesn't work

Since yesterday, the following samples started to work:

• HoverMenu. The result this one wasn't working was twofold. First, there was a bug in our implementation of TemplateControlCompiler which incorrectly exposed all the controls contained in a template marked with the TemplateInstance.Single attribute if any of template children was marked that way. The correct action is to expose only those controls which are either direct children of such template or whose parent containers are templates themselves (unless the parents bear the attribute, of course). Fixed in svn commit to revision 85473. The second problem was non-portable coding in the Toolkit itself. To make the sample work you need to modify the App_Code/TodoXmlDataObject.cs:

  
  Line 92 should read:
  get { return Path.Combine(RootPath, String.Format ("App_Code{0}TodoItems.xsd.orig", Path.DirectorySeparatorChar)); }
  
  Line 204 should read:
  get { return Path.Combine(RootPath, String.Format ("App_Data{0}TodoItems.xml", Path.DirectorySeparatorChar)); }
  

  On line 92 the TodoItems.xsd.orig should be the name of the file you renamed TodoItems.xsd into.
• FilteredTextBox. This one will work if you modify code starting at line 47 in the FilteredTextBox/FilteredTextBox.aspx file and remove either the Custom or the Numbers string together with the comma from the value of the FilterType attribute. It is not, of course a fix, but a workaround to show that the sample does (generally) work. Fix will come soon.
• AutoComplete. It has every right not to work, because it doesn't work when the toolkit is running under MS.NET either. The webservice works correctly (which you can confirm by visiting http://localhost:8080/AutoComplete/AutoComplete.asmx directly).

The rest of the fixes must wait till after the weekend.

AJAX Control Toolkit on Mono

As some of you probably already know, thanks to great work by Mainsoft we can run Microsoft AJAX applications with Mono from svn trunk now. As long as the System.Web.Extensions namespace is almost complete, there were missing (or buggy) bits and pieces inside the System.Web assembly provided by Mono.
In the past two days I've been implementing the missing and fixing the buggy code to get the AJAX Control Toolkit running without modifications under Mono. Today it works nearly in 100%!
There are few things that don't work, but I'll leave it for later, since first I want to present a small screencast showing that the toolkit does run under Mono :)

The screenshot below shows that the toolkit is indeed ran under Mono's XSP (weak proof, but what's a blogpost without graphics, eh? :D):


The screencast below shows some of the demos in action (some demos don't work, see further down the page).



What doesn't work (and why):

• AutoComplete. There's a problem with the remote service, haven't checked what is the problem yet.
• Cascading DropDown. Another problem with the remote service, also not checked for details yet.
• Filtered TextBox. The sample throws a weird parser exception, will take care of it soon.
• HoverMenu. Throws errors about duplicate controls.
  
• ListSearch. Throws a NullReference exception.
• NumericUpDown. This one works in all cases except the one which uses a web service.
• ReorderList. Depends on the existence of the TodoItems.xsd file which I had to remove (see below).

All the other samples work without problems. I'm going to take a look at the failing ones tomorrow and, hopefully, make them work.

There's one other issue you need to keep in mind if you want to test the toolkit on your Linux machine: the Mono's XSD generates invalid code from the TodoItems.xsd file that comes with the toolkit. To make the sample website work, you must generate the .cs file from the above .xsd with the .NET version of the tool:

xsd TodoItems.xsd /c

then put the result file in the SampleWebSite/App_Code directory and rename the TodoItems.xsd file to, for instance, TodoItems.xsd.orig

At this point you should be able to play with the demos.

New mod_mono/xsp in 1.2.5

Unlike stated in the previous post, the changes described there will make it into Mono 1.2.5 as they turned out to fix more bugs they were intended to (wish me more fixes like that!). mod_mono and xsp were copied from svn trunk and are part of the 1.2.5 Preview 4 release.

New mod_mono and xsp developments

It's been a while since I blogged. The reason for this is simple - all the work I've done on ASP.NET in the past weeks was bugfixing and most of it wasn't blog-worthy. But recently a couple of important bugs were closed which resulted in several nice feature additions to mod_mono and XSP.

One of the important bug fixes was a modification to Mono assembly shadow copying code. We had a race condition that showed up when one thread was shutting down an application domain and another would be starting a new one. The latter would overwrite the shadowed assemblies which would cause the former to throw an exception about invalid opcodes present in the assembly. The fix was to introduce an internal AppDomain serial number which would be unique for each new domain. The serial number is then used in generating the names of shadow copy directories. That way, even for the same application, new AppDomain created by the same application, with the same root directory, setup etc. (e.g. an ASP.NET hosting domain) saves its shadow assemblies in another target directory.

Another bug was reported to happen on ASP.NET sites powered by Apache/mod_mono. The problem was another race condition which occurred in the request startup/teardown sequence inside the Mono.WebServer assembly (shared by both xsp and mod_mono backends). The race was in the assignment and release of request ids which sometimes ended up reused even though the original request with that id wasn't done yet. The solution was to introduce a few lock statements in the code as well as an delegate way of releasing the request id in the code using Mono.WebServer.

The third bug was reported by a Mono user running a very busy website which triggerred the behavior described in the paragraph above, but also exhibited problems with memory consumption for the long-running mod_mono backends. We haven't solved the memory consumption problem yet (it's probably related to the GC), but as part of workaround for the issue we implemented set of options and features for mod_mono which make sites with such problems more robust. I will enumerate and shortly describe the features below.

Startup optimization

mod_mono used to start the backends in the child init hook, which is called after apache forks a new child and has already switched from the root user to the target user/group named by the User/Group directives, respectively. The problem with this solution was that if we had 5 child processes, then 5 copies of mod_mono would launch that many backends simultaneously. Eventually all but one backends would die, but the initial impact on performance would be quite severe. New code moved the backend launch to a server init hook function which runs when apache is still executing as root (i.e. in the main apache process). The code looks up the User/Group directives and switches temporarily to the defined uid/gid in order to launch the backend. That way the vhost backends are launched only once.

To lookup User/Group properly, mod_mono must be loaded after the two directives in the apache config.

The dashboard

The dashboard is a shared memory area which stores information about all instances of mod_mono backends. Each virtual host has its own dashboard, so the performance impact of one vhost's dashboard locking is none for the other vhosts present in the server. The dashboard is used by mod_mono to synchronize (re)starts of the backends so that only one copy of mod_mono stops or starts the backend (Apache can run several sub-processes each of which loads its own copy of mod_mono). The dashboard is also used to store accounting information used by the auto-restart feature described below.
In order to synchronize access to the dashboard, mod_mono must be able to acquire a lock before accessing the data. By default it uses whatever the underlying Apache runtime chooses, but there are cases when it might fail on some systems. Should such event occur, you can use the MOD_MONO_LOCKING_MECHANISM environment variable to specify one of the available mechanisms. For the list of currently recognized ones, please consult the mod_mono manual page (man mod_mono)

Auto-restart

If your mod_mono site uses patterns which make Mono allocate large amounts of RAM, and the site is busy enough for the Mono garbage collector not being able to free enough memory on time, you can configure mod_mono to restart the backend(s) automatically based on two criterions: backend uptime or the number of requests served. The feature is configured on a per virtual host basis. Configuration is done by means of three Apache configuration directives:

• MonoAutoRestartMode. This directive selects the restart mode and can take one of three values: None (default, no automatic restarts are done), Requests (restart after the given number of requests) and Time (restart after the backend has been up for the specified period of time)


• MonoAutoRestartRequests. Specifies the number of requests after which the backend should be restarted. Defaults to 10000 requests.


• MonoAutoRestartTime. Specifies the minimum uptime after which the backend will be restarted. Takes values in the generic format DD[:HH[:MM[:SS]]]. Defaults to 12h (00:12:00:00)

If your site stores data in the ASP.NET session storage, you must make sure that you use out of process session storage, since the in-process data wil l be destroyed when the restart occurs.

Lamentably, the changes described above will not be part of the upcoming 1.2.5 release of Mono. You need to use the svn trunk versions of mod_mono and xsp in order to take advantage of them.

Hack week @Novell

This week all of us working at Novell are free to work on any pet project we want. Together with several other folks, I am working on implementing desklets using the recently developed Moonlight - a port of Silverlight. So far it's been an ejoyable experience and we already have several desklets implemented :)

Mono 1.2.4 - the best ASP.NET 2.0 release so far

With Mono 1.2.4 released, the ASP.NET 2.0 support is nearly complete (with the exception of WebParts and the management APIs) and what we're looking into now is making sure all the little incompatibilities, missing APIs etc. are added and tested.

As part of this effort, I've recently tested all the non-data samples in the .Net QuickStarts set (available either online at http://quickstarts.asp.net/ or with the .NET SDK) and fixed quite a few little bugs or incompatibilities. Unfortunately the changes aren't part of the Mono 1.2.4 release but, as before, I recommend that you use the svn trunk version of Mono (or a daily snapshot) for your 2.0 development and testing. The data controls will be tested as soon as we update our SqlClient implementation with some features that'll help in the testing.

A note about testing the QuickStarts with xsp2 on Mono. The online QuickStarts site uses probably virtual directories in IIS to make sure that the samples which are fully-contained applications get their configuration and paths right. If you run xsp2 in the aspnet/ QuickStarts directory and notice that some don't work, just go to their source folder and run xsp2 from there.

Currently, again as part of the .NET conformance testing, I'm porting several ASP.NET 2.0 applications (starter kits and others) to use PostgreSQL instead of MS SQL - this will allow them to be fully hosted on Unix. I will blog about the ports as they happen.

ASP.NET progress update before 1.2.4

It's been a while since the last update, and I think it's worth mentioning that ASP.NET 2.0 support in Mono will get much, much better with the upcoming 1.2.4 release. The release notes contain a bit of information but there is a lot of little changes hidden behind the bigger ones. Most of work in the past months went into fixing small incompatibilities that were popping out all over the map.

One of the most important highlights of the next Mono release as far as ASP.NET is concerned will be, in my opinion, the fixing of an XSP problem with overlapped requests that resulted in exceptions thrown and requests failed. It took a fair amount of testing to pinpoint that one, but it's gone. In addition, ASP.NET performance has doubled for 2.0 applications, mainly thanks to getting rid of heavy-weight code to detect whether the visiting browser supports JavaScript.

The new code relies on the idea that the browser's UserAgent string (as unreliable source of information as it is - but we have no other choice) can be used to detect similar browsers with enough accuracy to "check" if JavaScript is there or not. New utility, called cuplevel (CompileUplevel) was added which takes an XML description of JS-capable browsers and compiles it into ugly, but fast, matching code. The code is able to match over 90000 of unique UserAgent lines in less than 0.02s, which is quite fast.

To make sure that our JavaScript scripts still work correctly, the checks for ECMAScript and W3C DOM capabilities have been moved from the class library to the scripts themselves (where they really belong). This may result in small parts of the script not working on certain browsers, but the rest of the script will continue working - unlike previously when no script was ever output to the client if the class library failed to detect that ECMAScript is supported.

In a word - do try 1.2.4 when it's out (or even grab a copy now), test it with your favorite 2.0 application and file reports on any bugs (even the smallest ones) you can find!

ASP.NET - convert a physical path to virtual path

I've seen this question asked several times on forums with many different answers provided. Here's another way to achieve that goal.

If you are 100% sure that your file is below your physical application root, you can just do the following:

virtualFilePath = physicalFilePath.Replace (HttpRuntime.AppDomainAppPath, "/").Replace (Path.DirectorySeparatorChar, '/');

A TODO list application for GNOME?

I use Tomboy to keep my todo list around, but it requires me checking the notes manually which makes it easy to actually forget to do something. So, my question is - does anyone know of a small, compact todo list application that supports date/time alerts, notifications, prioritizing and categorization of entries? Tomboy has some of it, but I'd rather use an app created specifically for the purpose of managing such a list. If you do know such a program - please let me know!

A cool un(der)documented feature of ASP.NET 2.0

A few days ago, by way of this bug report, I have learned about a cool ASP.NET 2.0 feature which allows one to extend the Page directive with custom attributes. It is briefly described in this blog entry, but I have investigated the matter a bit farther and discovered a few more details about the feature, see the description below.

Extended attributes are supported for both the Page and the Control directives. If your page inherits from a certain base type, by specifying the parent class name in the Inherits attribute, you can assign any public field or property in the base type by specifying its name in the directive attributes, like so:

<%@Page CustomAttribute="My text" Inherits="BasePage" %>
<%@Control CustomAttribute="My text" Inherits="BasePage" %>

The value of the attribute can be anything the field/property type can be converted to. The conversion is done using the TypeConverter class, with the help of TypeDescriptor class.

As of svn revision 74734, the support for all of the above is in Mono.

ASP.NET 2.0 progress update

I've just been thinking about providing a periodical progress update on ASP.NET 2.0 support in Mono for users that don't track the svn commits and would like to know what will be coming with the next Mono release. So, from time to time (when something interesting/important changes in our ASP.NET implementation) I will blog a short summary of the changes here.

In the past 10 days there have been several significant changes committed to svn head, here's a summary:

• Support for sitemap localization
  
• Source code generated from the aspx and ascx files now implements the same split class model what MS.NET. It prevents problems with code-behind clashing with the generated class.
• Application themes work properly for all controls now.
• An initial support for asynchronous pages has been added
• Fixes for the local resources (App_LocalResources) support. Mono now correctly handles local resource requests for custom controls. Resources are compiled on demand during the parsing phase.
• XmlSiteMapProvider now supports custom site map providers for nodes.
• App_Code support fixes. It is now possible to load custom providers, register tag prefixes whose implementations live in App_Code.

Personal Web Site Starter Kit fully functional now

Recently I blogged about the Personal Web Site starter kit (here and an update here) and mentioned that it was not fully functional due to problems with our implementation of the SqlClient (and, as it turned out, missing features in our Tds code). Since today this is no longer true - thanks to Andreia and Nagappan PWS is fully functional when running under  Mono now! Below are instructions on how to run the starter kit yourself.

1. Download the kit
2. Check out the InstallVST utility from Mono SVN (it's in mcs/tools/installvst) and compile it:

   gmcs installvst.cs

3. Unpack the PWS zip file to some directory
4. Run the following command:

   mono PATH_TO/installvst.exe PATH_TO_PWS_DIRECTORY/ PersonalWebSite.vstemplate PATH_TO_TARGET_DIRECTORY

5. Go to the PATH_TO_TARGET_DIRECTORY/PersonalWebSite/ directory, edit the web.config file you find there find the Personal and LocalSqlServer connection strings and replace their connectionString attributes with, respectively, the following values:

   Data Source=XXX.YYY.VVV.ZZZ;Integrated Security=False;Database=startkit_personal;User ID=sktest;Password=sktest
   Data Source=XXX.YYY.VVV.ZZZ;Integrated Security=False;Database=aspnetdb;User ID=sktest;Password=sktest

   Substitute the XXX.YYY.VVV.ZZZ strings with the IP number of your SQL server

 
Having completed the above steps, you need to prepare your Microsoft SQL server (either the full version or SQLExpress) for use with the starter kit. Follow the instructions below:

1. Make sure your SQL server uses mixed SQL + Windows authentication, allow connections over TCP/IP (server port 1433)
2. Create an SQL user named 'sktest' with the password 'sktest'
3. Create an empty database named aspnetdb, then fill it with required schema using the aspnet_regsql utility that comes with Microsoft .Net 2.0 SDK. This database can be shared among all the starter kits ported to Mono. Add the 'sktest' user to this database users and make it the database owner.
4. Create an empty database named startkit_personal, then use personal-add.sql script found in the PWS zip archive to populate it with the necessary schema and data. Add the 'sktest' user to this database users and make it the database owner.

At this point you are ready to run the application. To do so, issue the following command on your mono machine:

MONO_IOMAP=all xsp2 --root PATH_TO_TARGET_DIRECTORY/PersonalWebSite/

and then point your browser to http://localhost:8080/ (replace 8080 with the port number your xsp is configured for).
If everything went well, here's what you should see in your browser:

The welcome screen

The welcome screen after logging in

One thing should be noted about the user registration with this starter kit. The application is configured so that every new user is created in the disabled state - that is, you will not be able to log in even though the user has been created successfully. To remedy that, you have two options:

1. Edit the Register.aspx file and remove (or set to false) the DisableCreatedUser attribute to the <asp:CreateUserWizard> tag in that file
2. On your Windows machine launch the SQL Server Management application, connect to the aspnetdb database and issue the following query:

   UPDATE dbo.aspnet_Membership SET IsApproved=1

   This query will approve all the users you have registered (if you want to do it for individual users, you need to consult the dbo.aspnet_Users table, look up your user, note its ID and append WHERE UserId=YOUR_USER_ID clause to the above query)

ASP.NET 2.0 page themes

It seems that until now the themes were broken under Mono. I've just committed a few changes that make them actually work. I suspect that there might be more breakage in there, and despite testing them on a few applicatins I'd like to ask anyone who uses/knows of any non-trivial ASP.NET 2.0 applications using themes to let me know where to download them. Also, if you encounter a bug - do fill a report with a test case to the Mono bug tracking system. Please make sure you test the application(s) with Mono compiled from svn head newer than revision 73707

MojoPortal progress - it's really functional now

With the recent svn commit (revision 73669) Mono is now able to handle running MojoPortal with the menu enabled:

You can see the menu just above the Links section on the left. It is bound to a custom site map provider and accessed via a SiteMapDataSource control defined in the associated master page file.

The problem was with the way HierarchicalDataBoundControl looked for data source named by the DataSourceID property. It considered only the control's NamingContainer instead of working up the naming container chain and thus not reaching the associated master page.

ASP.NET temporary directory cleanups

In the past weeks I've committed several changes in order to make the ASP.NET temporary directory a bit less of a space hog for those who restart their xsp/mod_mono often.
The old implementation used to generate random file/directory names for both per-application toplevel temporary directory and all the files below it (including shadow files which can occupy a lot of space on larger sites). The changes I made include, so far, the following:

• Generate a toplevel temporary directory with predictable name. The hash calculation is based on the virtual and the physical paths of the application.
  
• The shadow files no longer have fully randomized names (of the form shadow-XXXXX with the Xs being replaced by hex characters), instead they are put in a subdirectory of the temporary directory named assembly/shadow/XXXXXXXX/YYYYYYYY_VVVVVVVV/ which is different for every shadow-copied assembly.

The way the XXs, YYs and VVs above are generated is that the XXs are a hexadecimal hash of the assembly name (sans the path) - it groups files of the same name in the same subdirectory. VVs are hexadecimal hash of the assembly path (sans the name). YYs are an XOR of XXs and VVs.
The above scheme tries to mimic what MS .Net runtime does (except they use dl3 instead of shadow in the above path), but I can't guarantee that the hashes are computed the same way they do. The way we do it guarantees that no two different assemblies can end up in the same shadow directory and create a name clash - that's sufficient.

The new shadow scheme uses considerably less space, which is very good, and it also adds another benefit - the .mdb (debug data) and .config files that accompany the original assembly are copied together with the assembly.

The remaining temporary directory cleanup issue is how we should remove the old assemblies. If anyone has any information about how MS .Net does that (I haven't investigated the issue yet) - please let me know.

Big news - MojoPortal 2.x runs on Mono!

As in the title - I've just managed to run MojoPortal 2.x (svn head) under Mono's ASP.NET 2.0 (also svn head) for the first time ever! As a proof, here's a screenshot:

Attempt to register the user succeeds, but later on the portal throws an exception about a missing attribute. I will look into it tomorrow and post any updates here. I'm really glad it has finally happened... :)

Joe, congratulations on excellent job with the portal!

PersonalWebSite starter kit update

It is possible to register a user now with the PWS, but the attempt to log in fails miserably. It seems the problem is with the Mono implementation of the SqlClient - it does not process the stored procedure output parameters correctly.

PersonalWebSite starter kit

I've just commited the first asp.net starter kit ported to work with Mono to the Mono SVN repository. I chose PersonalWebSite kit because it seemed to be the easiest one to deal with.
The kit itself was a no-brainer to port (just one change required - a case-sensitivity issue), but while trying to make it work I discovered that Mono implementation of SqlRoleProvider (and SqlMembershipProvider) were broken. The symptom was a parsing error returned by the SQLExpress 2005 server - at first I thought the bug was in the Mono.Data.Tds provider, but as Shana discovered, it turned out to be a problem with the providers mentioned above. The bug was that the providers were setting up stored procedure calls in a wrong way. Andreia fixed it in the current svn head of Mono.
There's one known issue at this point, namely the registration fails to work. It is a problem with our wizard control, which I will be looking into soon.
You can check out the ported starter kit together with instructions from the extras svn repository.

First blog entry ever

Well, it seems this is the end of my blog resistance. Knowing that I will probably be one of the worst bloggers ever I tried to refrain from becoming one, but with the latest change in my life - becoming a Novell employee working on ASP.NET implementation in the Mono team - I should probably fit in and be a good deveblogger.. :)

Anyway, I'll try to blog here about various matters related to Mono in general and ASP.NET under Mono in particular. No promises as to the quality of the entries etc. etc. - complaints will not be accepted :P