Friday, May 23, 2008 3:29 PM
I have a situation where we have product level build machines with a very controlled environment.
We are using VS2008 and Office 2007 projects to create addins for Word, Excel, and Outlook. Our developer machines have full VS2008 and Office 2007 environments for debug & test. The product level build machines do not have Office installed, just VS2008.
The issue we see is that Word and Excel addin projects build fine, but the Outlook addin project fails on the build machine. MSBuild verbose output shows the RegisterFormRegions build task failing:
Task "RegisterFormRegions" (TaskId:57)
C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.Office2007.targets(154,9): error : Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Done executing task "RegisterFormRegions" -- FAILED. (TaskId:57)
Done building target "VisualStudioForApplicationsBuild" in project "TcOutlookAddin_vs08.csproj" -- FAILED.: (TargetId:140)
Target "_CheckForCompileOutputs" skipped. Previously built successfully.
Target "_SGenCheckForOutputs" skipped, due to false condition; ('$(_SGenGenerateSerializationAssembliesConfig)' == 'On' or ('@(WebReferenceUrl)'!='' and '$(_SGenGenerateSerializationAssembliesConfig)' == 'Auto')) was evaluated as ('Off' == 'On' or (''!='' and 'Off' == 'Auto')).
Target "_CleanGetCurrentAndPriorFileWrites: (TargetId:75)" in file "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets" from project ".<...deleted......>\Addins\TcOutlookAddin\TcOutlookAddin_vs08.csproj":
Using "ReadLinesFromFile" task from assembly "Microsoft.Build.Tasks.v3.5, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "ReadLinesFromFile" (TaskId:58)
If we have Office 2007 on the build machine - this target is successful. Why do we need Office installed on the product level build machine?
I understand the need for Office to support runtime debugging & development. What is the RegisterFormRegions task doing that requires Office? Is there some assembly or COM object we can reference directly to avoid the error?
Wednesday, May 28, 2008 8:49 PM
RegisterFormRegions task has two functions during the build process:
Create a list of form regions defined in your add-in and return it as an output parameter for the add-in manifest creation phase.
Register the form regions by creating the appropriate entries in the registry.
Current;y, I believe the second step is what is causing you a problem. To find the form regions in the add-in, we use reflection to look for types marked with the FormRegionName attribute. Reflection requires all types to be fully resolvable and therefore all dependencies must be satisfied. FormRegionNameAttribute class is defined in Microsoft.Office.Tools.Outlook.v9.0.dll, which is part of the VSTO Runtime. However this assembly has its own dependencies, in particular I believe Microsoft.Office.Interop.Outlook.dll and Microsoft.Office.Interop.Forms.dll are the ones that would cause you trouble if you haven't installed Office.
My first recommendation would be to install Office PIA's in your server (there is a downloadable installer in MSDN). This should provide the missing dependencies. To be in the safe side, or if you need to diagnose any further problem, you can enable fusion log (fuslogvwr.exe) to check for what particular assembly is not present.
If you do not have any form region in your add-in and feel confortable playing with msbuild:
- Create a copy %ProgramFiles%\MSBuild\Microsoft\VisualStudio\v9.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.Office2007.targets
Disable RegisterFormRegions task by modifying its Condition attribute or removing it completely from the new .targets file
Modify your project file (.csproj/.vbproj) so it references your new .targets file.
Note: Remember that this approach will break Form Regions for your add-in as not only they do not get registered anymore but also the manifest generation task will not know anything about them.
Hope this helps.
Thursday, May 29, 2008 5:03 PM
Thanks for the information. The suggestion to look at the fusion log helped. It indicated that Microsoft.Office.Interop.Outlook was not found. I had done the PIA install - from o2007pia.msi, but in looking at the GAC, none of the Office.Interop dlls are there. After doing some logging in msiexec and reading the pia readme, it seems to indicate that the PIAs won't install unless it finds the associated Office app.
From the o2007pia_readme.rtf
Minimum system requirements to install the Office 2007 Primary Interop Assemblies are:
1 A Microsoft Office System 2007 product
2 .NET Framework 1.1 or higher
-This does make sense as the PIAs are basically just wrappers to the Office COM interfaces.
So if we have to install Office to be able to add the PIAs, then why not do the PIA install as part of the Office setup. It appears to me as if the PIA install would only be useful in the case that the original Office install did not include the PIAs (Net interop feature).
Unless there is a way to force the PIA install to proceed without the Office component, it appears as if we're left with installing Office on our build server.
Can you confirm?
Our Outlook Addin does contain a FormRegion, so altering the build target is not an option.
Thursday, May 29, 2008 6:36 PM
I am sorry, I forgot that the PIA redistributable would only install PIAs for Office apps that already installed. In this case, installer is too smart for your own good.
However, we only need to have the PIAs for type resolution not really to interact with Office so no need to have the native Dlls (or a full Office installation).
I believe there is a workaround here:
Get the Outlook PIA from one of your dev machines and place it in the GAC of your server using gacutil.exe.
Repeat step 1 for every required assembly (using fusion again will help you here).
Let me know if this helps.
Friday, May 30, 2008 3:02 PM
The work-around mentioned above does seem to do the trick.
I pulled the Microsoft.Office.Interop.Outlook (V126.96.36.199) PIA from a dev machine and put that in the gac on the build machine (gacutil -i). Fortunately that was the only assembly I had to add. The outlook addin project then built successfully without the RegisterFormRegions build task error.
I did not have to bring over any of the other interop assemblies for my scenario.
Thanks for the help.