How do I add the component for EXcel 2010 to a windows application when the user only has Excel 2007 installed?

The approach that I have taken in the past with this issue, is to create different assemblies that have the correct references for the interop libraries.  This is not something that I have done for quite a while, so I can't give you detailed information.  I can, though, give you a nudge in the right direction.

The message I am getting is Unable to install or run application.  The application requires that assembly Microsoft.vbe.Interop Version 14.0 be installed in the Global Assembly cache first.  I had added Microsoft.vbe.Interop version 12 to the application which I didn't need before, but I am still getting the same message.  

I had tried moving the application to a machine that does have Excel 2007 and VS installed.  I deleted the references to Microsoft.Office.Interop.Excel and tried to add the two resources that old versions had.  Microsoft.Office.Interop.Excel and Microsoft.Office.Core.  I could not find Microsoft.Office.Core.  Is it contained in any other component?  
Any assistance is greatly appreciated.

When I moved the application to the machine with Excel2007 and added the Micorsoft.vbe.Interop version 12, I was getting an error stating that the Interop was referenced twice.  When I expand the references, I do not see it there twice, but I did see VBIDE.  Could this be where I am getting a duplicate reference and if that is the case, can I delete the VBIDE and put Microsoft.vbe.Interop in it's place?

1.  Thanks I will take out the VBide reference and add the Microsoft.vbe.Interop version.
2.  I do not have both versions installed on my development machine.  I know that Excel can't have two different versions on the same machine.
3.  I have created mutiple projects for each version, but I am unclear what needs to be in the 2007 Excel version.  
4.  I have the publish output for the project pointing  to different folders, but not the build output.  Since each project is in its own folder, won't the build output be seperate?

1) You don't need the Microsoft.vbe.Interop either.

2) It gets a little tricky if you don't have multiple versions installed on the same machine.  The trick is to get the assemblies to load according to the version requirements.

3) Are you using source control, such as Team Foundation Server or Visual Source Safe?

4) If you have source control, do you have the option of multiple development machines connecting to the source code repository?

An alternative is to use late binding via the Dynamic data  type. then you don't need any reference to interop.

Type type = System.Type.GetTypeFromProgID("Excel.Application");
dynamic xlApp = Activator.CreateInstance(type);

You won't get any intellisense sand there's no comppile-time checking, but it removes the version depedency.

You can get intellisense during development by using Interop, then convert the definitions to dynamic.

Late-binding is a process fraught with danger.  If you go down that road, I would suggest creating a very stringent unit test framework.

There is no perfect approach--each has it's own problems.  I prefer the compile-time checking that you get from early-binding.

I had to go between two machines, but I grabbed an old version that used Excel 2007, moved all of the forms , etc to the old version from the new version, had to add System.DirectoryServices and then moved it back to the machine that had Excel 2007 on it.  I complied and published an application and it worked.  Thanks

I thought I may have to do this, but your comments reinforced the concept.  I appreciate it.