The technique for adding a reference to the COM interop of Office in Visual Studio is to go to:
And magically named reference appears:
Microsoft.Office.Core
The Project.csproj
file shows the details of the reference:
<COMReference Include="Microsoft.Office.Core">
<Guid>{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}</Guid>
<VersionMajor>2</VersionMajor>
<VersionMinor>3</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>primary</WrapperTool>
<Isolated>False</Isolated>
</COMReference>
And the project is checked into source control and all is well.
Then a developer with Office 2007 gets the project from source control, and cannot build it because such a reference doesn't exist.
He (i.e. me) checks out the .csproj file, deletes the reference to
Microsoft Office 11.0 Object Library
and re-adds the COM reference as
Microsoft Office 12.0 Object Library
And magically a named reference appears:
Microsoft.Office.Core
The Project.csproj
file shows the details of the reference:
<COMReference Include="Microsoft.Office.Core">
<Guid>{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}</Guid>
<VersionMajor>2</VersionMajor>
<VersionMinor>4</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>primary</WrapperTool>
<Isolated>False</Isolated>
</COMReference>
And the project is checked into source control and all is well.
Then a developer with Office 2003 gets the project from source control, and cannot build it because such a reference doesn't exist.
He (i.e. not me) checks out the .csproj file, deletes the reference to
Microsoft Office 12.0 Object Library
and re-adds the COM reference as
Microsoft Office 11.0 Object Library
And magically a named reference appears:
Microsoft.Office.Core
The Project.csproj
file shows the details of the reference:
<COMReference Include="Microsoft.Office.Core">
<Guid>{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}</Guid>
<VersionMajor>2</VersionMajor>
<VersionMinor>3</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>primary</WrapperTool>
<Isolated>False</Isolated>
</COMReference>
And the project is checked into source control and all is well.
Then the project is built, pressed onto CDs, and sent to the customers who have Office 2007.
And all is not well.
In the olden days (i.e. before .NET dll hell), we would reference the Office objects using a version independant ProgID, i.e.:
"Excel.Application"
which resolves to a clsid of the installed Office, e.g.
{00024500-0000-0000-C000-000000000046}
of which a class is then constructed using a call to COM (language-netural pseudo-code):
public IUnknown CreateOleObject(string className)
{
IUnknown unk;
Clsid classID = ProgIDToClassID(className);
CoCreateInstance(classID, null,
CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER,
IUnknown, out unk);
return unk;
}
1) What is the approved technique to automate the installed Office applications?
2) What are the Office 2003 Primary Interop Assemblies useful for?
3) If i use the Office 2003 Primary Interop Assemblies, do i have to have office 2003 installed?
4) If i build with the Office 2003 Primary Interop Assemblies, are my customers tied to Office 20003 forever?
5) Are there any Office 2007 Primary Interop Assemblies
Wow that's a huge number of questions. I think that in general if your app is using the PIAs then you're assuming that your target audience has some version of Office installed. The PIAs will be installed in the GAC when the target user installs Office. If they don't have Office installed then why are you targeting Office?
Yes, the Office dlls are the correct way to automate Office. There's a list of the assemblies here, including some for Office 2007.