Neo4j.AspNet.Identity is Back!

Originally posted on: http://geekswithblogs.net/cskardon/archive/2015/06/05/neo4j.aspnet.identity-is-back.aspx

In fairness, it was never *away*, but after a brief hiatus – it is being developed again.

So changes – it’s moved – https://github.com/cskardon/Neo4j.AspNet.Identity

It’s also been repackaged and nuget-ed, the instructions on the Readme have been updated and the actual database structure is better than before, it’s not all there (of course) but I will accept pull requests and any issues, open up on the github page.

I’ll try to do some follow up posts with the db structure, but roughly:

image

Upgrading your Neo4J from XXX to 2.2.0–having authorization trouble?

Originally posted on: http://geekswithblogs.net/cskardon/archive/2015/03/27/upgrading-your-neo4j-from-xxx-to-2.2.0ndashhaving-authorization-trouble.aspx

I’ve recently upgraded one of my Neo4J dbs from 2.1.7 to 2.2.0, and instantly ran into troubles with the new Authentication that the db now has. You’ll notice it when you first login to your browser (http://localhost:7474/) and get asked for a login name and password. Of course, you can turn off authentication via the settings (conf/neo4-server.properties) by changing the ‘dbms.security.auth_enabled’ value to false, but now we’ve got it, we should use it!

Luckily neo4jclient already allows us to pass in basic auth via the uri, so we can do something like:

var client = new GraphClient(new Uri("http://user:pass@localhost.:7474/db/data"));
client.Connect();

9 times out of 10, that’ll work just fine for you, the problem is if your password has a character in it that the Uri constructor can’t parse – now I’m sure you can escape the character – but I’ve been unable to find out how, so something like:

new Uri(http://user:pass#@localhost.:7474/db/data)

will fail with a ‘UriFormatException: Invalid URI: Invalid port specified.’ message (I’ve added a ‘#’ to the password).

What to do???

Spiffily – the GraphClient has another constructor that takes in an IHttpClient, so we can create our own version that injects the Authorization header into any (and all) requests to the db:

private class HttpClientAuthWrapper : IHttpClient
{
    private readonly AuthenticationHeaderValue _authenticationHeader;
    private readonly HttpClient _client;

    public HttpClientAuthWrapper(string username, string password)
    {
        _client = new HttpClient();
        if (string.IsNullOrWhiteSpace(username) || string.IsNullOrWhiteSpace(password))
            return;

        var encoded = Encoding.ASCII.GetBytes(string.Format("{0}:{1}", username, password));
        _authenticationHeader = new AuthenticationHeaderValue("Basic", Convert.ToBase64String(encoded));
    }

    public Task<HttpResponseMessage> SendAsync(HttpRequestMessage request)
    {
        if(_authenticationHeader != null)
            request.Headers.Authorization = _authenticationHeader;
        return _client.SendAsync(request);
    }
}

Which is used like so:

var client = new GraphClient(
    new Uri("http://localhost.:7474/db/data"), 
    new HttpClientAuthWrapper("user", "pass#")
    );
client.Connect();

All authorized and happy!

Branching

[code lang=text]
Title: "Branching" on 2008-06-17 12:11:56
Categories: "General"
– "Source Control"
Originally posted at geekswithblogs.net/cskardon
[/code]

I’ve developed in 3 main situations, University, Personally and Professionally, which I believe is probably similar for most developers. I’ll freely admit that for my personal projects I’ve rarely (if ever) utilised source control solutions, even though I know that there are plenty of free solutions available. It’s just never been an issue (though I am going to rethink that).

University taught me squat all about how to use source control, I think I gained an inkling of what it was somewhere towards the end of my time there, when another project team lead mentioned to me that they were using it. I really came into the source control circle in my first professional role.

I never really realised how important source control was until then, and now I recognise proper usage of source control as a core part of the development process. I’d almost go as far as to say, the core part of the process. A crap coder can write crap code, delete good code, whatever they like, and as long as it’s source controlled – we can see what was changed, when, and importantly rollback if required.

Most devs I’ve worked with have really only ever used source control to do the usual checkin/checkout gubbins, which for 90% of the time is great. Most have heard of branching, but never actually used it, some people don’t even want to use it. It’s a big scary concept that people fear. Personally I think a lot of the fear is due to the complexity of the tools used to do the job. Well. One tool in particular. Visual SourceSafe 6 & 2005.
Branching shouldn’t be (too) scary!

Why should branching be used?

Imagine we’ve developed our program, EmailXtreme (a spiffy email app if you must know), and we’ve reached version 1, our first release! Now, to get to the first release, we’ve taken some short cuts, and some features we wanted have been cut to make the release date. But we’re in the moment, who cares?
Time passes, and development of the extra features begins.

More time…

OH NOES! Bug!!! One of our customers has discovered a bug in the app – and wouldn’t you know it – it’s a critical bug, EmailXtreme doesn’t actually Email (thanks testers!).

All developers get working on the fix, fortunately it’s a one liner, fixed, tested – out it goes to the customers (with apologies).

5 minutes after…

During congratulations, pizza and beer, a lone voice can be heard:

“guys, errr, what about that new feature we were working on, it’s not finished, and [cough] will break, well, everything.”

Silence. A beer can drops on the floor. Someone cries.


Quick rewind

  • Release v.1 done, all good (yay).
  • Dev team branch into a version 1 branch, then get developing on the trunk.
  • Bug comes in.
  • Bug is fixed in maintenance branch, released to the customer and finally the fix is merged into the development trunk.
  • Customer and devs happy, this time they get their pizza and beer. Good job!

This is a bit of an oversimplification of how branching can work, but it’s also a good example of why branching is useful.

How?

That’s really all down to the tool you’re using. I have used sourcesafe to do this, and it pained me, and the guys I was working with. I can only really comment on one other tool – Vault, and that makes branching a doddle.

It’s worth checking your current Source Code Control (SCC) to see what you can do.

Managed Application Framework – Part 2 – Basic Versioning!

Soooo… A post from a while ago covered the basic Managed Addin Framework (MAF from here-in) and how to set up a basic addin with host and pipeline.

One of the big problems of an Addin situation is if we change the contract between our Addins and our host. This can happen for a number of reasons – added functionality, removed functionality, the dreaded security etc… So, we change our contract and OH NOES! break all the AddIns we’ve carefully nurtured to maturity.

Luckily the guys who developed the MAF have come up with a solution to this, and it all lies with the pipeline………

Previously we had the IHelloMAF contract:

[AddInContract]
public interface IHelloMAF : IContract
{
string HelloMAF();
}

Obviously this gives us a limited set of functionality, so lets add a little bit more:

[AddInContract]
public interface IHelloMAF : IContract
{
string Hello(string name);
}

This will give us the power to accept inputs! Of course, this is just the contract, the detail is in the actual implementation itself.

If I simply update the contract and rebuild the pipeline, then my previously created AddIn will stuff up as it implements the old contract, I would have to change the AddIn to implement the new version, but I don’t or maybe can’t do that.

What does that mean for the development? Basically, we need to create another adapter, one to convert version 1 addins to work as a version 2 addin. To do this, we use the Pipeline builder, it saves a lot of time and effort in the long run. We need to be able to tell the Pipeline builder that, actually, generate a new AddInView, not overwrite the existing one. To do this, we reference in the PipelineHints dll (this is in the location you installed the PipeLine builder – in my case: C:\Program Files\Microsoft\Visual Studio Pipeline Builder\PipelineHints.dll).

Once we have the hints dll referenced we can go to our Contract file and put the following in:

[assembly: PipelineHints.SegmentAssemblyName(PipelineHints.PipelineSegment.AddInView, “AddInView2”)]

** Put this ABOVE the namespace declaration (if you have one)!! **

What this effectively does is force the Pipeline builder to create the AddInView segment for this contract, but name it ‘AddInView2’ rather than it’s default ‘AddInView’.

If we now run the Pipeline builder, we will generate some new projects, including ‘AddInView2’, note – the ‘AddInView’ project is still there, aces!

After this we need to update the host to cope with the new contract (** IF we changed the contract name, if we didn’t then no updates required **), should be pretty simple.

We can then create a new AddIn, based off of the new contract, and once we’ve done that, run the host and load up our new AddIn. All should be working!

But the version 1 addin isn’t showing – this is expected at the moment. The pipeline builder has only created a pipeline for the new style of Addin. What we need to develop is a v1 addin to v2 addin adapter. The easiest thing to do is copy from the AddInSideAdapters project.

We create a new Class Library project, calling it something like AddInV1ToV2Adapter, which gives us a good start point.
Add in references to:
System.AddIn
System.AddIn.Contract
AddInView (the version 1 addin!)
Contracts
(Again, Copy to local = FALSE!!)

Then opening the AddInSideAdapters project, copy the IXXXViewToContractAddIn.cs contents and paste them into your ‘Class1.cs’ file. Now we just need to edit the code to do our translation, so.. first things first, rename the class, doesn’t really matter what it’s called!

You should find the only thing you really need to change is the implementation of the methods, so in our example, we’d have:

public virtual string Hello(string msg)
{
return _view.HelloWorld();
}

Rebuild the entire solution and run the host… Now our host detects 2 AddIns, which is perfect!

I would attach the code to this post, but my blog host doesn’t allow attachments at the moment, I am in the process of looking into this!
If you want it, please email me: cs7kardon [-=At=-] xc7lave . c7o . uk (remove the ‘7’s and compress!)

Just Let It Go

I was reading a blog post (Narcissism of Small Code Differences) today, and something rang true.

Basically the post (or what I got from it), is that the differences in ways people program are just that, differences. Just because a bit of code maybe isn’t written the way I would write it, doesn’t mean it’s wrong. As depicted in the post, there may be reasons why code is done in a certain way!

I mention this now, as I’ve just come across some code from a co-worker that in the past, I probably would have re-written, it’s a simple thing, and really more style based than efficiency etc.

The co-workers code reads like:


if(!xxx)
{
/*Do some stuff*/
return false;
}
else
return true;

Here I would itch to get rid of the ‘else’, either:


if(!xxx)
{
/*Do some stuff*/
return false;
}
return true;

as the ‘else’ is irrelevant in this case. Or even:


if(xxx)
return true;


/*Do some stuff*/
return false;

Neither would change the way the method works, but both are purely style changes that look more pleasing to me. But, hey! What if the original coder prefers it his way – it’s wrong for me to force my style on someone else.

So today I’ve decided to let go any style changes unless they significantly make the code easier to read / debug etc… Yay for narcissistic me!

Pulsy Button

After much umming and ahhing, and developing several versions of BrokeyButton I have the first cut of the PulsyButton.

What is PulsyButton? Well, it’s a button – that pulses. By pulsing I mean that it ‘pulses’ between the Background colour and a ‘PulseColour’ (that you set!).

Pulsy Button

Easy usage:
<PulsyButton Content="Hello" BackgroundColor="LightGray" PulseColor="Red" IsPulsing="True"/>

Obviously if IsPulsing is set to false then the button won’t pulse.
As it’s just based off the ‘Button’ base class, you can literally insert it wherever you have a Button, and all your styles etc will work fine.

I have plans to add more properties, and will over time:
* PulseTime — A TimeSpan for the pulse.
* PauseTime — A TimeSpan to pause the pulse for, i.e. pulse-paaaaauuuuusssseeeee-pulse etc

Also plans to fix some problems:
* Use StoryBoard and set the Background property directly
* Get rid of BackgroundColor property, so only Background is needed

Erm, can’t think of others at the moment.


Bit more detail -> What have I done?

Well, I had a lot of trouble getting a StoryBoard to work programmatically, I don’t know why, and I will perservere. But in the mean time, I’ve resorted to just a simple ColorAnimation.

How have I used a ColorAnimation with a Background brush?

Well, first I created a DependencyProperty:

public static readonly DependencyProperty BackgroundColorProperty
= DependencyProperty.Register( "BackgroundColor", typeof( Color ), typeof( PulsyButton ),
new UIPropertyMetadata( BackgroundColorChanged ) );

private static void BackgroundColorChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
PulsyButton pb = (PulsyButton) d;
pb.Background = new SolidColorBrush( (Color) e.NewValue );
}

This was my ahem workaround to the setting of the Background property directly, as the ColorAnimation will only animate Color properties (i.e. target the SolidColorBrush.Color property for the brush). By the by, it was the targeting of that property that caused me much hassle.

Anyhews, once we’re there, we should also have a PulseColor property (yes I know colour should have a ‘u’ in it, but I’ve gone all americanized :))

public static readonly DependencyProperty PulseColorProperty
= DependencyProperty.Register( "PulseColor", typeof( Color ), typeof( PulsyButton ),
new UIPropertyMetadata( PulseColorChanged ) );

public Color PulseColor { get { return (Color) GetValue( PulseColorProperty ); } set { SetValue( PulseColorProperty, value ); } }

private static void PulseColorChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
PulsyButton pb = (PulsyButton) d;
pb._pulseAnimation.To = (Color) e.NewValue;
}

Here I’ve included the PulseColor property, rest assured there is a BackgroundColor property as well. So, now we have the two colours to animate between, Background -> Pulse -> Background… We just need to create the animation.

private readonly ColorAnimation _pulseAnimation = new ColorAnimation();

There’s no need to recreate it, so it’s a readonly member. But when do I set this bad boy up? Not the constructor – nooooo, the colour properties won’t have been set up at that point, so I’ve gone for a ‘Loaded’ event consumer.

public PulsyButton()
{
Loaded += PulsyButton_Loaded;
}

private void PulsyButton_Loaded( object sender, RoutedEventArgs e )
{
_pulseAnimation.From = BackgroundColor;
_pulseAnimation.To = PulseColor;
_pulseAnimation.Duration = new Duration( TimeSpan.FromSeconds( 1 ) );
_pulseAnimation.AutoReverse = true;
_pulseAnimation.RepeatBehavior = RepeatBehavior.Forever;


this.BeginAnimation( BackgroundColorProperty, _pulseAnimation );
}

The animation will now begin, and the pulsy fun is nearly there!
But wait… what about turning pulse on/off?

All that is done in the IsPulsingChanged property:

private static void IsPulsingChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
bool isPulsing = (bool) e.NewValue;
PulsyButton pb = (PulsyButton) d;
if( !isPulsing )
{
pb._pulseAnimation.RepeatBehavior = new RepeatBehavior( 0 );
pb.BeginAnimation( BackgroundColorProperty, pb._pulseAnimation );
}
else
{
pb._pulseAnimation.RepeatBehavior = RepeatBehavior.Forever;
pb.BeginAnimation( BackgroundColorProperty, pb._pulseAnimation );
}
}

Now, I’m not 100% sure this is the correct way to do this, in fact I’m certain it’s not. However, it does work, which at the moment is what matters.

So there you have it, a button that pulses.

——————=====================———————–

Can’t attach the code to the post, so gonna have to past it here, sorry!!

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Media;
using System.Windows.Media.Animation;

public class PulsyButton : Button
{
private readonly ColorAnimation _pulseAnimation = new ColorAnimation();

public readonly DependencyProperty IsPulsingProperty
= DependencyProperty.Register( “IsPulsing”, typeof( bool ), typeof( PulsyButton ),
new UIPropertyMetadata( IsPulsingChanged ) );

public bool IsPulsing
{
get { return (bool) GetValue( IsPulsingProperty ); }
set { SetValue( IsPulsingProperty, value ); }
}

private static void IsPulsingChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
bool isPulsing = (bool) e.NewValue;
PulsyButton pb = (PulsyButton) d;
if( !isPulsing )
{
pb._pulseAnimation.RepeatBehavior = new RepeatBehavior( 0 );
pb.BeginAnimation( BackgroundColorProperty, pb._pulseAnimation );
}
else
{
pb._pulseAnimation.RepeatBehavior = RepeatBehavior.Forever;
pb.BeginAnimation( BackgroundColorProperty, pb._pulseAnimation );
}
}

public static readonly DependencyProperty PulseColorProperty
= DependencyProperty.Register( “PulseColor”, typeof( Color ), typeof( PulsyButton ),
new UIPropertyMetadata( PulseColorChanged ) );

public Color PulseColor { get { return (Color) GetValue( PulseColorProperty ); } set { SetValue( PulseColorProperty, value ); } }

private static void PulseColorChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
PulsyButton pb = (PulsyButton) d;
pb._pulseAnimation.To = (Color) e.NewValue;
}

public Color BackgroundColor
{
get { return (Color) GetValue( BackgroundColorProperty ); }
set { SetValue( BackgroundColorProperty, value ); }
}

public static readonly DependencyProperty BackgroundColorProperty
= DependencyProperty.Register( “BackgroundColor”, typeof ( Color ), typeof ( PulsyButton ),
new UIPropertyMetadata( BackgroundColorChanged ) );

private static void BackgroundColorChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
PulsyButton pb = (PulsyButton) d;
pb.Background = new SolidColorBrush( (Color) e.NewValue );
}

public PulsyButton()
{
Loaded += PulsyButton_Loaded;
}

private void PulsyButton_Loaded( object sender, RoutedEventArgs e )
{
_pulseAnimation.From = BackgroundColor;
_pulseAnimation.To = PulseColor;
_pulseAnimation.Duration = new Duration( TimeSpan.FromSeconds( 1 ) );
_pulseAnimation.AutoReverse = true;
_pulseAnimation.RepeatBehavior = RepeatBehavior.Forever;

this.BeginAnimation( BackgroundColorProperty, _pulseAnimation );
}
}

New Header!

Huzzah! I’ve utilised all my artistic skills and whomped a new header to the site!
I’m sure you’ll agree it’s pretty spiffy 🙂

Extensionising Wpf (or Chris’ fun with Extension methods and Wpf)

To be honest, it’s not really trouble using, or indeed writing extension methods, I don’t really have any troubles writing them, it’s more what I wanted to do with them that has bugged me.

As everyone who gets into writing WinForms / WPF apps knows, there will come a point where you will need to partition the work you’re doing to another thread. The usual reasons (so you can do other things, so the UI doesn’t lose it’s interactivity etc) apply.

Once you’ve entered this world you may even want to update the UI from within the thread – maybe it’s just a simple thing like enabling a button, changing the text on a label (etc). It’s quite a common thing to do and as such you can find shed loads of blogs, articles on the whys and wherefores of achieving those goals. I’ve been a WinForms developer for oooh, 4 years now, with the last year being a crossover of WPF / WinForms development. As a consequence I’ve done this quite a lot, and tend to find I have the same methods littering my code for achieving these goals:

private delegate void UpdateControlVisibilityDelegate(Control control, Visibility visibility);
private void UpdateControlVisibility(Control control, Visibility visibility)
{
if(!Dispatcher.CheckAccess())
{
Dispatcher.Invoke(DispatcherPriority.Send, new UpdateControlVisibilityDelegate(UpdateControlVisibility), control, visibility);
return;
}
control.Visibility = visibility;
}

Obviously, this is called pretty easily via the code:

UpdateControlVisibility(_myLabel, Visibility.Hidden);

Nicely, even if this is called from another thread, it avoids the cross-threading issues.

But what about making it better? Using the tools available and going all Extension method on it’s arse??

Extension methods are (I think) great, even if Resharper is currently screwing up the intellisense for them! Anyhews, the basic signature we’ll be looking at for the method would be something like:

public static void UpdateControlVisibility(this Control control, Visibility visibility)
{
/* Code */
}

Two things different from the previous, first, it’s static, second it’s got the ‘this’ keyword in front of the ‘Control’ argument. OK, so now lets just plug in the code…

private delegate void UpdateControlVisibilityDelegate(Control control, Visibility visibility);
public static void UpdateControlVisibility(this Control control, Visibility visibility)
{
if(!Dispatcher.CheckAccess())
{
Dispatcher.Invoke(DispatcherPriority.Send, new UpdateControlVisibilityDelegate(UpdateControlVisibility), control, visibility);
return;
}
control.Visibility = visibility;
}

Ah. The biggest problem is that the method uses the ‘Dispatcher’ property of the Window class. As the extension method has to be in a static class, we don’t have access to the Dispatcher property… so… should we pass it in?

public static void UpdateControlVisibility(this Control control, Visibility visibility, Dispatcher dispatcher) { /**/ }

We could. It would work (or at least in my tests seems to), but would be a bit messy, ideally we only want to pass in the Visibility argument (remember as it’s an extensibility method, the ‘control’ part isn’t ‘passed in’). So. What to do? Luckily, the ‘Dispatcher’ property is actually on the Control itself, so we can modify the method call to be something like:

public static void UpdateControlVisibility(this Control control, Visibility visibility)
{
if(!control.CheckAccess())
{
control.Dispatcher.Invoke(DispatcherPriority.Send, new UpdateControlVisibilityDelegate(UpdateControlVisibility), control, visibility);
return;
}
control.Visibility = visibility;
}

The only real thing of note is that we’re using the ‘CheckAccess()’ method of the control rather than the Dispatcher’s. No real reason, just shorter to type, and does the same thing (or so reflector tells me 🙂 ).

So, now we can just get our Control based, err, controls to have their Visibility changed safely:

_myLabel.UpdateControlVisibility(Visibility.Hidden);

Good thing is that we can just whack this code into a utility project and utilise it where we want.

So – is this all good? Have we solved the problems of the world? No, sadly not. There are some caveats which you should be aware of. I originally attempted this so I could ‘Show()’ a Window safely. This led to me writing the following:

private static void ShowSafelyDelegate(this Window window);
public static void ShowSafely(this Window window)
{
if(!window.CheckAccess())
{
window.Dispatcher.Invoke(DispatcherPriority.Send, new ShowSafelyDelegate(ShowSafely), window);
return;
}
window.Show();
}

I was using this like this (you’ll have to bare with the threading here, it’s important to the story..):

///Handles the click of the button, gets the data on a new thread.
private void _btn_Click( object sender, RoutedEventArgs e )
{
Button b = sender as Button;
if(b == null)
return;
Thread t = new Thread(GetData);
t.Start(b.Tag);
}


///Gets the data and shows it in a
///The information to retrieve the data with.
private void GetData(object obj)
{
RetrievalInfo ri = obj as RetrievalInfo;
if(ri == null)
return;
DataTable table = DbUtils.GetData(ri);
WndwResults wr = new WndwResults(ri, table);
wr.ShowSafely();
}

Now, as we can see, the ‘GetData’ method is run on a seperate thread and constructs a WndwResults Window, and displays it (using the ‘ShowSafely’ method. Looks fine, but when run, will throw a tiswas and give you an:

InvalidOperationException
"The calling thread must be STA, because many UI components require this."

OK, so lets set the Apartment state of the thread to be STA…

Thread t = new Thread(GetData);
t.SetApartmentState( ApartmentState.STA );
t.Start(b.Tag);

GO!

ARGH!!!

LoaderLock detected
"Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang."

???

What the hell does this mean??
Turns out that the Loader Lock is a system wide lock which Windows uses to load / unload dlls (http://www.lenholgate.com/archives/000369.html). As to what it’s doing here, well, I need to spend some more time investigating that. However, more importantly right now is what we can do about it?

Well, we can disable the Managed Debugging Assistant for the LoaderLock exception (via the ‘Debug -> Exceptions’ menu option), but when we do this, we see the Window we’re loading flash up and then dissapear – which isn’t exactly what we want… The other option is to change the code.

In my initial code, I created the WndwResults Window in the new thread. If I take this back a bit further, and construct the WndwResults in the main thread, (not ‘Show’ it, but just construct it) then we’re ok:

/* Simplified example */
{
WndwResults wr = new WndwResults();
Thread t = new Thread(ShowWindow);
t.Start(wr);
}


private void ShowWindow(object o)
{
Window w = o as Window;
w.ShowSafe();
}

The above code works fine, and that’s because we’re not constructing the Window in the new thread. Of course the issue here is that I can’t now pass the data into the constructor, which costs me a few things – use of ‘readonly’ for the members, and other such things. But we can live with that.

Soooo….

We add a ‘SetData’ method to the Window:

public void SetData(DataTable table, RetrievalInfo ri){ /*....*/ }

and, going back to our previous code:

///Gets the data and shows it in a
///The information to retrieve the data with.
private void GetData(object obj)
{
RetrievalInfo ri = obj as RetrievalInfo;
if(ri == null)
return;
DataTable table = DbUtils.GetData(ri);
_wndwResults.SetData(table, ri); //
_wndwResults.ShowSafely();
}

Run the code… and… FFS!!!

InvalidOperationException
"The calling thread cannot access this object because a different thread owns it."

Of course it does! Hmmm, not a lot can be done in this situation, because the SetData (in my case) sets a couple of DependencyProperties, which in turn update the UI.

What can be done though? Well – we can make the SetData method literally only set member variables, and then attach to the ‘Loaded’ event of the Window in it’s own constructor, so… if it originally did this:

public void SetData(string message)
{
_lbl.Content = message;
}

Now it needs to do this:

//First add the member:
private string _message;


//Second add to the constructor of the Window and event handler.
public Window1()
{
InitializeComponent();
Loaded += Window1_Loaded;
}


//Handle the event...
private void Window1_Loaded(object sender, RoutedEventArgs e)
{
_lbl.Content = _message;
}


//Finally, modify the SetData method to actually set the data.
public void SetData(string message)
{
_message = message;
}

Phew! Lots of stuff to do, and that’s just for setting a label!

What are the conclusions of this epic of blog posts?
Well, quite frankly, going down the extension method route, whilst informative in learning how the threading works (well, a bit) has given me some useful methods, but, there are a lot of caveats that a Window has to adhere to, to make it work properly.

I’m going to persevere with this though, I reckon I can at least get some decent set of utility extension methods (for example the setting visibility one) for WPF controls. I’ll keep you posted – you never know, it might even be more frequent than once a month!

Managed Application Framework – Part 1 – The Beginnings!

Last week I was tasked with developing a new App for the guys I work with, (not a developers app you understand, but for actual normal users!!! Luckily it puts me smack bang where I work best – developing functional, extendable (and most importantly) Windows based apps. I’m now officially in my comfort zone!

The main difference between this app and previous apps I’ve done is the customer, normally I’m the person who writes that software tool that the other devs or system admins will use, so I can cram in shed loads of functionality and what I think are cool UI’s – usually involving liberal use of the SandDock tools (http://www.divelements.com/). This time because the users are non-expert users I’m having to really consider the design of the UI, and it is (in this case) very important – one of the specs of the app is: ‘It has to look cool’.

There is actually a reason for it to look cool – because we need it to impress management to get the go-ahead to redo an older app. Up side of this is that it’s going WPF. Aces!

Woah, I appear to have got a little bit sidelined.. I actually started this post to talk about the Managed Add-In Framework (MAF) of .Net 3.5. The MAF is a framework for using Add-In’s (or plugins as some apps call them) within .NET, but without the hassle of writing your own code to do the cool stuff (reflecting to load dlls etc).

As it happens MAF fits very nicely into the app I’m designing at the moment, so I’ve been playing around with it for a week or so now, and I have to say, I’m very impressed, the design of the MAF has been extremely well thought out, and covers a hell of a lot!

What does MAF consist of? Basically 3 broad parts, Host – Pipeline – Addin, of which the pipeline can be broken down into: HostView – HostAdapter – Contract – AddInAdapter – AddInView. The reason this is important is that the pipeline seperates the Host and AddIn from being dependent on the Contract (which in a later post will prove to be incredibly useful).

In this post (below) I’m going to explain how to set up a simple quick MAF application, just to get the swing of things, so.. without further ado: the MAF.

Firstly it’s important to know that the MAF requires a certain folder structure to work, (I think it requires it, every example, sample etc I’ve seen has it!). The structure can be seen on MSDN at: http://msdn2.microsoft.com/en-gb/library/bb384240.aspx – This is why I’ve put the fact that you need to set the output folders in the properties for projects created to point to a non-default location.

We begin creating a MAF project with a Class Library project we’re gonna call ‘Contracts’. In it we define the contract we intend to make all our Add-Ins implement.

  1. New Class Library – ‘Contracts’, set the Build Output to be: ..\Output\Contracts
  2. Add references to: System.AddIn and System.AddIn.Contract
  3. Define new interface, which must implement the IContract interface, and have the AddInContract attribute.


[AddInContract]
public interface IHelloMAFContract : IContract
{
string HelloMAF();
}

  1. Build the one project, all ok? Good, let’s mosey on!
  2. Get and install the Pipeline builder (open source) from codeplex: http://www.codeplex.com/clraddins
    (All the instructions are on the interweb at that site).
  3. Run the Pipeline builder and create the pipeline, this creates the 4 extra projects (HostView, AddInView, AddInSideAdapters and HostSideAdapters projects). This saves us the time of writing this code ourselves (which involves quite a lot of code repetition).
  4. Build the solution, you should have 5 projects now. Assuming that went ok, lets carry on.
  5. Create an Add-In —
    a) Add a new Class Library project to the solution, call it something like ‘AddInV1’
    b) Set the build output location to be: ..\Output\AddIns\V1
    c) Reference in the AddInView DLL which will be in the Output\AddInView directory.
    Set this reference’s ‘Copy to local’ property to ‘FALSE’.
    d) Reference in System.AddIn
    e) Edit the class file and create the code to implement the IHelloMAF contract:


[AddIn("AddInV1", Version="1.0.0.0")]
public class AddInV1 : IHelloMAF
{
public string HelloMAF() { return "Hello MAF!!"; }
}

In this code we’ve attached the ‘AddIn’ attribute, which takes a name (which can’t have spaces) and then a set of named properties (intellisense is your friend here). Also of note is that in our ‘Contracts’ project we called the contract: IHelloMAFContract, whereas here we’re using IHelloMAF. The code does nothing impressive, just returning a string.

  1. Build the solution, if you look in your output folder you should now have a \Addins\V1 directory with the dll in it. That’s the Add-In created.

  2. Now we’re going to create a host to actually run the Addins
    a) Create a new Console Application (call it something memorable, ‘host’ for example :))
    b) Reference the HostView dll (copy to local = false) and the System.AddIn dll.
    c) Set the build output location to: ..\Output
    d) In the Program.cs file, put in the following:


public static void Main()
{
string path = Environment.CurrentDirectory;
//Update the AddInStore looking for the AddIns.
AddInStore.Update(path);

//Get the tokens from the AddInStore.
Collection tokens = AddInStore.FindAddIns(typeof(IHelloMAF), path);

Console.WriteLine("Found " + tokens.Count + " addins, activating them....");

foreach(AddInToken token in tokens)
{
//Activate a given token.
IHelloMAF addin = token.Activate( AddInSecurityLevel.Internet );
Console.Write( "\tAddin: " + token.Name + ", version: " + token.Version + " --> " );
Console.WriteLine( addin.HelloMAF() );
}

Console.WriteLine();
Console.WriteLine( "Fin. Press ENTER to exit." );
Console.ReadLine();
}

What we have here are 3 main points, firstly where we do: AddInStore.Update(path); We’re telling the AddInStore to update itself and look for AddIns with the given root path.

Next point is the AddInStore.FindAddIns(typeof(IHelloMAF), path); line, which basically asks the AddInStore to find the AddIns available of a given type.

The final point is the activation of the AddInToken – token.Activate( AddInSecurityLevel.Internet );. At this point we’re activating the Add-In, and in the next lines calling methods on it.

  1. Build the solution.
  2. Start debugging (F5).

Running this should now give us:

> Found 1 addins, activating them....
> Addin: AddInV1, version: 1.0.0.0 --> Hello MAF!!
> Fin. Press ENTER to exit.

That’s the basic Host Pipeline AddIn structure, and will provide you with a good basis, the next step is to consider what to do in the event that we want to change the contract…

Jamendo

Not a development post (in the true meaning of the word :)) but more about a website I found a few days ago… Jamendo.com – I spend my coding time listening to music, it’s how I work and particularly with the distractions of an office with other people, it’s often the only way to ‘zone in’ to the work.

Jamendo provides a collection of royalty free music, free to download and share etc. It’s given me more options to listen to now, so that’s a good thing.

Check it out and see what you think!