One explicit goal of this proposal is to be future-proof by adopting as many MEF idioms as possible.
  1. Define (cloned from .NET) ImportAttribute, ExportAttribute and ImportingConstructorAttribute
  2. A Funqlet would then be composed of two projects: MyFunqlet and MyFunqlet.Configuration
  3. The configuration project has a project reference/dependency on the funqlet project, with CopyLocal=true
  4. This project also contains a public partial class implementing IFunqlet at the project root, which has nothing but a call to a private (unimplemented) partial method.
  5. If the developer wants to add some manual registration, that's the place they would do it.
  6. An msbuild task in the configuration project creates the other half of this partial class by implementing the partial method as follows:
    1. Loads via ReflectionOnly (or Assembly.LoadBytes, whichever doesn't disrupt normal development of the funqlet project) all files in the output directory. (this allows a single configuration project to be used for multiple funqlets :)).
    2. Searches all types that are Exports, and generates a corresponding Register<> call on the container.
    3. If there are Imported properties, it will generate the corresponding object initializer syntax to resolve that dependency, like: Register<IFoo>(c => new Foo { c.Bar = c.Resolve<IBar>() } );
    4. Of course, in order to know which constructor overload to invoke, it has to search for ImportingConstructorAttribute (copy MEF heuristics here)
    5. If the Import is Lazy<T> (I guess this type is there in SL?), then it uses a c.LazyResolve instead.
  7. The Shell/App has two ways of configuring the container with the funqlets:
    1. Add a project reference to the configuration project, and do a straight "new" of the public configuration class generated there. Multiple configuration projects could be added this way and instantiated for configuring the container.
    2. Load the assemblies via reflection and search for the funqlets (this would only be for discovery of the IFunqlet classes, not to discover imports/exports, which is good already)
    3. Provide some kind of catalog of the full funqlet types to load and invoke.

Last edited Aug 29, 2010 at 5:13 AM by dcazzulino, version 1


No comments yet.