System.AddIn

Oct 14, 2009 at 7:41 PM
Edited Oct 14, 2009 at 7:41 PM

First of all, wow, good job blade, the design/usage of this class fits the WPF model perfectly. Seems like you've put a lot of thought into this project.

On a side note, do you know a good way of using this project with the System.AddIn framework? That framework seems to require public static void main for multi app-domain loader optimization.

Coordinator
Oct 14, 2009 at 10:32 PM
Edited Mar 9, 2010 at 9:13 AM

Thanks a lot for your nice comment, I thought this little project was passing by almost unnoticed! :)

About your question, I have played a bit with the System.AddIn framework and I know what you are speaking about (I suppose it is about sharing assemblies among AppDomains, to save up memory and speed up things); I must even say that I don't like very much such framework, even if it is well designed... sometimes is not very flexible (simple scenarios do not need multiple app-domain, so it would be nice to be able to define if an add-in should be loaded in the main executable AppDomain, a common one for all add-ins or in a dedicated one, for example) and the documentation is quite scattered.

That said, I am not using System.AddIn for my project (I created a custom plugin-in framework to fit my simpler needs), but for different reasons I had to define the Main function, and I use the class in this project to create a single instance application. The following is a simple example on how to use it (of course you need to get rid of the App.xaml, but in the example below I load a Resources.xaml file in the constructor, so that I can define resources in a xaml file as with App.xaml).

 

 

using System;
using System.Linq;
using System.Windows;
using System.Reflection;
using System.Windows.Input;
using System.Collections.ObjectModel;
using System.Collections.Generic;
using System.Collections.Specialized;
using Custom.Windows;

namespace CustomApp
{
public class App : InstanceAwareApplication
{
[STAThread]
[System.Diagnostics.DebuggerNonUserCode]
[LoaderOptimization(LoaderOptimization.MultiDomainHost)]
public static int Main(params string[] args)
{
App app = new App();
WindowMain main = new WindowMain();
return app.Run(main);
}

public App()
: base()
{
ResourceDictionary appResources = new ResourceDictionary();
appResources.Source = new Uri("pack://application:,,,/" + Assembly.GetEntryAssembly().GetName().Name + ";component/Resources.xaml");

Resources.MergedDictionaries.Add(customResources);
}
}
}

 

I hope this little piece of code helps you, let me know if you have more questions, I will gladly answer! :)

Oct 15, 2009 at 9:33 PM

ah, neat! thanks for the tip. I have been contemplating about not using MAF for a few days now; mostly due to its inherently weak WPF support.

You've just made up my mind about ditching MAF in favor of MEF. :-)

 

Thanks again for everything, looks like I have a long way to go from becoming an expert in .NET like you.

Coordinator
Oct 15, 2009 at 9:42 PM

I do not consider myself an expert, but I love to play with .NET a lot, and I keep on aiming always a bit higher :D