The technique for adding a reference to the COM interop of Office in Visual Studio is to go to:
References
Add Reference
Select the COM tab
Select Microsoft Office 11.0 Object Library
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;
}
Questions
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?
6) If i install the Office 2007 Primary Interop Assemblies do i have to have Office 2007 installed?
7) What is wrong with using standard COM interop to drive Excel, Word, or Outlook? e.g.:
[ComImport]
[Guid("00024500-0000-0000-C000-000000000046")]
public class Excel
{
}
8) What is one achieving when one adds a
Reference to items on the COM tab,
as opposed to using [ComImport],
as opposed to using the Office 2007 Primary Interop Assemblies?
9) Is adding a reference using the COM tab identical to using COM interop, except that it needs a type library before you can see it?
10) Are the Office 2003 Primary Interop Assemblies backwards and forwards compatible with:
- Office 14
- Office 2007
- Office 2003
- Office XP
- Office 2000
- Office 97
- Office 95
If a customer, and a developer, installs a new version of Office, will it still work?
11) Do we have to ship the Office 2003 Primary Interop Assemblies with our application?
12) Does the customer have to install the Office 2003 Primary Interop Assemblies before they can use our application?
13) If a customer installs the Office 2003 Primary Interop Assemblies do they have to have Office installed?
14) If a customer installs the Office 2003 Primary Interop Assemblies do they have to have Office 2003 installed?
15) Are the Office 2003 Primary Interop Assembles a free, lite, redistributable version of Office 2003?
16) If my development machine has Office 2007, can i use the Office 2003 PIAs, and ship to a customer with Office XP installed?
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.
The answer is to "Copy Local" whatever assembly dll you get for the interop. Once you have the assembly dll in your output folder, add a reference to it, and check it into source control.
Now everyone has the referenced assembly dll.
do you use VSTO (Visual studio tools for office)?
http://msdn.microsoft.com/en-us/office/aa905533.aspx
An old thread, and probably most people would be happy with CopyLocal=True, however here's another way..
Use both (or more..? thinking Office 2010 if the problem still exists..) references in your project files, and either ignore or just tell MSBuild to ignore the "MSB3284" warning (Library not found).
So include this in your .csproj file:
<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>
Followed by:
<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>
I would be interested to see if Microsoft provides a NuGet library for this - just to get everyone on to the same approach. I think that would remove the necessity for people to search the web for these answers... I believe this would be against Microsoft Office's license so they are the only ones to supply it.
BTW with copy local you have to be careful not to redistribute these library by mistake.
Related
Is this dll a part of visual studio tools for office or Microsoft Office Word s/w?
PIAs are just intermidiate files that are used in transferring/marshalling calls between mananged/unmanaged boundaries. For example, they are used to convert managed types to unmanaged ones. You can generate them on your own without VS involved. Under the hood, VS uses the same tools to generate them when you add an unmanaged references (COM).
You can read more about PIAs in the Office Primary Interop Assemblies section in MSDN.
I am working in Visual Studio 2012 and I was missing the "Microsoft.Office.Interop.Excel" assembly. After downloading the missing exe from http://www.microsoft.com/en-us/download/details.aspx?id=3508,
the instructions are as follows:
"Wrap the O2010pia.msi file in another setup package through Visual Studio or other Windows Installer aware setup editor"
I ran the exe, but the missing assembly is still missing from Visual Studio.
I am quite new to development and after googling for a while, I am no closer to understanding what this means. I would greatly appreciate some insight.
You did not read it correctly. The page says "Use one of the following installation methods". The one you are asking about is what you do when you create an installer for your program so the PIA also gets installed on your client's machine. You are not there yet.
You should not be doing this anymore, PIAs are outdated since VS2010. Replaced by the "Embed interop types" feature, aka "NoPIA". Project, Add Reference, click COM, select the "Microsoft Excel xx.x Object Library" entry where xx.x is the version number of Office you've got installed on your machine. This automatically adds the Microsoft.Office.Core and Microsoft.Office.Interop.Excel references to your project. With their Embed Interop Types property set to True so you don't have to install anything on the client's machine.
If you don't see this entry then you will need to install Office on your machine. Required to add the reference and to debug and test your code.
Working on a piece of code that interacts with a sharepoint app on a separate (SP) server. I'm using VS2010 and have referenced and installed Microsoft.SharePoint dll (2007 version) in my Windows Formd project.
VS is not picking up the SharePoint class Microsoft.SharePoint.SPWeb and SPSite. The entire line is like this: Microsoft.SharePoint.SPWeb sp_web = new Microsoft.SharePoint.SPSite("mySPsiteurl").OpenWeb();
The SPWeb and SPSite do turn teal as soon as I add their name space in the refereces, but as soon as I run the app they turn black and throws an error of missing assembly reference.
Any ideas as why is this happenning?
Thanks,
Risho
How would you added this Microsoft.SharePoint dll for 2007 ? did you copy that manyually in File System ?
The Sharepoint 2007 .NET assemblies will not appear in the .NET tab because by default they will include SharePoint 2010 assemblies.
However if you create a Sharepoint 2007 project in VS2010 (the two 2007 workflow projects we have under the Sharepoint tab) these 2007 assemblies will be added for you and by this the SPWeb and SPSite will also be available to you and vanishes your error.
Hope this helps
I have a C# project in Visual Studio 2005 that is referencing a few COM libraries. When I build it errors like this are thrown:
Referenced assembly 'assemblyName' does not have a strong name.
Now, I used to reference COM assemblies in Visual Studio 2003, and it would automatically sign the Interop wrappers. All I had to do was set the setting 'Wrapper Assembly Key File'.
I tried finding a similar setting in Visual Studio 2005, but I couldn't find any. So I was wondering if there's any equivalent way of strong naming COM Interops in Visual Studio 2005 and getting rid of the above error.
It looks like it was already answered in "Where is the Wrapper Assembly Key File setting in VS 2008?" question.
Instead of using Visual Studio you could use Tlbimp.exe and
Aximp.exe to generate the Interops. Tlbimp.exe has options for signing.
I have used them to be generate an Interop file for each different version of the same COM component in my application. The COM components are vendor supplied COM components used for accessing data points in mass spectrometry files and the COM interface change from time to time as new versions of the vendor software is released. The application can then decide at runtime which Interop to use in order to match what version is installed on the computer where the application is installed.
The BAT file I use for generating the Interops is online.
I have installed the 2007 PIA and repaired my Office 2007 installation.
Still, when I add a reference to the Office 12 Object Library in VS2005, I only see Office.Core and cannot add an 'imports' statement for Office.Interop
I have checked that Windows\assembly\gac\ has got the interop dlls.
With the PIAs installed, you have to add a reference to the corresponding COM library - instead of generating an automatic interop, the PIA will be used instead.
To quote Microsoft's documentation
For Microsoft Office applications that do not have projects in Visual Studio Tools for Office, you must add a reference to the appropriate application or component to your project manually. Adding a reference to the component references the primary interop assembly, if the assembly is installed in the global assembly cache. Office applications and components are accessible from the COM tab of the Add Reference dialog box.
Add a browse reference. You have to ship the PIA dll to get any benefit out of it anyway.