我有Office 2007 VSTO加载项，它使用功能区XML，依此类推。在重新启动后首次启动Office时，它比第二次启动时花费的时间要长得多。加载项在安装期间使用VSTO包含列表注册为vstolocal并受信任。据我了解，这可以避免将其安装到ClickOnce并验证发布者。
那么首次启动很长时间的原因可能是什么？你能给我一些想法吗？
答案 0 :(得分：3)
我们拥有带VSTO插件的Word，首次启动需要20-30秒，第二次启动需要6-7秒。这适用于Word 2007，.NET 3.5和Windows XP。没有加载项的单词冷启动大约需要5秒钟，热启动大约需要2-3秒。在我们的冷启动测试中，Word是第一个在启动后启动的应用程序，也是第一次使用任何.NET代码。
与您一样，我们发现加载项中代码的执行时间对加载时间没有明显影响。使用VSTO意味着必须加载和初始化.NET Framework和VSTO Runtime。速度的下降完全归结为从磁盘加载和.NET / VSTO初始化的开销的某种组合。
当然，提出的第一个“解决方案”是在登录期间无形地启动Word然后终止Word进程，以预热磁盘缓存。当然这只是让机器在启动过程中没有响应45分钟（我猜是因为它增加了磁盘争用）。但是，哇，Word之后很快就开始了（只要它在登录后不久就开始了）。幸运的是，我们没有对用户造成这种解决方案。
我们还编写了一个简单的.NET应用程序，它只需启动，加载一些与Word加载项相同的依赖项并退出。它也将在登录期间进行安排。它确实需要几秒钟的时间启动Word并在日志中添加更多秒，但是当某些用户甚至可能在他们的使用期间不使用Word时，这似乎毫无意义。会话。增加无意义，如果他们确实想要使用Word并且他们在桌面响应后立即启动Word，那么Word将最终与自定义应用程序竞争资源，该应用程序应该为它铺平道路！
我们的情况很复杂，因为我们也有Word模板（VBA）加载项。这些占了启动时间的很大一部分，因为它是需要初始化的第二个运行时，以及从磁盘的某些分散区域加载的更多文件。仅使用VST加载项或仅使用VBA加载项的Word，再到Word，使用VBA和VSTO加载项的Word一起使冷启动时间非线性增加。也就是说，添加更多依赖项会为总数增加更多的加载时间，从而为单个依赖项本身的加载时间增加。
我们也尝试过COM shim向导。使用COM Shim消除了VSTO运行时，但仍允许您在加载项中安全地使用.NET。将我们的VSTO代码转换为与生成的COM Shim一起使用并不太难。这大大改善了加载时间（我没有数据，我认为它将冷启动时间减半，但包括VBA加载项在内）。我们理想的解决方案是使用COM Shim加载.NET加载项，并将所有VBA代码迁移到.NET。当这个解决方案突然出现时，冷启动时间并不是它所带来的大问题，而且优先级被放弃了！
答案 1 :(得分：0)
我也使用.NET v4.0在Outlook，Visual Studio 2010和加载项中遇到此问题。我找到了这个页面：http://blogs.msdn.com/b/vsod/archive/2012/05/19/resolving-performance-issues-with-loading-office-add-ins-vsto-add-ins-or-shared-add-ins.aspx
只是我的观察：空（VSTO）加载项也需要最多5秒才能加载。
所以它可能是加载.NET库的问题。
（至少在我发现这篇文章后，我知道这个问题是真的。）
编辑：重启后的问题可能与.NET冷启动有关。但同样奇怪的是，Windows系统控件 - ＆gt;程序和函数中加载项的安装日期是当前日期。所以看起来每天都新安装加载项？！？