I need to develop a plugin for excel. It should behave similar to Plugins for Eclipse. It should be available as a context sensitive menu, should have access to spreadsheet contents currently opened, the chart content etc.
I saw the the following link for developing Add-ins for Excel: http://msdn.microsoft.com/en-us/library/office/aa730920(v=office.12).aspx#office2007excelXLL_DevelopingXLLs ( using C & C++ and XLL SDK).
Is this the only option to develop plugins for Excel?
Lots of info on Microsoft's site about creating add-ins. Some suggested reading to point you in the right direction.
http://msdn.microsoft.com/en-us/library/ms268878.aspx
http://support.microsoft.com/kb/302901
http://msdn.microsoft.com/en-us/library/aa289518(v=vs.71).aspx
even some stuff on stackoverflow Creating add-in for Excel using C#
What will your add-in do? It might be easiest to do it in Excel's built-in VBA.
There are three distinct plug in (Add-in) technologies:-
VBA. Built in basic to Excel. Easiest, you can even record a macro from key strokes. Fastest. Trivial to deploy. Best. Considered obsolete by Microsoft. You need to write EndIf instead of } which is a deal killer for many.
.Net (C# or VB). Not as nice development environment. Needs Visual Studio + interfacing technology, VSTO (worst), ExcelDNA, or that Belerus system (probably best). Deployment difficult. Slower due to COM usage. Was a VBA replacement but no obsolete.
JavaScript. The latest and greatest. Very fashionable. Very difficult client/server environment to develop in. Very difficult to deploy. Very inefficient. Limited API.
As mentioned by others, there are three basic Office technologies other than XLL's, they are VSTO, VBA, and Office JS API.
My personal experience having worked with all three, is that VSTO is the most powerful, in either VB.NET or C#, as they are essentially the same language. The future road map for the two languages will show divergence, because C# will receive higher-end features while VB.NET will be targeted as the easy to us, but as this point, there is little difference between the two for programming Excel. VSTO will provide features expected, with built-in process for versioning, release, automatic updates, and rollback, and is capable of anything within .NET library.
VBA is the original programming language for Office and most samples are based on that. You can create fairly complex ribbons and context menus with it, but that said, it will be incapable of async/threaded operations, and is lightweight for service related work. That said, if you don't need such operations, VBA can work, but you should have some plan for managing versioning and code management, which is not natively part of the VBA sphere, and will be entirely managed by you.
The office API is like programming web pages with Office, defining and using JS for operations - newer one leverage React and Angular - with HTML and CSS for the panels. My recent experience converting Outlook VSTO add-ins was frustrating as many easy-to-implement features in VSTO/VBA are not available or are more complicated in JS. The experience and the interface though is quite nice, are much better looking than the typical WinForm, and it will be capable of working in web-based office clients, unlike VSTO.
The XLL link you provided is for a wrapper around C++. This is likely more complicated than any of the other types, and although there is power in going lower, you would need to have the experience and skills to make it worthwhile.
Synopsis:
