深入.NET程序集加载

这个问题是一个有关.NET公共语言运行时的问题。大家知道，.NET为了提高程序性能，所有程序集是按需加载的，也就是说在必要时在加载。但是，你知道程序集确切的加载时机吗？绝大多数情况下，我们都不需要关心程序集的加载时机，不过，当我们在做程序自动升级的时候就碰到一些非常有趣的事情了。下面我先抛出问题。

首先，我们先来看看以下这段有问题的程序，你觉得哪有问题。我先来解释一下这段程序的用处：

（1）在WPF的App这类的构造函数中检测内核文件更新并启动OSGi.NET内核；

（2）UpdateCoreAndStartBundleRuntime的作用就是：A）更新UIShell.iOpenWorks.BundleRepositoryOpenAPI、UIShell.PageFlowService、UIShell.OSGi等程序集；B）在内核程序集更新完成后，创建一个BundleRuntime（表示OSGi.NET插件内核，来自UIShell.OSGi程序集）。

namespace UIShell.iOpenWorks.WPF
{
    /// <summary>
    /// WPF startup class.
    /// </summary>
    public partial class App : Application
    {
        private BundleRuntime _bundleRuntime;

        public App()
        {
            UpdateCoreAndStartBundleRuntime()
        }

        void UpdateCoreAndStartBundleRuntime() 
        {
            // Update Core Files, including BundleRepositoryOpenAPI, PageFlowService and OSGi Core assemblies.
            if (AutoUpdateCoreFiles)
            {
                new CoreFileUpdater().UpdateCoreFiles(CoreFileUpdateCheckType.Daily);
            }

            // Start OSGi Core.
            var bundleRuntime = new BundleRuntime();
            bundleRuntime.AddService<Application>(this);
            bundleRuntime.Start();

            Startup += App_Startup;
            Exit += App_Exit;
            _bundleRuntime = bundleRuntime;
        }

     // Other codes...
    }
}

上面这段代码很简单，但是是错误的，下面我们稍作细微调整，代码就能够正常工作了。

namespace UIShell.iOpenWorks.WPF
{
    /// <summary>
    /// WPF startup class.
    /// </summary>
    public partial class App : Application
    {
        // Use object type to avoid loading UIShell.OSGi.dll before update.
        private object _bundleRuntime;

        public App()
        {
            UpdateCore();
            StartBundleRuntime();
        }

        void UpdateCore() // Update Core Files, including BundleRepositoryOpenAPI, PageFlowService and OSGi Core assemblies.
        {
            if (AutoUpdateCoreFiles)
            {
                new CoreFileUpdater().UpdateCoreFiles(CoreFileUpdateCheckType.Daily);
            }
        }

        void StartBundleRuntime() // Start OSGi Core.
        {
            var bundleRuntime = new BundleRuntime();
            bundleRuntime.AddService<Application>(this);
            bundleRuntime.Start();

            Startup += App_Startup;
            Exit += App_Exit;
            _bundleRuntime = bundleRuntime;
        }
        // Other codes ......
    }
}

正确的代码和错误代码的差异有二：

（1）_bundleRuntime的类型由BundleRuntime变为object；

（2）将UpdateCoreAndStartBundleRuntime函数拆分成两个函数，分别为UpdateCore和StartBundleRuntime。

这两段代码的差别非常细微，从功能的角度来看，没有任何的差异。各位聪明的看官，为什么第一段代码是错误的呢？这就是.NET程序集晚加载所引起的。那我们先来看看，以下这段代码，BundleRuntime这个类型被使用并创建了一个实例，那么，这个方法一旦执行完成，UIShell.OSGi（BundleRuntime类型所在程序集）这个程序集肯定被加载了。但是，确切加载时机是什么时候？是在调用“var bundleRuntime = new BundleRuntime()”这行代码时，UIShell.OSGi所在程序集才加载吗？正确的答案是：UIShell.OSGi程序集加载时机是CLR进入UpdateCoreAndStartBuntime这个方法入口时，CLR会将这个方法所用到的类型的所在程序集全部加载进来。这样问题就来了，也就是在执行UIShell.OSGi这个程序集更新之前，UpdateCoreAndStartBuntime方法刚刚调用时，UIShell.OSGi程序集就会被加载，这是，你执行对UIShell.OSGi程序集更新的时候，就会碰到异常，提示这个文件已经被占用了。

void UpdateCoreAndStartBundleRuntime() // Update Core Files, including BundleRepositoryOpenAPI, PageFlowService and OSGi Core assemblies.
        {
            if (AutoUpdateCoreFiles)
            {
                new CoreFileUpdater().UpdateCoreFiles(CoreFileUpdateCheckType.Daily);
            }

            var bundleRuntime = new BundleRuntime();
            bundleRuntime.AddService<Application>(this);
            bundleRuntime.Start();

            Startup += App_Startup;
            Exit += App_Exit;
            _bundleRuntime = bundleRuntime;
        }

我们可以在该代码加上一个测试代码，然后看看UIShell.OSGi是否是刚进入方法之时，执行更新之前就加载了。答案是肯定的。这段代码很好说明了，BundleRuntime这个类型所在程序集UIShell.OSGi是在声明这个类型的方法调用时就加载。

以上问题的解决方法非常简单，就是将上面两段不同功能代码拆分到不同的函数。此时，我们可以再来调试一下代码。

你可以发现拆分后，这个问题就可以解决了。好了，大家应该明白关于程序集加载的确切时机了。不过，如果大家还想追究为什么程序集加载时机是在进入方法时，你还可以深入研究《.NET本质论》这本书，我建议大家看该书英文版的，对于深入理解CLR有非常大的帮助。

有任何技术问题，可以加入iOpenWorks插件仓库平台QQ交流群： 121369588。

本文基于Creative Commons Attribution 2.5 China Mainland License发布，欢迎转载，演绎或用于商业目的，但是必须保留本文的署名道法自然（包含链接）。如您有任何疑问或者授权方面的协商，请给我留言。