I have used Shared Add In(C#) to develop an Excel Add-In. In the initialization, I had no problem with loading excel-dna file .xll on Office 2010. However, there is problem with running on either Office 2013 or 2016, showing that "function is Invalid".
AddIn udfAddIn = applicationObject.AddIns.Add(progID, true);//the exception is "AddIns is Invalid"
udfAddIn.Installed = load;
Please help me. I would like to know how it (.xll file) works on Office 2013 and 2016 by shared add in. Thanks!
You are mixing two different technologies when you make a Shared add-in (a COM add-in) with Excel-DNA. I'm surprised it worked with Excel 2010.
The best approach is to make a new Class Library project (targeting .Net Framework) and then install the ExcelDna.AddIn package from NuGet. Then follow the instructions in the readme file that pops up. You should have a starter add-in that works in both Excel versions.
The best place for Excel-DNA support is the Google group at https://groups.google.com/forum/m/#!forum/exceldna
Related
I am developing my first Outlook Add-In in C#. In Visual Studio I have the options to develop an "Outlook 2010 Add-in" or "Outlook 2013 Add-in" or probably an "Outlook 2016 Add-in".
This Add-In should work on one PC which runs currently Outlook 2010 but which I could upgrade to a newer version.
If I start to develop an "Outlook 2010 Add-in" will this also work in Outlook 2013 and 2016? Do I have to do something to make it work with different versions of Outlook?
My Add-In will check some details of the mails and depending on the details it will sort these mails. I guess that should work in all versions.
Is there a clear advantage of an 2013 or 2016 Add-In compared to 2010?
As mentioned in comments by #penleychan, targeting the latest version is a good thought. I did the same when I develop my VSTO addin. Most of the time I have used the common features of the Outlook and developed the addin with template version similar to the installed office (on my machine). Its easy to debug.
If the addin is going use specific feature(s) of a version of Office, then we should use that version template.
You may like to refer this link.
You can run your Office 2010 based solution in later Office versions. You just need to choose the right target .net version. Read more about that in the Running Solutions in Different Versions of Microsoft Office article.
Is there a clear advantage of an 2013 or 2016 Add-In compared to 2010?
The only benefit you get in that case - the PIAs version corresponding to the target Office version. That means you will get access to objects, methods, properties and events available in later Office versions. Anyway, at runtime you still can use the late-binding technology which allows accessing missed members at design-time. See Type.InvokeMember for more information.
Is there any way to create add-in for Outlook 2007/2003 in Visual Studio 2012 (C#)?
So far I found that it should be possible and I just need to remove references from build-in 2010 add-in. Also tried to download some packages for older VS without success. After many attempts, during adding .dll file to Outlook 2007, I am still receiving error, that it is not add-in for Outlook 2007.
After all, I doubt a lot that I can do some add-in for old Outlook 2003 if I am not able to do it for 2007. It would enough for this time to force 2007 add some add-in with only MessageBox on startup.
You can try to use this library NetOffice. I'm using it and is very good.
Even if it does not fits your needs you can dig a little in the code and try to understand how they do it. They have nice examples.
BTW, If you are using VS express edition you cannot develop Office add-ins without a library like NetOffice.
I am currently working on an Excel 2010 add-in which formerly was an Excel 2007 add-in.
Somewhere in the process of switching computers, the add-in was converted i think.
Some of my customers stated that the add-in wasn't working on Excel 2007 anymore so I tried to debug it in a VirtualBox with Excel 2007 and Visual Studio 2010 installed.
Now I get the Error Message:
You cannot debug or run this project, because the required version of the Microsft Office application is not installed.
I started a new Excel 2007 add-in project and tried to find what the differences are and came up with the idea that it somewhat has to do with the dll's so I changed my 2010 addin until it looked like an 2007 addin.
I still get the error message stating that my project can't be debugged.
Is there anything I could've forgotten to change.
Writing a completely new addin is unfortunately not an option.
These questions haven't helped me so far:
Excel Addin that works on Excel 2007 and 2010
Deploying Office 2010 addin
To get VS 2010 working with Office 2007 modify the project file (.csproj) so that it will open in Office 2007 and not look for Office 2010 when run (hence the error message above).
Here is the project settings change (Excel example):
Source XPath:
//Project/ProjectExtensions/VisualStudio/FlavorProperties/ProjectProperties/#DebugInfoExeName
Old Value (Office 2010):
DebugInfoExeName="#Software\Microsoft\Office\14.0\Excel\InstallRoot\Path#excel.exe"
New Value (Office 2007):
DebugInfoExeName="#Software\Microsoft\Office\12.0\Excel\InstallRoot
\Path#excel.exe"
After changing this project setting, when you fire up the debugger (F5) it will load the Excel 2007 application instead of looking for Excel 2010.
Typically, when I am developing against multiple versions of Office with VSTO Add-ins, I have a project for each version of Office I am targeting. I put all common code between the projects into a single project (typically the oldest project) and use linked files, I add the common files to the newer projects. This allows me to write one set of common core code, abstracted from the requirements of each version of Office. This means I am no longer fighting the different ways VSTO is compiled for each version of Office. This can be made easier with shared folders and virtual machines, so I can develop and test without multiple computers. It is by no means graceful, but it works well for me. This should allow you to develop your VSTO Add-in against both Office 2007 and Office 2010 without much issue.
I want to create an add-in (a ribbon precisely) for MS Excel by using Visual Studio C# 2010 Express. I have searched and read about it here and here and somewhere else. However, when I want to create a new project I don't see any template as described, I don't see even the Office tab. Is it because I am using the Express edition? I think it shouldn't be. Because in this official comparison they say all editions are capable of office development.
What can I do to develop this add-in?
According to this post on the MSDN forum, Visual Studio Tools for Office are not available in the Express edition. I'm not sure where you're reading that on the comparison page (a quick glance said nothing about the Express edition).
A good alternative to VSTO for making an Excel add-in with .NET is Excel-DNA (which I develop). It is a free library that integrates your .NET assembly with Excel using the C API (as an .xll add-in). You can create user-defined worksheet functions (UDFs) for Excel (which are not supported by VSTO), and make ribbons, RTD servers. And you get easy deployment (a single .xll file) without needing any registration or admin rights, even for ribbons and RTD servers.
Another option, if you just want to integrate through the COM interface and not make UDFs or use the specialized Excel features, is NetOffice. The project give you a version-independent set of interop assemblies for Office and Visio, and allows you to easily make add-ins targeting different versions of Office. NetOffice can also be used as your COM interop library in an Excel-DNA add-in.
Both of these directions will work fine under the Express editions of Visual Studio, as well as in the free SharpDevelop IDE.
Let's say I am using SharpDevelop/VS to develop an app that uses PowerPoint.
Do I need to recompile the app so there is a build for each version of MS Office?
I have MS Office 2007, but I would also like the app to work with Office 2003 and later, without having to recompile the app for each version.
Do I just need to install the appropriate Office Interop redistributable package/msi on the client machine, and ship my app as is?
Thanks in advance for your help.
If you're using the Microsoft.Office.Interop libraries you just need the 2007 version, it will be backwards compatible with older docs
I have found that you should build against the oldest MS Office you have. We still use MS Office 2000.
The the thought behind this:
Everything MS Office 2000 can do any later version of MS Office can do.
A lot of things MS Office 2007 can do is impossible to do in earlier versions
of MS Office.
I absolutely agree with Nifle. Use the OLDEST ones you can find. If you use 2007, there is a very good chance it will not work with older versions.
Since I did not want to install the oldest Office version on my development PC, I used Virtual PC to create a "final build" environment. I develop with my regular PC then move the source files over to the Virtual PC with Office 2003 and VS installed, and create the final customer build there.
You will need to edit the CSPROJ file to reference the older Office libraries with this method. You can do that by just opening VS on the build virtual PC, removing the references to Office and adding them again.
Just to confirm this with anybody that is trying this. I have a .NET 4 project that references the 15.0 PowerPoint Interop library and the Office 15.0 library (Office 2013). I setup the project to "Embed the Interop Types".
I setup a virtual machine with Office 2007 Ultimate on and ran the application (without copying any additional DLLs). It correctly interacted with PowerPoint to extract the data my application was looking for.
The Interop libraries are backwards compatible from my experience.