Sizing the console

OK, so once in a while I have to work just on a plain old console on one of my linux machines. But since there is this neat 22″ monitor on my desk it hurts to see to see the default-resolution of 640×480 pixels.

So how to alter the default resolution, when you’re not using any graphic window manager thingy?

I have a recent version of Debian running, so I use grub for managing my boot-menu.

To change the resolution the easiest way is to go the /etc/default/grub and edit the commandline settings:

GRUB_CMDLINE_LINUX_DEFAULT="vga=0x0305"

This will give you at least 1024×768 with 256 colors! (A decent list of codes to use can be found at www.pendrivelinux.com).

Getting fluent

The case

OK, so I worked around the first issues with the setup of the NHibernateIntagration facility and fluent NHibernate, and now are new issues just showing up.

So I wrote my first mapping:

public class AccountMap : ClassMap<Account>
{
public AccountMap()
{
Id(x => x.Number).GeneratedBy.Assigned();
Map(x => x.Name);
}
}

This looks pretty slick – in fact this is looking so darn cool, I want it to work!

But what is showing up in my testrunner is not very re-assuring: No persister found for Entity Account.

What the hell?!

The setup

So what happend so far? After getting my solution ready to compile, the next step is to add the fluent mapping to the current NHibernate configuration. Since the configuration is being created within the integration facility this doesn’t seem trivial. But actually, taking a closer look, this isn’t that complicated:

<facility id="nhibernate"
isWeb="false"
type="Castle.Facilities.NHibernateIntegration.NHibernateFacility, Castle.Facilities.NHibernateIntegration"
configurationBuilder="FluentConfigurationBuilder, Core">

The key is the configurationBuilder. This offers a hook in the configuration-building-process of the facility.

Next step is to implement the configuration-builder:

public class FluentConfigurationBuilder : IConfigurationBuilder
{
public Configuration GetConfiguration(IConfiguration facilityConfiguration)
{
var defaultConfigurationBuilder = new DefaultConfigurationBuilder();
var configuration = defaultConfigurationBuilder.GetConfigutation(facilityConfiguration);
configuration.AddMappingsFromAssembly(Assembly.LoadFrom("Core.dll"));
return configuration;
}
}

This is the recommended route to read the fluent mappings from the assembly and to add them to the NHibernate configuration. The key is the AddMappingsFromAssembly extension-method.

So, this is where I stand right now – and this is failing.

The solution

Looking at the source of the fluent NHibernate extension-method AddMappingsFromAssembly reveals some truth:

public static Configuration AddMappingsFromAssembly(this Configuration configuration, Assembly assembly)
{
var models = new PersistenceModel();
//models.AddMappingsFromAssembly(assembly);
models.Configure(configuration);
return configuration;
}

So there it is – black-on-white: the actual mapping is commented out – and no-one knows really why.

Ok, so my current (and working) code looks like this:

public class FluentConfigurationBuilder : IConfigurationBuilder
{
public Configuration GetConfiguration(IConfiguration facilityConfiguration)
{
var defaultConfigurationBuilder = new DefaultConfigurationBuilder();
var configuration = defaultConfigurationBuilder.GetConfigutation(facilityConfiguration);
var model = new PersistenceModel();
model.AddMappingsFromAssembly(Assembly.LoadFrom("Core.dll"));
model.Configure(configuration);
return configuration;
}
}

Everything is fluent

Since fluent is just everywhere, I thought that I would have to go the fluent NHibernate road as well. Turned out to be quite wacky.

First of – I just wrapped up all my referenced assemblies: Castle Windsor 2.0 (which is actually internally labeled as 1.1) as well as all the other stuff and NHibernate 2.1 GA. Then adding the new kind in town: Fluent NHibernate.

And this is where the trouble begins … Fluent NHibernate is build against 2.1.0.4000 of NHibernate (= 2.1 GA). This is good, since I just downloaded this exact version. But wait – what’s my most favorite NHIntegrationFacility doing there – it’s actually linked against 2.1.0.1003. So this screws me off.

OK – don’t panic! Fortunatly .Net has the ability to redirect assembly bindings. Just a little bit of tweaking in the app.config does the trick:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NHibernate" publicKeyToken="aa95f207798dfdb4" culture="neutral" />
<bindingRedirect oldVersion="2.1.0.1003" newVersion="2.1.0.4000"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

Looking at the binding

Sometimes programs just don’t behaive the way the’re supposed to. This is the time you need to bring in heavy machinery.

One hint is to look at the actual assemblies being used. I happend quite a few times, when some unexpected assemblies where being used. The easiest way to achive this is by looking at the binding log of .Net.

This can be done, by turning on the Fusion-Log in the registry at HKLM\Software\Microsoft\Fusion\ForceLog and setting an appropriate path at HKLM\Software\Microsoft\Fusion\LogPath. The logs can then be inspected with the Assembly Binding Log Viewer.

Executing SharePoint commands on the prompt

The STSADM tool provided by Sharepoint offers almost all features, which are available through the central administartion of Sharepoint (if not more!). This is especially useful, if you’re scripting certain actions, so you can do massive changes to your Sharepoint environment in a save way.

But once in a while, when you’re issuing commands via STSADM you might notice that they seem not to be carried out right away. Especially when deploying Sharepoint Solution Packages (.wsp) this can lead to unexpected errors. Assume you add a solution to the solution-store of sharepoint and want to deploy that solution globally:

STSADM -o addsolution -filename mysolution.wsp
STSADM -o deploysolution -name mysolution -immediate

Looking at the solutions in the central administration might show ERROR. But why? What did go wrong? Central administration doesn’t offer any further clues.

To get to the root cause you have to know how Sharepoint is actually handling the commands issued via STSADM. These commands are being queued and then asynchronously processed. This processing is done by a corresponding service. In some circumstances this service might not be running – most likely because it’s set to start manually instead of automatic.

So switching this service from manual to automatic should do the trick. But to be really sure, that the commands are being processed you can instruct STSADM to execute all currently queued commands right now. This is useful for instance in the example shown above, where the second command can only be processed after the successful completion of the first. So the solution might look like this:

STSADM -o addsolution -filename mysolution.wsp
STSADM -o execadmsvcjobs
STSADM -o deploysolution -name mysolution -immediate

BSOD: Logon Process

I haven’t had a real nasty blue screen of death for the longest time – so I was long overdue.

During some housekeeping of my laptop I decided to get rid of some apps and then to my surprise I got a nice BSOD as a reward for cleaning out my harddisk.

I took me quite some time to get my head around this. Turned out, that one app was a little too eager to clean out stuff and removed some DLLs that where essentially needed by the logon-process.

BSOD

Thank goodness I recently made a virtual image of my machine and still had an old copy of a BartPE image around. So just fire up BartPE, compare the contents of c:\windows\system32\ with the contents of my virtual image – and there were about a dozen DLLs missing.

A couple of hours later I had the missing DLLs back in place and … my machine is running again. I think this will put me advance for quite a while as far as BSOD are concerned.

Installing Bluetooth Peripheral Device

I thought, that I had my HTC Touch Pro, Vista x64 SP2 and Outlook 2007 all set up – and then come some stupid update and everythings seems to be back to start.

After switching on bluetooth on my laptop I get a nice looking Vista dialog stating “Installing Bluetooth Peripheral Device” – NOT! I mean, Vista couldn’t find an apropriate driver 🙁

OK, so there is help; you just have to do it yourself.

  • ignore the failing “Installing Bluetooth Peripheral Device” dialog
  • open the device manager and open the properties for the not corret installed bluetooth device
  • select “reinstall driver” and select to manually supply the driver
  • browse to “Microsoft Corporation” as the manufacturer (beware: there is also just “Microsoft”, which doesn’t do!) and the select either Windows Mobile 6.0 or 6.1

that all – why can’t Vista do all this on his own?

Live Writer is language sensitive

So I though I take a look at Windows Live Writer (since it’s called Essentials it sound as you gotta have some). But vanilla is just not my style I immediately looked at the Live Writer Gallery.

But just to figure that there are no plugins available?! I just couldn’t believe my eyes!!

OK – so switching the language-preference of my browser from german to english helped a lot – seems like Microsoft doesn’t want them germans to get any plugins 🙁