LightSwitch and the MEF story (part 2): using SubSystemLoaders to wire up the application

Let’s be honest, no one likes to write documentation, including the LightSwitch team.  This is one of the things about LightSwitch many find annoying, but I find so intriguing. Even after half a year of working with it, I still discover things in the LightSwitch framework that have 0 official documentation, 0 blog posts, 0 results on google, …  Diving into the LightSwitch framework as deeply as I am, makes me feel like an explorer, Marco Polo, charting the uncharted…

In today’s post I’ll walk you through one of those uncharted territories and try to explain how LightSwitch uses SubSystemLoaders to set up the LightSwitch application, previously referred to as “How LightSwitch does composition“, …

In my first post about LightSwitch and the MEF story, I wrote that a LightSwitch application uses MEF “ to glue together different subsystems at runtime“.  By the way, I did not randomly pick the term SubSystem, it’s actually a LightSwitch idea to load together different subsystems…

So lets find out how they work…

Client…

Step one: config.xml

When a LightSwitch application fires up, one of the first things it will do is locate a file called config.xml…  This file is created/updated by the LightSwitch build process, and located inside your Silverlight XAP package.   To view it, open windows explorer and navigate to your LightSwitch solution.  Deeper down, in the subfolder bin/debug/web, you will find the built SilverLight application “MyLightSwitchApplication.Client.xap”.  If you change the extension from XAP to ZIP, you can use your normal unzipping tool to open the compiled SilverLight application, and find the config.xml file inside.

Step two: Manifests

I won’t explain the ApplicationCulture, ManifestTimeStamp, ApplicationName, Version or RootProjectGuid nodes in this post, but jump right to the Manifests.

Each of these manifests refers to a xml file, which in turn contains one (or more, but usually just one) name of an assembly.  For each of these assemblies, as identified by these manifests, the LightSwitch framework creates an AssemblyCatalog.

Step three: trying to locate SubSystemLoaders

In each of these catalogs, the LightSwitch framework will search for all exports of implementations of ISubSystemLoaders.

It is quite picky about what ISubSystemLoaders it will accept, and on how to organize them, as revealed by the export attribute and metadata used on one of those ISubSystemLoaders…

[Export(typeof(ISubsystemLoader)), Package("SubsystemLoader"), SubsystemName("Runtime.UserCode"), DependsOnSubsystem("Runtime.Presentation")]

Step four: deciding what SubSystemLoaders to accept.

Now that it found a list of ISubSystemLoader implementations, the LightSwitch framework reads the next node of our Config.xml file, which contains the names of the ISubSystemLoaders it needs to load.  For each of them, it will call the Load method…

Some of them explain pretty well what they do just by looking at the name (ModelLoader, PresentationRuntimeLoader, ThemingRuntimeLoader, RuntimeShellLoader, UtilitiesLoader, DiagnosticsLoader), others are just pure mystery (yes that XML files does state there should be some “ReportingLoader”…).

Two of special interest are the RuntimeUserCodeLoader and the RuntimeExtensionLoader.  They each load up the assemblies as identified by the ExtensionAssemblies and UserCodeAssemblies nodes…

Which obviously identify your code: your extensions, and your LightSwitch application…

Step 5: Initializing the application.

After the LightSwitch framework has correctly composed all subsystems, it is ready for use and will create a new instance of your LightSwitch application.  The first method, called directly from the constructor of the application, is the “partial void Application_Initialize()” method.

Your LightSwitch application is loaded and initialized, time to navigate the main page of the defined shell (or to the LoginPage.xaml, if forms authentication is enabled) and enjoy the fruits of this complex process.

Who said true beauty lies in simplicity?

Server…

Step one: I have no idea.

Unfortunately, I haven’t even scratched the surface of the LightSwitch framework on the client-side, and thus haven’t even started to dig into the server-side.

However, opening the Web.config, those first appSettings smell strangely familiar all the sudden…

Conclusion…

The LightSwitch framework seems to use configuration (config.xml client side, and web.config server side), to locate ISubSystemLoader implementations, identify them, and ask them to load a part of that LightSwitch power for your application.

This configuration is generated each time you build your LightSwitch application, and I haven’t gone so far as to manipulate this during the build process, but I think the result of such is hardly difficult to guess.

Until then, the Application_Initialize method seems to be the earliest point in a LightSwitch application where one could execute any user code, such as registering additional ExportProviders with the LightSwitch MEF container

Marco out.

Advertisements

7 thoughts on “LightSwitch and the MEF story (part 2): using SubSystemLoaders to wire up the application

  1. Great article Jan!

    Would it be fair to say that the lack of this kind of LightSwitch “documentation” is because much of the information is implied, because of the MEF story?

    Cheers!

    Paul
    PaulSPatterson.com

    • Hey Paul!
      Thanks for the kind words!
      I’m quite sure the lack of documentation on these topics is justified because of
      a) this is “LightSwitch internals”, not ment to use by any developer other then the LS crew
      b) LightSwitch is still targetted ad the “semi-developer”, who most likely has no interest in these topics.

      However, that doesn’t mean that “LS Hackers” like ourselves don’t want to know these things 🙂

      Keep on hacking 😉

  2. Pingback: Windows Azure and Cloud Computing Posts for 12/28/2011+ - Windows Azure Blog

  3. Pingback: LightSwitch and the MEF story (part 2): using SubSystemLoaders to wire up the application « Silverlight News

  4. Jan,

    Maybe you can help me, I have an issue clearly related to your post. I have a LightSwitch (2011) app running in a dev server, and I tried the official code of the application to run in my computer, but it does not work sending a ton of exceptions among them:

    Could not find file ‘130598668923952332’.
    Could not find file ‘SubsystemService_cache.xml’.
    Could not find file ‘SubsystemLoader_cache.xml’.
    Could not find file ‘AppBridge_cache.xml’.
    Could not find file ‘BaseServices_cache.xml’.
    Could not find file ‘ModelSubsystem_cache.xml’
    Could not find file ‘RuntimeShell_cache.xml’.
    Could not find file ‘PresentationRuntime_cache.xml’.
    Could not find file ‘RuntimeUserCodeCatalog_cache.xml’.
    Could not find file ‘Rules_cache.xml’.
    Could not find file ‘RuntimeServices_cache.xml’.
    Could not find file ‘Utilities_cache.xml’.

    They look like the files you mentioned, in fact they are generated in a directory like:

    C:\Users\\AppData\LocalLow\Microsoft\Silverlight\is\\\1\s\\f\Manifests

    Every time when I run the application. But it simply does not find them and I have no idea why, Can you help me? Can you tell me what I have to add to the configuration for the files to be found?

    Thanks

    Luis

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s