My Solution
Okay, so after a lot of banging my head against the wall -- finding out the msbuild properties, conditions, and project inlcudes don't work for/in the ProjectExtensions section, I figured out an additional hack that makes my .csproj work in Visual Studio 2013 [Update 3] whether the developer has Office 2010 or Office 2013 installed (it's detailed in the second bullet point below -- which is not required for the same behavior in VS 2010, YMMV for VS 2012).
To make your project work this way you need to do these three things:
Hand edit your .csproj file and find all the office interop assembly references -- make sure the version is set to version "14.0.0.0" (as opposed to "15.0.0.0") and that the "SpecificVersion" child element is present and set to "False".
Under the Project\ProjectExtensions\VisualStudio\FlavorProperties\ProjectProperties element find the "OfficeVersion" attribute/value pair and remove it (so the attribute that reads OfficeVersion="14.0" -- delete that). -- Leave all other 14.0s intact, if anything got changed to 15.0, downgrade it back to 14.0 (and again, if it's a reference, set SpecificVersion to false). -- Do not worry about changing any GUIDs, just leave them as they are!
At this point, the solution will open and compile on machines that are running Visual Studio 2013 whether they have Office 2010 or Office 2013. -- But it will not start the solution on machines running Office 2013. To fix that:
- Open regedit and navigate to HKLM\Software\Microsoft\Office\
- Export the entire 15.0 branch to a .reg file.
- Open the file in notepad and change all registry path occurrences of "15.0" to "14.0".
- Re-save the file (make sure you save it as unicode).
- Import the file & restart Visual Studio. -- This will allow you to start with debugging with Office 2013.
One other thing to keep in mind -- especially if you use EmbedInteropTypes, make sure that when you do your release / publish build that you do it from a machine with Office 2010 (and not 2013) installed, so that the published assembly is built against the Office 2010 specific libraries. -- This will maintain that you have backward and forward compatibility between the two versions.
Again, this worked for me for a Word Add-in -- For an Excel Add-in YMMV.
Original "Answer" (may contain useful details for others)
I mentioned in comments above that I'm having the opposite problem -- VS 2013 Update 3 is forcibly upgrading my projects if the user has Office 2013 installed.
You can try installing VS 2013 Update 3 (even temporarily, say in a VM) and the latest VSTO 2012 / 2013 version, and opening the project, it should forcibly upgrade yours as well. I know you're using Excel, and I'm using Word, but the section it's upgrading:
Old .csproj XML:
<Project ...>
...
<ProjectExtensions>
<VisualStudio>
<FlavorProperties GUID="{BAA0C2D2-18E2-41B9-852F-F413020CAA33}">
<ProjectProperties HostName="Word" HostPackage="{20A848B8-E01F-4801-962E-25DB0FF57389}" OfficeVersion="14.0" VstxVersion="4.0" ApplicationType="Word" Language="cs" TemplatesPath="VSTOTemplates" DebugInfoExeName="#Software\Microsoft\Office\14.0\Word\InstallRoot\Path#WINWORD.EXE" DebugInfoCommandLine="/w" AddItemTemplatesGuid="{51063C3A-E220-4D12-8922-BDA915ACD783}" />
<Host Name="Word"... />
</FlavorProperties>
</VisualStudio>
</ProjectExtensions>
...
</Project>
New .csproj XML:
<Project ...>
...
<ProjectExtensions>
<VisualStudio>
<FlavorProperties GUID="{BAA0C2D2-18E2-41B9-852F-F413020CAA33}">
<ProjectProperties HostName="Word" HostPackage="{29A7B9D7-A7F1-4328-8EF0-6B2D1A56B2C1}" OfficeVersion="15.0" VstxVersion="4.0" ApplicationType="Word" Language="cs" TemplatesPath="VSTOTemplates" DebugInfoExeName="#Software\Microsoft\Office\15.0\Word\InstallRoot\Path#WINWORD.EXE" DebugInfoCommandLine="/w" AddItemTemplatesGuid="{51063C3A-E220-4D12-8922-BDA915ACD783}" />
<Host Name="Word"... />
</FlavorProperties>
</VisualStudio>
</ProjectExtensions>
...
</Project>
Looks to me like the two things that changed are:
The registry path from 14.0 to 15.0 (which in VS 2010 was easy to work around -- you just created a matching 14.0 registry path that pointed to where you installed Word 2013 and it worked fine).
The host package's CLS ID. I don't know what they are for Excel, but you can probably look them up. -- I prefer not to change the CLS ID of the checked in project, such that developers developing & testing the project against Word 2010 can continue to do so, as well as those developing and testing against Word 2013.
Of additional note it looks like two references got updated from 14.0 to 15.0 as well -- this is a major no-no -- since we want to only build against/embed the 2010 Interop Types (these work fine in 2013, but we don't want to accidentally access some 2013 only property and then have it not work in 2010...)
The two references that got updated are "Microsoft.Office.Interop.Word" and "Office".
Edit:
Looks like I can set those two references to SpecificVersion: False, and then hand edit the XML file to step them back down to "14.0.0.0" (version seems to be grayed out from the regular menu).
