Hi Pete
Sorry to hear you're having problems with this. Can you provide a few more details, please
1. When you install VSTO 2005 SE (design-time, Visual Studio) on top of VSTS 2005 or VSTO 2005, you should end up with 3 different Outlook add-in project templates:
It's not clear from your post which of these 3 you're using
2. Just to confirm, you have installed VSTO 2005 SE (design-time, Visual Studio), right This will chain the install of VSTO 2005 SE runtime. Can you confirm in control panel that you do have both of these installed (not just the old VSTO 2005 runtime)
3. Is this Outlook 2003 or 2007
4. Did you have an earlier VSTO v3 CTP installed on this machine There are known problems if you install VSTO 2005 SE on top of any pre-release version.
Hi Pete,
You might also want to refer to the following thread: http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=818608&SiteID=1 . I've provided a comprehensive set of things to look for when you encounter this problem. The application in that post is Excel, but the principles are going to be the same. I think (but can't remember for sure) that the error message you are getting is generic. If so, you can set VSTO_SUPPRESSDISPLAYALERTS=0 in your environment prior to launching Outlook and you should get the real exception. If I had to guess I would think CAS is still the problem. Remember that the customization must be trusted by all four policies and that AppDomain policy will not grant full trust based solely on All Code or Zone groups. So you will need to explicitly trust the customization by some other means--such as trusting a specific location or a strong name.
Sincerely,
Geoff Darst
Microsoft VSTO Team
Hi guys,
First off, I want to thank the VSTO team for being open and responsive to queries. I hassled Eric Carter first (but felt somewhat justified since I bought the VSTO book ;) ) and he passed me over to Misha. To clarify my setup, I have VS 2005 Professional loaded on XP SP2. I also had VSTO 2005 installed, but the release version, I've never installed any betas. I then loaded VSTO 2005 SE. I manually checked CAS, it's as expected since VS set it up automatically. Per Misha I enabled mixed debugging and sent some information which showed that it isn't getting to the point where managed code is being loaded. This may explain why there are no details, and why setting logging or doing the displayalerts does nothing.
I just loaded the same setup VS 2005 + VSTO 2005 + VSTO 2005 SE on an XP SP2 work machine here (I'm having trouble with the home machine), and everything works fine when I select the Outlook 2003 Add-In and do a Hello World mod to the basic template. The only real differences between the home and office machines is that at home I run Outlook (same 2003 SP2 version) in Internet Only mode, while at work of course it's in Corporate mode talking to an Exchange Server. I don't imagine that would be an issue (though I understand some Extended MAPI things are not available in this mode) or it would surely have been noticed by now. The only other difference I can think of for the home setup is I'm running Spyware Doctor 4.0, which I don't trust as far as I can throw. ;) Not sure how that could interfere, but I'll run a test with it disabled. I'm waiting to hear back from Misha on my last email (I had to modify my return message three times before it seemed to get past the MS spam filter), but I will try the more advanced debug checking that Geoff discusses in the link. Thanks,
Pete
Hi Geoff,
I tried the steps you outlined in your linked post. AddinLoader.dll *is* being loaded, however the fuslogvw viewer doesn't give me any information after hitting Refresh. Managed and native debugging is enabled, and all exceptions are enabled. Am I using the Fusion viewer incorrectly, or does this help narrow it down
Pete
Hi Pete,
As long as you are running the fuslogvw that matches the version of the runtime being used (i.e. you aren't running the x64 version for example), the lack of any entries would suggest that we were never able to create the AppDomain. That seems pretty suspicious. I wonder if the NDP is loading at all Try setting COMPlus_LoadLogDir=c:\shimlogs in your environment (make sure you create c:\shimlogs) and then try loading your Outlook add-in again. Then go to your shimlogs directory and check for the presence of a logfile. The logfile should tell you what version of the runtime was loaded and where it found it. Let me know what it says; perhaps that will give us a hint as to what is going on.
Geoff Darst
Microsoft VSTO Team
Hi Geoff,
I'll do that this evening. In the meantime, I noted that the Outlook startup error message comes up at a point where the debugger window shows the VSTOLoaderUI.dll being loaded. In the modules window, that entry has a red exclamation mark with the error on mouseover showing "The module did not load at the default load address". Here is the entry:
VSTOLoaderUI.dll C:\Program Files\Common Files\Microsoft Shared\VSTO\8.0\1033\VSTOLoaderUI.dll N/A N/A Binary was not built with debug information. 38 8.0.50727.42 (RTM.050727-4200) 9/23/2005 2:35 AM 01C70000-01C74000* [3956] Outlook.exe: Native
Not sure if that helps, I will try your other suggestion and post the result, thanks.
Pete
Hi Pete,
That error message signifies a potential performance issue, but not a code bug. When you build a dll, you provide a base address at which that dll should be loaded and assumptions are made regarding function addresses that take this location into account. When a dll loads at a base address other than its default, the loader has to go through all of the images which reference the dll and provide relocation information so the function calls will resolve to the right address. This has a negative effect on load time (which is why the modules window flags it). This is why when you build your own applications, you should examine all of the load address for your dlls and adjust them so there are no conflicts. In addition, when you publish your own dlls, you should base them at something other than the default load address. If you are interested, the Rebase SDK topic provides more information about what addresses to use: http://ca.geocities.com/johnmartzouco/pages/Rebase_help_from_PlatformSDK.htm. Anyway, I'm not sure if this is a bug on our end or just luck of the draw. We don't have control over what Outlook loads and we also have to load in multiple applications. As a result, there isn't any base address choice that we can make which would be guaranteed to be free from conflict.
One other thing that occurs to me regarding your issue. When you ran fuslogvw, did you go into settings and actually turn it on By default, the log is off; you need to explicitly choose to either log all loads, just failures, etc.
Sincerely,
Geoff Darst
Microsoft VSTO Team
*** Assembly Binder Log Entry (12/6/2006 @ 10:35:05 PM) ***
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.
Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Office.Interop.Outlook, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
(Fully-specified)
LOG: Appbase = file:///C:/Program Files/Microsoft Visual Studio 8/Common7/IDE/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : Microsoft.Build.Tasks, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe.Config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Microsoft.Office.Interop.Outlook, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
LOG: Found assembly by looking in the GAC.
LOG: Binding succeeds. Returns assembly from C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Outlook\11.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Outlook.dll.
LOG: Assembly is loaded in default load context.
*** Assembly Binder Log Entry (12/6/2006 @ 10:36:43 PM) ***
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.
Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Build.Framework, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
(Fully-specified)
LOG: Appbase = file:///C:/Program Files/Microsoft Visual Studio 8/Common7/IDE/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
===
LOG: Start binding of native image Microsoft.Build.Framework, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: Start validating native image Microsoft.Build.Framework, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: Start validating all the dependencies.
LOG: [Level 1]Start validating native image dependency mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: Dependency evaluation succeeded.
LOG: Validation of dependencies succeeded.
LOG: Start loading all the dependencies into load context.
LOG: Loading of dependencies succeeded.
LOG: Bind to native image succeeded.
Native image has correct version information.
Attempting to use native image C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\Microsoft.Build.Fra#\2853945a44b41a4c903a09415c37fd08\Microsoft.Build.Framework.ni.dll.
ZAP: An ngen image of an assembly which is not loaded as domain-neutral cannot be used in multiple appdomains - abandoning ngen image. The assembly will be JIT-compiled in the second appdomain. See System.LoaderOptimization.MultiDomain for information about domain-neutral loading.
Discarding native image.
Hi Pete,
Sorry for the delayed response. A massive storm took down our power for several days. Anyway, the bad news is that the fusion log isn't suggesting anything wrong with your system that would prevent the AppDomain from getting created. That is bad news because that error message occurs when a failure bubbles up through a whole lot of code. So we have a generic error message that could apparently have been triggered by a wide variety of problems. I think at this point, the only way we are going to get an answer to this is if you send me a dump. If you don't have windbg, please download it from http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx. Then please configure it to use the Microsoft public symbol server (see http://support.microsoft.com/kb/311503/). I can't remember whether this step matters; it may be that I can use my own symbols after the fact with a dump file, but I'd rather be safe then sorry. Once you've got that setup, try to load your add-in. Once you have reached the "office document customization is not available" dialog, please generate a dump. You can do this by running the following batch file:
>>>>>>>>>>>>>>>>>>>>>>>>>
@REM **********************************************
@REM Generates a dumpfile for the specified process
@REM
@REM Geoff Darst 7/6/2006
@REM **********************************************
@echo off
if not "%_echo%"=="" (
echo on
)
SetLocal
set DebuggerPath=%ProgramFiles%\Debugging Tools For Windows
set DumpOptions=/ma
set DumpDir=c:\dumps
set DumpFile=%DumpDir%\%date:~4,2%.%date:~7,2%.%date:~10,4%.%time:~0,2%.%time:~3,2%.%time:~6,2%.dmp
goto ParseCommandLine
:ParseCommandLine
:Do
if "%1"=="/ " (
goto Help
)
if "%1"=="- " (
goto Help
)
if "%1"=="/p" (
goto ParseProcessId
)
if "%1"=="-p" (
goto ParseProcessId
)
if "%1"=="/out" (
goto ParseOut
)
if "%1"=="-out" (
goto ParseOut
)
goto Help
:While
shift
if "%1"=="" (
if "%ProcessId%"=="" (
goto Help
)
if "%DumpFile%"=="" (
goto Help
)
goto GetDump
)
goto Do
:ParseProcessId
shift
set ProcessId=%1
goto While
:ParseOut
shift
set DumpFile=%1
set DumpDir=%~p1
goto While
:GetDump
if not exist %DumpDir% (
echo Creating dump directory at %DumpDir%
md %DumpDir%
)
if exist "%DumpFile%" (
choice /c:YC /M "%DumpFile% exists. Press "Y" to overwrite or "C" to cancel."
if ERRORLEVEL==2 (
goto Done
)
if ERRORLEVEL==1 (
goto Overwrite
)
)
goto Dump
:Overwrite
del /f %DumpFile%
goto Dump
:Dump
"%DebuggerPath%\windbg" /p %ProcessId% /pv /Q /c ".dump %DumpOptions% %DumpFile%;q"
goto Done
:Help
echo.
echo Generates a dumpfile for the specified process
echo.
echo Usage: GetDump /p ^<Process Id^> [/out ^<Dumpfile^>]
echo.
echo GetDump /p 401 /out c:\devenv_dump.dmp
echo.
echo If you do not specify a dumpfile, the dump will be written to
echo c:\dumps\<mm.dd.yyyy.hh.mm.ss.dmp>
goto Done
:Done
EndLocal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
If you can mail me the dump file at geoffda@microsoft.com, I'll take a look and see if I can get a better idea of what is happening. What I'm hoping for is to get a meaningful HRESULT failure which will give us a clue as to the problem. That said, it may be that there won't be enough information to debug this post-mortem.
Sincerely,
Geoff Darst
Microsoft VSTO Team
Hi Geoff,
Sorry to hear about the bad weather up there. I've always wondered why MSFT doesn't move someplace with nicer weather, like down here in Southern California. ;) It may take a day or so to get the dump for you, but I will send it on, thanks.
Pete
Hi Pete,
Just so you know I'll be out for the holidays after Wednesday, so if you don't get it to me before then I'll look at it when I get back on Jan. 2nd. Also, would you please add an entry to this thread when you've sent the log. That way I'll know to be looking for your e-mail.
Thanks,
Geoff Darst
Microsoft VSTO Team
We've finally gotten to the bottom of this. The problem was that the permissions on HKCR\VSTOInterop.InteropAppDomainManager were incorrect. There was no ACE for the built-in Users account and the built-in Administrator's account only had Read control. Resetting the appropriate permissions resolved the issue.
Geoff Darst
Microsoft VSTO Team
Hey, I was gonna say that. ;) Just wanted to publicly thank Geoff for going above and beyond with the diagnostics and debugging.
Pete