Hi!
I have Office 2007 VSTO add-in, it uses ribbon XML, and so on. When the Office is first started after the reboot, it takes significantly longer time, than when it is started for the second time. The add-in is registered as vstolocal and trusted using VSTO inclusion list during installation. As I understand, this avoids installing it into ClickOnce and verifying the publisher.
So what can be the possible reason of long first-time start? Could you please give me some ideas?
We have Word with VSTO Add-In which takes 20-30 seconds, on first start and 6-7 seconds on second start. This is with Word 2007, .NET 3.5, and Windows XP. Word with no Add-In took about 5 seconds to cold start and 2-3 to warm start. In our cold start testing Word was the first Application started after boot, and the first use of any .NET code.
Like you we found that the execution time of code in the Add-In had no appreciable affect on the load time. Using VSTO means that the .NET Framework and the VSTO Runtime have to be loaded and initialised. The speed hit was all down to some combination of the overhead of loading from disk and the .NET/VSTO initialisation.
Of course the first 'solution' raised was to start Word invisibly during log in then kill the Word process, to warm up the disk cache. Of course this just made the machine unresponsive for an extra 45 odd seconds during boot (I guess because it increased disk contention). But, wow, Word started up quick after that (as long as it was started shortly after log in). Luckily we did not inflict this solution on our users.
We also wrote a simple .NET application, which would simply start, load some of the same dependencies as our Word Add-In and quit. It too would be scheduled during log in. It did take a few seconds off Word start up and add more seconds to the log in time, but it seemed pointless to make that trade off when some of the users might not even use Word during their session. Adding to the pointlessness, if they did want to use Word and they started Word as soon as the desktop became responsive then Word would end up competing for resources with the custom application that was supposed to be smoothing the way for it!
Our situation is complicated because we have Word Template (VBA) Add-Ins also. These account for a good chunk of the start up time as well, as it is a second runtime that needs to be initialised, and more files to load from some scattered areas of the disk. Going from just Word, to Word with just the VSTO Add-In or Word with just the VBA Add-Ins, to Word with VBA and VSTO Add-Ins together gave a non-linear increase in cold start time. That is, adding more dependencies added more load time to the total then the load time of the individual dependency by itself.
We also tried the COM shim wizard. Using a COM Shim eliminates the VSTO runtime, but still allows you to safely use .NET in the Add-In. It wasn't too tough to convert our VSTO code to work with the generated COM Shim. This improved the load time by a good amount (I don't have the figures, I think it halved the cold start time but that was with the VBA Add-Ins included). Our ideal solution would be to use a COM Shim to load the .NET Add-In, and to migrate all of the VBA code to .NET. When this solution was presented suddenly the cold start time wasn't the massive problem it was made out to be and the priority was dropped way down!