When I reference any Office 12 PIA from Visual Studio in the project file XML the reference points to Office 14 despite the fact that when you view the properties of the reference in Visual Studio it claims the path is to the Office 12 PIA as shown in the 'HintPath' in the XML below and in the screenshot.
Can someone please explain this behaviour? Is this binding redirection?
I am guessing this is because I have the Office 14 PIA's in the GAC so Visual Studio uses the latest version of the assembly. What are the implications of keeping the references as is and deploying the application to a target machine that does not have the Office 14 PIA's? Will the application use the Office 12 PIA's?
If I am targeting the Office 12 environment and the application is automatically redirecting to Office 14 should I be concerned that the code will cease to function when the Office 14 PIA's are used?
<Reference Include="Microsoft.Office.Interop.Excel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<EmbedInteropTypes>True</EmbedInteropTypes>
<HintPath>..\..\..\..\Program Files\Microsoft Visual Studio 10.0\Visual Studio Tools for Office\PIA\Office12\Microsoft.Office.Interop.Excel.dll</HintPath>
</Reference>
http://msdn.microsoft.com/en-us/library/15s06t57.aspx
http://msdn.microsoft.com/en-us/library/2fc472t2(v=vs.80).aspx
When you install and register the Office PIAs in the global assembly cache (either with Office or by installing the redistributable package for the PIAs), the binding redirect assemblies are also installed only in the global assembly cache. These assemblies help make sure that the correct version of the primary interop assemblies are loaded at run time. For example, when a solution that references a 2007 Microsoft Office primary interop assembly runs on a computer that has the Microsoft Office 2010 version of the same primary interop assembly, the binding redirect assembly instructs the .NET Framework runtime to load the Microsoft Office 2010 version of the primary interop assembly.
Related
Our build environment is VS 2015 (ideally) targeting .net 4.0
We have just re-worked our visual studio plugins based on the Visual Studio extensibility project template in VS 2015. The resulting VSIX works great on VS 2015 & 2017 RC1.
However I would like to target the VSIX at VS 2010 (and ideally 2012). This is where the problems start....
VS 2010 uses .net 4.0.
I drop the compiler to .net 4.0
The VS 2015 (4.5) assemblies wont load (i.e. Microsoft.VisualStudio.Shell.14.0).
Thats OK as I don't use anything in them, so I drop the references to them in favour of the version 10.0 (2010) ones.
Great the code compiles.
But the VSIX package does not
1>C:\Program Files
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5):
warning MSB3274: The primary reference
"Microsoft.VisualStudio.Imaging, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" could not
be resolved because it was built against the
".NETFramework,Version=v4.5" framework. This is a higher version than
the currently targeted framework ".NETFramework,Version=v4.0".
So the problem seems to be that if I target VS 2010 I need it to build as .net 4.0, but the VS 2015 build script requires .net 4.5.
I'm wondering if its possible to use the VS 2010 build tools in a VS 2015 project? Or must I convert my VS 2015 project back to VS 2010?
UPDATE
Starting to think this is not possible for other reasons...
https://learn.microsoft.com/en-us/visualstudio/extensibility/faq-2017
The new VSIX v3 format is backward compatible with VSIX v2, so you’ll
still be able to have a single VSIX with a single VSIX ID that
supports Visual Studio 2012 and later. The new VSIX v3 format does not
support Visual 2010 and earlier. To support Visual Studio 2010 onward,
you will need to create a separate extension (with a separate VSIX
ID).
I have ran into similar problem, so I have created a Nuget package called VsixUpdater, which can do the VSIX migration automatically if added to a VSIX project, it even works with older versions of Visual Studio (I tested it with 2012), after adding the package the generated VSIX packages will be V3 and 2017 compatible, see https://github.com/axodox/VsixUpdater for details.
Create a seperate project and VSIX for VS 2010 and another for VS 2012 and later. You can have a look at my source here: https://github.com/ErikEJ/SqlCeToolbox
Notice that I require .NET 4.5.1 for my VS 2010 extension also (simply requires that .NET 4.5.1 is present/installed on the PC, and it is built in to Windows 8.1 and later)
In the end I ended up with 2 projects
A project targeting VS 2010 compiled under .Net 4.0 using a version 2.0 manifest (built using VS 2015).
A project targeting VS 2012 + compiled under .Net 4.5
using a version 3.0 manifest (built using VS 2015).
There has been a certain amount of faffing around with references, but it all seems to work. Our only outstanding issue is the code signing, as VS 2015 will not accept anything below SHA256 and VS 2012 will not accept SHA256....
I have a visual studio extension (deployed as .vsix) that needs to support both Visual Studio 2013 and 2015.
The problem is that the extension needs to talk to TFS so it uses the TFS client libraries and in VS2015, these were changed from being GAC deployed to be a nuget package that the consuming app should redistribute.
How should I setup my VS package's references so that it works on both versions of Visual Studio?
I've tried several approaches:
Reference the 2013 GAC dll's: When loading on a VS2015 machine, these DLLs cannot be found.
Reference 2013 GAC dll's but also copy-local (bundle with .vsix): Some other dependency of those DLLs were missing.
Reference 2015 dll's (from nuget) and bundle with .vsix: Loads fine in both 2013 and 2015, but doesn't work in 2013 (actually using TFS functionality fails - for example a call to GetLocalWorkspaceInfo("c:\src\path") returns null)
I would:
Reference the 2013 assemblies, so that you ensure that you only use the API that's available in that version. (2015 is, of course, backward compatible.)
Add an AssemblyResolve hook so that you can load the 2015 assemblies in place of the 2013 assemblies, when they fail to load. Instructions for previous versions are available, but should be similar.
I think that option 3 will mostly work, but the reason your workspace can't be found is because 2013 and 2015 use different workspace caches. I suspect that you could surmount this by building another connection to the server and updating the workspace cache into the 2015 location. Though this points to deeper issues in compatibility: you would be unable to hook up event listeners for VS connection/workspace objects.
I was trying to create a windows forms using the Microsoft.Office.Interop libraries, but I cannot find them. I tried to follow the guides only and installed the Microsoft Office 2010: Primary Interop Assemblies Redistributable, but the references did not show up in the COM tab. I closed VS.NET, restarted my computer and they still did not show.
I am using Visual Studio 2010 with .NET Framework 4.0.3.
PIA is just an interop layer, you need Office installed to see a COM reference. If you reference a COM type library, AND a corresponding PIA is installed correctly, your reference will be replaced by a PIA one. You can also reference the PIA directly by browsing to its folder and add reference, but the PIA won't be functional unless you have Office installed.
Running WinXP SP3, Visual Studios 2005, .NET 2.0. Recently upgraded machine from Office 2007 to Office 2010 sp1.
I had a project that referenced Microsoft.Office.Interop.Word and when I reopened it the reference was not found. I've checked the Office install CD and ".NET Programmability Support" is selected as installed. If I go to C:\Windows\assembly I see Microsoft.Office.Interop.Word Version 14.0.0.0 installed on the list.
When I go to Add Reference .NET tab, the only Office references I see are Microsoft.Office.Tools.Common, Microsoft.Office.Tools.Excel, Microsoft.Office.Tools.Outlook, Microsoft.Office.Tools.Word.
I can go to the COM tab and add Microsoft Office 14.0 Object Library to get the reference to Microsoft.Office.Core. However I have been unable to find a way to reference the Interop assembly.
Doing a file search on my machine for Microsoft.Office.Interop.Word.dll also finds no matches.
I've repaired the Office install and still no luck. I also tried to install the PIAs directly, same behavior.
Could this be an issue with trying to use Office 2010's interop assembly with VS2005? I saw online that the directory the dll is found in is usually under Program Files\Visual Studios 10.
Any thoughts on what step I'm missing?
You can install Office 2010 PIA separately. Installer can be downloaded from http://www.microsoft.com/download/en/details.aspx?id=3508
Does VSTO 3.0 (using Visual Studio 2008) support both Office 2003 and Office 2007 installed side-by-side on a single development computer so that both Office 2003 and Office 2007 can be targeted (in separate solutions)?
I have seen conflicting information about this.
NO: http://msdn.microsoft.com/en-us/library/bb398242.aspx
Visual Studio Tools for Office does not support installing Microsoft Office 2003 and the 2007 Microsoft Office system (or different versions of the same application, such as Word 2003 and Word 2007) side-by-side on the development computer. To develop solutions for different versions of Microsoft Office, use a different development computer for each version of Microsoft Office.
YES: http://msdn.microsoft.com/en-us/library/15s06t57.aspx
When you install Visual Studio Tools for Office, the primary interop assemblies are automatically installed to a location in the file system, outside of the global assembly cache. When you create a new project, Visual Studio Tools for Office automatically adds references to these copies of the primary interop assemblies to your project. Visual Studio Tools for Office uses these copies of the primary interop assemblies, instead of the assemblies in the global assembly cache, to resolve type references when you develop and build your project.
These copies of the primary interop assemblies help Visual Studio Tools for Office avoid several development issues that can occur when both the 2003 and the 2007 versions of the Office primary interop assemblies are registered in the global assembly cache.”
Has anyone done this and were there any problems?
You can target both 2003 and 2007 with the same computer - but you need two different programs for that in Visual Studio (e.g. MyCoolThingfor2003.sln and MyCoolThingfor2007.sln) as they have different interops. But you should not have both Office programs installed on that same computer.
You can't install Office 2003 and 2007 side by side. The two links you posted talk about different things. The first link says no to installing the actual Office 200x application, whereas the second link refers to the PIA (which is just a wrapper). You can install any version of the PIAs on a computer side by side, but it doesn't mean it'll launch different versions of office.
If your goal is to develop a VSTO addin that supports both Office 2003 and Office 2007, then you'll need to develop on a system with VS2008 + Office 2003.