Wednesday, November 08, 2006

Nothing particularly interesting to report, while I'm sitting here watching a custom-built automated test suite chug away (which incidentally takes approximately 5 hours to run... at 100% CPU usage on 1 core... ugh) - I thought I'd muck around with Iron python and base4... my inspiration was this "On the fly" schema creation on the base4 site, however I wanted to just grab an existing assembly (from the server no less) and start using it's types in Iron Python... it's pretty easy (and quite cool, think about the implications of no references, every time you run your app the schema might have magically grown some more features ;o)

Getting Started...

First off, lets fire up the trusty iron python console... I like colours and being able to tab through member lists, so I'm going to throw in some command line parameters...

ipy -X:TabCompletion -X:ColorfulConsole

Cool, consoles up and running so lets get down to business... first things first, loading up the Base4.Storage assembly...

import sys
import clr
sys.path.Add("C:\\Program Files\\Base4 Solutions Ltd\\Base4 version 2.1.1.85")
clr.AddReferenceToFile("Base4.Storage.dll")
from Base4.Storage import *

All done... now before we can do anything useful, we'll need to setup our default connection string (read: default context)...

StorageContext.SetDefault("tcp://Server:@localhost:999/Base4_default")

This is the amiga speaking...

Now the fun begins... if you have System.Speech available, grab that puppy too... because deep down we all know that the thrill of making your computer talk still exists... especially if you started out your days on an Apple or better yet Amiga...

clr.AddReference("System.Speech")
from System.Speech.Synthesis import *
synth = SpeechSynthesizer()

Sweet, now lets view (or listen) for all the available schema assemblies...

for asmFile in StorageContext.FindAll[SchemaAssemblyFile](): 
    synth.SpeakAsync(asmFile.Name)
    print asmFile.Name

Loading the schema...

At this point you'll end up with a list of the assembly files (and hopefully, your machine will be droning away notifying of you just what they're called... ;o) in my case I have a little "Experiment.dll", so lets load that up... I'm pressed for time so I won't be putting in speech detection for selecting the appropriate schema, though it's both entirely possible, and pretty easy to do...

asmFile = StorageContext.FindOne[SchemaAssemblyFile]("Name='Experiment.dll'","")
assembly = experimentAssembly.LoadAssembly()
clr.AddReference(assembly)
from Experiment import *

And yes, the strongly typed schema is now there for me to play with...

The experiment schema contains among other things an "Order" type, which holds a collection of "OrderLine" line's... so we can now do this:

order = Order()
line1 = OrderLine()
line1.UnitCost = 30
line1.NumberOfUnits = 2
order.OrderLines.Add(line1)
order.Save()

I think it makes quite a handy diagnostic tool, especially when you start considering that your dev, test and live environments may all have different schema versions... it could certainly save a lot of stuffing around - it would be fairly tedious to repeat this exercise in C# by comparison (especially once you've written a few useful helper functions in your own "base4" python module... I could shorten this entire post to 3 or 4 lines instead).

posted @ Wednesday, November 08, 2006 9:00:48 AM (New Zealand Daylight Time, UTC+13:00) Comments [0] | Trackback |

Friday, November 03, 2006

IronPython on ASP.Net

IronPython on ASP.Net ?

Yes, that's right... dynamic language support in ASP.Net ... and some interesting things I didn't know existed in ASP.Net already, such as no-compile pages - well worth a skim through the whitepaper here (http://www.asp.net/ironpython/WhitePaper.aspx?tabid=62) - it's an interesting approach to bringing in dynamic language support to asp.net - and would certainly work for ruby on the CLR as well... probably better actually because ruby's statements are balanced and so you have less problem with whitespace.

Speaking of the deadly space that is white, It will be interesting to see if they've dealth with this horrible python integration issue at all...

I haven't seen any evidence of whitespace agnostic additions in the sample code that's been posted, so I'm guessing not... in which case there may be tears before bed time for some developers who want to do quick-and-dirty asp-like code (which I see is one of the advantages of using a dynamic language in this situation) ... As it all tends to blow up in your face when your tabs are slightly out of line - something which visual studio might just do for you when it feels like shuffling your html ;o)

I'm not sure how easy it would be to introduce a whitespace agnostic mode in IronPython for ASP.Net (Boo's whitespace agnostic mode, as used in Brail is quite elegant... the alternative is to do something like the spyce framework, using opening and closing braces... which just looks mucky to me because you end up with stuff like this:

[[ if display:{ ]]
<strong>something here</strong>
[[ }else:{ ]] 
<strong>nothing here</strong>
[[ } ]]

Seems a bit too noisey... the "if display:" is enough to know you need to locate a matching closing block, so adding a construct like "end" should do the trick... which is how it's done in Brail...

<%if display:%>
<strong>something here</strong>
<%else:%>
<strong>nothing here</strong>
<%end%>

As clean as...

.Net | IronPython | asp.net

posted @ Thursday, November 02, 2006 9:29:50 PM (New Zealand Daylight Time, UTC+13:00) Comments [0] | Trackback |

Thursday, November 02, 2006

News...

Castle goes RC2

Well it's an exciting week for Castle users, RC2 is out the door, and with it a new website look and feel with up-to-date content, and most interesting to me is the introduction of a new entity "CastleStronghold" a commercial venture, run by Hammet which offers professional support for developers and organisations implementing solutions in Castle, including guaranteed response times to inquiries and access to additional skilled development resources.

Personally Castle Stronghold is great news, as a developer for a company which has been using the Castle IoC for over a year now it adds a certain weight to our decision to run with this technology, and I think it offers a clear indication of the longevity this technology and product has... In time as our customer base grows it certainly looks appealing to have guaranteed support backing us up - and also helps customers to understand it's not some half backed open source project that's just going to fizzle out one day...

The RC2 release itself is exciting from a community point of view, it should be better then ever for people to pick up and play with this stuff - though we generally use interim snapshots of the trunk (ie. the last trunk release that didn't break our build...) so we've been exposed to most of the features for a while now, albeit without alot of the bug fixes ;o)

IronPython

I've been a bit quiet on the IronPython front... which is mostly because I haven't had the time to play around with it much lately - however I'll try to finish off my look into IronPython as a scripting engine, and in particular the good and bad aspects of getting it to play with your .Net code... In the mean time a collection of useful IronPython links is slowly growing here: http://ironpython-urls.blogspot.com/

Base4.Net

A week into using the Base4.Net's latest release, with compile-time query support, I'm loving it... it definitely gives a huge leap in productivity and expressability (if that's even a word ;o) - looking forward to seeing these features rounded out at some point (with support for scopes, projections and ordering) - Alex James is talking about migrations (my "most-wanted" feature) and it's looking encouraging, it's where I feel the most pain at the moment as base4 isn't particularly friendly when you try to approach the problem of building your schema in a YAGNI fashion - there is quite a bit of pain involved in adding and removing properties from types during development as requirements are refined.

The rub is that the current "on the table" solution will require restarting the base4 service to apply the migration... which at the moment means restarting the windows service with a different command line... or more likely, stopping the service, then starting the standalone server with the right command line arguments, waiting till it's done, stopping the standalone server and starting the service again... I was originally thinking of implementing these as a Nant or MSBuild task (much like RoR's migrations work with rake) but I think it might be a bit chunky... I need to think about it a bit more.

Splicer

I haven't forgot about my little side project (Splicer is a library I've written for "attempting" to eliminate the pain of using DirectShow.Net to encode audio and video) - and I do intend to keep updating and supporting it as-needed ... next release should see WinForm samples for encoding audio and video added, and updated code examples... after that I might review the implementation a bit, to see how effects and transitions can be made easier to use via relative times - I'm interested in DSL's at the moment, so maybe I could create a DSL for video editing ;o)... if nothing else it would be amusing... I've yet to establish if anyone actually uses the library yet (other than myself of course).

.Net | base4 | castle | IronPython | Splicer

posted @ Wednesday, November 01, 2006 11:33:00 PM (New Zealand Daylight Time, UTC+13:00) Comments [2] | Trackback |

Tuesday, October 31, 2006

Generics and Castle...

Though I knew you could do it, I never have till today... and that's supplying a type for a generic parameter in another type, which is registered in a container... Of course I didn't have to do it that way, but it it kept the configuration a little thinner.

Basically I have some simple WCF services I wanted to host in a container.. here's the service's interface...

[ServiceContract(Namespace="http://localhost/schemas/testrunner/", SessionMode=SessionMode.Required)]
public interface ITestRunner
{
    [OperationContract]
    Guid StartTestRun(Guid testSuiteId);
 
    [OperationContract]
    TestRunStatus GetRunStatus(Guid testRunId);
}

To get this to work for my implementation I had to do one thing, which was set the InstanceContextMode to "single" for the service implementations behaviour, otherwise the service host would die when I tried to pass in an instance (it expects a type for any other mode)... I haven't dug very deep into WCF, but it would be nice if they supported a mechanism for supplying a component activator instead...

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)] 
public class TestRunner : ITestRunner
{

Now, I build a component for hosting my service... it implements IStartable...

publicclassHostingWrapper<T> : IStartable    where T: class
{
    private ServiceHost _host;
    private T _service;
    private ILogger _log;
 
    public HostingWrapper(ILogger log, T service)
    {
        if (log == null) throw new ArgumentNullException("log");
        if (service == null) throw new ArgumentNullException("service");
 
        _log = log;
        _service = service;        
    }
 
    public void Start()
    {
        _host = new ServiceHost(_service);
        if (_log.IsDebugEnabled) _log.Debug("Opening ServiceHost for service: {0}", _service.GetType());
        _host.Open();
        if (_log.IsInfoEnabled) _log.Info("Opened ServiceHost for service: {0}", _service.GetType());
    }
 
    public void Stop()
    {
        if (_log.IsDebugEnabled) _log.Debug("Closing ServiceHost for service: {0}", _service.GetType());
        _host.Close();
        ((IDisposable)_host).Dispose();
        if (_log.IsInfoEnabled) _log.Info("Closed ServiceHost for service: {0}", _service.GetType());
        _host = null;
    }
}

And then you just need to regsiter it in the container's configuration:

<components>
    <component id="testRunnerService.default"
        service="BoatsForGoats.Services.Testing.ITestRunner, BoatsForGoats.Services"
        type="BoatsForGoats.Services.Testing.TestRunner, BoatsForGoats.Services" />
 
    <component id="testRunnerHost.default"
        type="BoatsForGoats.Services.HostingWrapper`1[[BoatsForGoats.Services.Testing.ITestRunner, BoatsForGoats.Services]], BoatsForGoats.Services" />

About the only tricky thing is that I guessed (incorrectly) that I would only need a single set of square brackets around the generic parameter.

.Net | castle | WCF

posted @ Monday, October 30, 2006 11:21:10 PM (New Zealand Daylight Time, UTC+13:00) Comments [0] | Trackback |

Friday, October 27, 2006

Blowing up the burner..

Well I blew up my feedburner yesterday... my RSS feed was set to max out at 50 items, which, with my love for pasting html-bloated source code was well over the 256K limit.... but feedburner never bothered tell me it was dead... only noticed today... at any rate, I tried resetting the size to a max of 6 posts in the feed... and pinging it... but it was still dead, so I did a resync... still no joy... In the end I found that I had to turn off feed burner support in das blog and then resync the feed.

Moral of the story, don't bloat your feed (It was bad form at any rate, especially in bandwidth starved New Zealand ;o)

If you can see this post it's all working again happily...

feedburner

posted @ Friday, October 27, 2006 2:52:24 AM (New Zealand Daylight Time, UTC+13:00) Comments [0] | Trackback |

Thursday, October 26, 2006

Base4.net compile-time query handling support

Well lots to blog about, but no time to do it... at least not today - at any rate I just thought I would say if you haven't considered using Base4 up until now, why not give it a go with the latest drop :) I'm loving these new changes with the support for Compile-time query handling... I think at this point you can start prototyping stuff with base4 very quickly, between the UI for designing or discovering an existing schema, and now the ability to avoid learning the ObjectPath query syntax it's pretty compelling...

At any rate, as mentioned in the various posts from Alex James, you can now write these kinds of queries:

IItemList<FileBase> matchingFiles = StorageContext.Find<FileBase>(FileBase.Fields.FileSize > 1024000 && FileBase.Fields.MimeType == "audio/wav");

Faboo, and of course you can drill through the relationships:

Track track =  StorageContext.FindOne<Track>(Track.Fields.Name == reference.TrackName 
    && Track.Fields.Release.Name == reference.ReleaseName 
    && Track.Fields.Release.Artist.Name == reference.ArtistName);

This is for a simple hierarchy, where we have Artists-> Releases -> Tracks (sadly organising Music in reality isn't quite this easy...)

But as you can see these queries are getting quite verbose, personally this is where the elegance of this approach comes in... reuse is possible, for example - we can build a static class to hold common queries:

public static class FileBaseQueries
{
    public static ExpressionField LargerThenOneMegabyte
    {
        get
        {
            return FileBase.Fields.FileSize > 1024000;
        }
    }
 
    public static ExpressionField MimeTypeIsAudioWav
    {
        get
        {
            return FileBase.Fields.MimeType == "audio/wav";
        }
    }
}

And now the first query could be rewritten:

StorageContext.Find<FileBase>(FileBaseQueries.LargerThenOneMegabyte && FileBaseQueries.MimeTypeIsAudioWav);

The main thing I like about this approach is your queries start looking like sentences... "Larger Then One Megabyte and Mime Type Is Audio Wav"...

Another idea might be to use a method on the static class instead...

public static ExpressionField MimeTypeIs(string type, string subType)
{
    return FileBase.Fields.MimeType == string.Format("{0}/{1}", type, subType);
}

And then writing something like:

StorageContext.Find<FileBase>(FileBaseQueries.LargerThenOneMegabyte && FileBaseQueries.MimeTypeIs("audio","wav"));

At this point it still reads quite nicely, but it's a little more flexible...

Edit: I just noticed this entry wasn't actually marked as syndicated... fixed it now.

.Net | base4

posted @ Wednesday, October 25, 2006 7:36:06 PM (New Zealand Daylight Time, UTC+13:00) Comments [0] | Trackback |

Thursday, October 19, 2006

Intermediate IoC...

I think there's 3 levels of skill involved with the Castle IoC implementation... first off you get a handle of the XML configuration, registering components, using existing facilities... pretty much getting away largely with cut 'n paste coding.

Then you get to the intermediate level.. writing basic facilities, tweaks to the component model, writing your own sub dependency resolvers or component activator, having a go with binsor configuration.

I think the third level is reserved for the Castle team alone... ;o)

This post is going to be straddling the beginner to intermediate kinda level... which is generally all I ever reach with Castle's IoC... it's not often you have to dig deeper day-to-day... though it's always good to know there is a lot of untapped potential there.

So.. for today, say you have a component, like the Base4Host, which has some explicit constructors:

public Base4Host(string appName, int port)
{
    if (string.IsNullOrEmpty(appName)) throw new ArgumentNullException("appName");
    if (port <= 1024) throw new ArgumentOutOfRangeException("port", "port should be greater then 1024");
    _appName = appName;
    _port = port;
}
 
public Base4Host(string appName, int port, string root)
    : this(appName, port)
{
    if (string.IsNullOrEmpty(root)) throw new ArgumentNullException("root");            
    _root = root;
}

You can register it the container easy enough, and provide values for them in XML configuration, but what if you want to do the same programatically... generally your first stop would be to examine the IWindsorContainer for a suitable overload... alas it doesn't get us far, so we dig in to the underlying IKernel itself... the kernel exposes some possible candidates:

void AddComponentWithExtendedProperties(String key, Type classType, IDictionary extendedProperties);
void AddComponentWithExtendedProperties(String key, Type serviceType, Type classType, IDictionary extendedProperties);

So you experiment with them, but supplying the dictionary of extended properties does nothing... hmm... time to file a bug report? well no... extended properties having nothing to do with satisfying parameter or property dependencies on your component - not directly at least.

So why don't we just create the component ourselves.. and then add it to the container?

Well you can, via the Kernel.AddComponentInstance method but you're going to miss out on some things... for instance the startable facility won't be "concerned" with your component, and as such if it implements IStartable it won't get started and stopped... Though I haven't confirmed this, I dont think the container will bother to dispose of any IDisposable components registered in this fashion either... the container doesn't consider itself the owner of the component (and generally this is what we want).

So we're going to have to get a little more intimate with the container implementation ... so every time a component is registered in the container a corresponding ComponentModel is generated for the component, this basically keeps track of the:

Components dependencies
Constructor candidates
Parameters (sounds like us...)
Name, implementation type and service type.
Lifecycle, Lifestyle...
And some other stuff you can discover for yourself.

Now we could get heavy handed and jump into contributing to the construction of the component model itself... but it's pretty uncessary, we just want to tweak the end result... so we can use an event handler on the Kernel - ComponentModelCreated.

So here we have an implementation that solves our problems... This is being implemented inside a facility, but you could do this anywhere... wire it up in your custom container that's derived from WindsorContainer maybe, obviously you want to remove the if statement for checking the Implemenation type is Base4Host though. :)

private const string AdditionalParametersKey = "AdditionalParameters";
 
private void Kernel_ComponentModelCreated(Castle.Core.ComponentModel model)
{
    if (model.Implementation == typeof(Base4Host))
    {
        if ((model.Configuration == null)
            && model.ExtendedProperties.Contains(AdditionalParametersKey))
        {
            Dictionary<string, object> additionalParameters = (Dictionary<string, object>)model.ExtendedProperties[AdditionalParametersKey];
            foreach (string parameterName in additionalParameters.Keys)
            {
                model.Parameters.Add(parameterName, Convert.ToString(additionalParameters[parameterName]));
            }
        }
    }
}
 
protected override void Init()
{
    Kernel.ComponentModelCreated += new ComponentModelDelegate(Kernel_ComponentModelCreated);
}

Now I can register my component by doing something like this:

Dictionary<string, object> additionalParameters = new Dictionary<string, object>();
additionalParameters.Add("appName", _applicationName);
additionalParameters.Add("port", _port);
additionalParameters.Add("root", _baseDirectory);
 
Hashtable properties = new Hashtable();
properties.Add(AdditionalParametersKey, additionalParameters);
 
Kernel.AddComponentWithProperties("base4.defaultHost", typeof(Base4Host), properties);

Here we're passing all our additional parameters as a Dictionary<string, object> inside our IDictionary of additional properties.... this isn't the most elegant implementation, but this is all code internal to a single facility so it's not really important to me... and it gets the job done just fine.

.Net | castle

posted @ Wednesday, October 18, 2006 8:46:17 PM (New Zealand Daylight Time, UTC+13:00) Comments [2] | Trackback |

Tuesday, October 17, 2006

Abstractions...

Abstractions... mmmm... so sweet

...a post from Ayende on abstractions, and specifically a mention of the logging "abstraction" in Castle... it's an interesting thing, for the Seismic product I worked logging (via the same abstraction) into a product a year or more ago... in the end we needed the ability to log contextual information (basically exposing features already existing in log4net at the time, but not available via the Castle ILogger interface) and so I ended up creating a new interface that was a superset of the existing abstraction, IExtendedLogger...

here's the devil... looks simple...

public interface IExtendedLogger : ILogger
{
    void AddProperty(string key, object value);
    void RemoveProperty(string key);
}

However... because we're being a good little abstraction "whore" we end up with a few more classes to support this new interface, and make the user experience more pleasurable:

Though I was reasonably pleased with the end result a year ago, that was probably a couple of hours work + some more time tweaking (once you include the time to code up that test fixtures) that would've been better spent building additional functionality into the product.

I have to admit the lure of a needless abstraction is ever present to me... I enjoy halving a class into an abstract and concrete implementation, and then extracting an interface is like the candy coating... prefixing the concrete implementation with "Default" makes it even seem like you've all but got people lining up to create their own versions! Wow, isn't it powerful, flexible.. and all sorts of other words ending in "ul" or "ile".

....But in the end, needless is needless - and I haven't needed the flexibility gained from this abstraction so far... after a year... a whole year, that's pretty much like never... sure I had grand plans, but they never did come to fruition... and grand plans don't keep me fed - YAGNI strikes again.

About the only thing I find the needless abstractions do is in clarifying my thinking on what I do and don't need, or more importantly what I do and don't want people to do with my code.... it let's me define just what I want my "pit of success" behavior to be, albeit not the implementation... Perhaps some of this stuff is better reserved for throw away prototypes then production code.

I think the best book I've found for discouraging this "80's guitar solo" of abstraction..um...ism is the Framework Design Guidelines... Though these abstractions do make it easy for me to maintain and grow my code (and the orthogonality of the design is generally good) it comes at the price of other people having difficulty learning my API through experimentation, and I fail to create a progressive framework... which after reading the aforementioned book, is something we all wan't to do.

I guess the final question is, do you reverse an abstraction that isn't required after such a long time...? Or do you just avoid making the same mistake twice and live with the abstraction, assuming it's not hurting too many people - Is it worth lumping it with the rest of the "broken windows" in a project, or is that a little too brash?

.Net | castle

posted @ Tuesday, October 17, 2006 9:53:52 AM (New Zealand Daylight Time, UTC+13:00) Comments [0] | Trackback |

something a little bit different...

Nothing to do with code, but how many people are or have watched time trumpet in NZ?

posted @ Tuesday, October 17, 2006 9:46:08 AM (New Zealand Daylight Time, UTC+13:00) Comments [0] | Trackback |

A quick observation...

Startable facility and hosting base4

Ivan's pretty keen :) last week he demonstrated hosting the base4 service in ASP.Net ... cool stuff.

Now here he has placed the implementation in the HttpApplication class, and as a quick observation this would be a good candidate for moving into it's own component... and as luck would have it, Castle has just the thing, via the Startable facility.

Startable... (and the implied, stoppable ;o)

Now the startable facility is a very simple beast, basically... you create a class, that implements this interface:

/// <summary>
/// Interface for components that wish to be started by the container
/// </summary>
public interface IStartable
{
    void Start();
    void Stop();
}

Which lives in the Castle.Core assembly... though the facility itself lives in the Castle.MicroKernel assembly... you should already have references to both, otherwise I doubt your container is working at all :P

And you then register the startable facility in the container:

<facility id="startable.facility"
    type="Castle.Facilities.Startable.StartableFacility, Castle.MicroKernel" />

And thats it... now whenever you register a component in the container, the startable facility will check it, and if it's found to implement IStartable it will add it to a list of components "awaiting startup"... once any of these awaiting components has had all it's dependencies satisfied it will be started (so it may be started as soon as the component is registered, if it doesn't have any dependencies - this will be the case for our component)...

Disposing of the container will cause the components to be stopped in turn... perfect for hosting our base4 server...

Reworking the hosting code to be a startable component...

...so taking what Ivan's done, we could rework it a little... and be able to host base4 in web apps, as well as say your business logic's test harness... here's my quick 'n dirty reworked implementation as a component that I did this afternoon... my final version probably won't have any dependencies on the HttpContext as I'll just rely on explicit declaration of all the settings as parameters in the container configuration... I tend to like keeping all the config in the container, one place to look 'n all that.

public class Base4Host : IStartable
{
    private const string _machineName = "localhost";        
    private const string _provider = "SQL2005";
    private string _appName;        
    private int _port;
    private string _root;
    private ServerConfiguration _configuration;
    private IServerProxy _proxy;
 
    public ServerConfiguration Configuration
    {
        get { return _configuration; }
    }
 
    public IServerProxy ServerProxy
    {
        get { return _proxy; }
    }
 
    public Base4Host(string appName, int port)
    {
        if (string.IsNullOrEmpty(appName)) throw new ArgumentNullException("appName");
        if (port <= 1024) throw new ArgumentOutOfRangeException("port", "port should be greater then 1024");
        _appName = appName;
        _port = port;
    }
 
    public Base4Host(string appName, int port, string root)
        : this(appName, port)
    {
        if (string.IsNullOrEmpty(root)) throw new ArgumentNullException("root");            
        _root = root;
    }
 
    #region IStartable Members
 
    public void Start()
    {
        _configuration = CreateConfiguration();       
        _proxy = ServerFactory.StartServer(_configuration, false);
        string base4Context = string.Format("tcp://Server:@localhost:{0}/{1}", _port, _appName);
        StorageContext.SetDefault(base4Context);            
    }
 
    public void Stop()
    {
        _proxy.Stop();
        _proxy = null;
        _configuration = null;
    }
 
    #endregion
 
    #region Support methods
 
    private ServerConfiguration CreateConfiguration()
    {
        ServerConfiguration configuration = new ServerConfiguration();
 
        DiscoverApplicationName();
        InsertApplicationRoot(configuration);
        InsertConnectionStrings(configuration);
        InsertConnectivityInformation(configuration);
 
        if (!Directory.Exists(configuration.Store.Root))
        {
            Directory.CreateDirectory(configuration.Store.Root);
        }
 
        return configuration;
    }
 
    private void InsertConnectivityInformation(ServerConfiguration configuration)
    {
        configuration.Store.Name = _appName;
        configuration.Store.Provider = _provider;
        configuration.Store.Port = _port;
        configuration.Store.MachineName = _machineName;
    }
 
    private void DiscoverApplicationName()
    {
        if (string.IsNullOrEmpty(_appName))
        {
            if (HttpContext.Current.Application["AppName"] == null)
            {
                Assembly assembly = Assembly.GetCallingAssembly();
                HttpContext.Current.Application["AppName"] = (AssemblyTitleAttribute.GetCustomAttribute(assembly, typeof(AssemblyTitleAttribute)) as AssemblyTitleAttribute).Title;
            }
 
            _appName = HttpContext.Current.Application["AppName"].ToString();
        }
    }
 
    private void InsertApplicationRoot(ServerConfiguration configuration)
    {
        string root = string.IsNullOrEmpty(_root) ? HttpContext.Current.Server.MapPath("~/") : _root;
        configuration.Store.Root = root.EndsWith("\\") ? root + "App_Data\\Base4" : root + "\\App_Data\\Base4";
    }
 
    private void InsertConnectionStrings(ServerConfiguration configuration)
    {
        string connectionStringName = ConfigurationManager.AppSettings["DefaultConnection"];
 
        if (string.IsNullOrEmpty(connectionStringName) && ConfigurationManager.ConnectionStrings != null
            && ConfigurationManager.ConnectionStrings.Count > 0)
        {
            connectionStringName = ConfigurationManager.ConnectionStrings[0].Name;
        }
 
        configuration.Store.ConnectionString = string.IsNullOrEmpty(connectionStringName) ? ConfigurationManager.AppSettings["Store.ConnectionString"] :
            ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString;
 
        SqlConnectionStringBuilder connStrBuilder = new SqlConnectionStringBuilder(configuration.Store.ConnectionString);
 
        connStrBuilder.InitialCatalog = "master";
        configuration.MasterConnectionString = connStrBuilder.ToString();
    }
 
    #endregion
}

Notice we don't expose a default constructor... how can the container create it?

Well, it can't unless we supply the parameters it requires... which is just what we'll do:

<component
    id="base4host.default"
    type="MyProject.Base4Host, MyProject">
    <parameters>
        <appName>GoatsAndBoats</appName>
        <port>11888</port>
    </parameters>            
</component>

Simple... a couple of useful extensions to our existing base4 facility may well be to:

Ensure the startable facility is installed... so we can fail-early and with a meaningful error during application startup.
Add some additional "optional" parameters for configuring the facility, so that it can take care of registering the Base4Host for us.

For the optional parameters, I'm thinking of doing something like this:

<facility id="base4.storageFacility"
    type="SomeProject.Core.Base4StorageFacility, SomeProject.Core"
    host="true" 
    appName="GoatsAndBoats" 
    port="11888"
    connectionString="local"
    />

At which point it's trivial to shift between accessing base4.net as a remote service vs. hosting it in your own app... unlike the remote setup you can skip providing the base4 url (context string) as it'll be implied from the app name and port.

.Net | base4 | castle

posted @ Tuesday, October 17, 2006 12:28:44 AM (New Zealand Daylight Time, UTC+13:00) Comments [1] | Trackback |