Is there a simple "hello world" sample for coding an Office 365 Excel add-in that I can follow and customize?
I am assuming that you would like to build an Excel add-in that can be run in Windows/Mac and Online. So you could use Yeoman generator to build "hello world" sample code easily. The Yeoman generator creates a Node.js project that can be managed with Visual Studio Code or any other editor, whereas Visual Studio creates a Visual Studio solution. Select the tab for the one you'd like to use and then follow the instructions to create your add-in and test it locally.
This article will walk you through the process of building an Excel Taskpane Add-in in Yeoman generator.
You could also explore API capability using Script Lab.
Script Lab is a useful tool for anyone who wants to learn how to develop Office Add-ins using the Office JavaScript API in Excel, Word, or PowerPoint. It provides IntelliSense so you can see what's available and is built on the Monaco framework, the same framework used by Visual Studio Code. Through Script Lab, you can access a library of samples to quickly try out features or you can use a sample as the starting point for your own code. You can even use Script Lab to try preview APIs.
Well it depends on what you mean by an Excel add-in I guess. There are a lot of options here.
If you're talking about a simple add-in written in VBA, which doesn't require any additional tools to get started, there are lots of tutorials available online.
You could take a look at this simple getting started tutorial:
How to Create and Use an Excel Add-in
If you want to know more about there is to developing office (excel) add-ins i'd encourage you to take a look at the developer docs from microsoft:
https://learn.microsoft.com/en-us/office/dev/add-ins/
https://learn.microsoft.com/en-us/office/dev/add-ins/excel/
The nice thing about this approach is that it's designed to be cross-platform and enables you to create add-ins by using web dev technology. If you're more interested in using visual studio and VB.NET / C# I'd start by exploring the VSTO Add-ins route. Start at the docs or use google for getting started tutorials yourself. The VSTO docs can be found here:
https://learn.microsoft.com/en-us/visualstudio/vsto/excel-solutions?view=vs-2019
Or jump right in and start here: https://learn.microsoft.com/en-us/visualstudio/vsto/walkthrough-creating-your-first-vsto-add-in-for-excel?view=vs-2019
There are three common ways to create an Excel 365 JavaScript Add-in:
(1) You could use the Yeoman Generator (with Visual Studio Code)
(2) You could use the Office Templates (with Visual Studio 2019)
(3) You could use NPM and Webpack (with Notepad)
You can find simple "Hello World" examples of all three here:
https://bettersolutions.com/javascript/excel-api/index.htm
Related
Recently Microsoft introduced the Office Add-ins architecture which allows for developing add-ins hosted remotely and run within IFrames inside office. I have read a lot trying to understand whether this architecture is meant as a replacement for VSTO or do they have separate use-cases. VS 2015 has templates for both.
In my specific case, I want to develop an add-in that extends Excel 2016 with custom import functionality (e.g. custom CSVs, TSV, or even XLSX). I can't tell which type of project I should go with.
Given the amount of legacy applications developed as COM and VSTO add-ins I find it hard to believe Microsoft would drop support within the next 10 years.
For me the most important differentiators of one approach vs. the other are:
COM/VSTO Office add-ins
Access to complete object model
Local machine interaction, e.g. file system
Available on Windows since Office 2007
JavaScript Office Add-ins
Portable between Windows, OS X, iOS etc. (not complete everywhere yet though)
Easy integration with online services
Easy distribution, no need to worry about installers
In your case I'd ask myself these questions:
Will there be a need to support other platforms besides Windows in the future? > JavaScript API
Are the requirements covered by the current JavaScript API implementation?
I've found that VSTO isn't 100% implemented either. I've given up developing VSTO for Project, got hit by too many issues. Instead I've developed everything in VBA and have perfected some neat ways to install, distribute and update VBA macros.
I have an existing application developed using Microsoft Visual Studio 2010 C#. I just purchased Xamarin's Monotouch product which allows me to use their IDE MonoDev to create iPhone/iPad applications from scratch by coding C#. Right now I don't want to code a new application. I want take my existing C# application import the source into monodev/monotouch and have the result run on the iPhone/iPad. My existing C# application is designed for deployment on Android phones/tablets using Xamarin's Android product. It works great! I have begun wading into the Xamarin documentation, samples, tutorials etc. But I need to port the existing application to iPhone/iPad right now, right away. I really don't have the luxery to spend time learning from scratch. I've got to belive someone has already gone down this migration path. If you have can we talk, email, or do you know if there is a guide describing the specific steps to take to accomplish this?
TIA
Xamarin MonoTouch does not allow you to run any C# application and run it immediately on an iPhone. The UI layer is native, so the C# code that constructs the UI must use the Xamarin bindings onto the Apple UI APIs.
The 'standard' migration process is to create an empty MonoDevelop project then start adding your existing C# business logic files, resolving any compilation issues as they arise.
I plan on developing Excel Add-ins and I have looked around on ways of getting it accomplished. What I have found from expert views on various forums whom suggest using third party XLL development environments (XLW, ExcelDNA and host of others) instead of Excel SDK development 2007 with C++ as the latter option requires steep learning curve and for novices such as me would require managing low level details such as memory management
So my question is whether the XLL produced or developed using the 3rd party tools (XLW, ExcelDNA) would run on users Windows system that do not have .net runtime support. There are only 1 or 2 sample tutorials on the web about development of XLL with Excel 2007 SDK using Visual Studio.net and users comments on those tutorials suggest that an XLL developed in Visual Studio.net using Excel 2007 SDK are not runnable on Windows that do not have .net runtime
If you develop your add-in with C# or VB.NET (either with Excel-DNA or XLW), it will require the .NET runtime to be present on the client machines. If you develop the add-in with C++ (with XLW or another C+-based toolkit like XLL+) your add-in will not require the .NET runtime.
By default XLW uses the dynamically linked C runtime so you need to be sure the target machine has the appropriate version. http://xll.codeplex.com uses static linking so you can be sure your xll will run on any Windows machine.
I saw a demo of Code Contracts the other day and decided to give it a shot in a little test project.
I can setup my Code Contracts code appropriately after adding a 'using System.Diagnostics.Contracts' statement to the classes, but the contracts don't seem to be enforced.
Is there a reason why I don't see the 'Code Contracts' tab appearing on the project properties screen?
You need to install the Dev Labs toolkit in order to get the Visual Studio Integration to show up.
Code Contracts are part of .Net 4, but the tooling isn't part of VS 2010 by default.
It can be downloaded from here : http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx
The VSTO bit I understand. Visual Studio has the project templates to get you started with creating nice .NET based add-ins.
But where is VSTA? I installed the SDK but it seems to be gears towards adding extensibility to your own applications.
I had thought that VSTA was like the new VBA for Office 2007. Infopath 2007 seems to be VSTA enabled but I cannot seem to find where Excel 2007 is also VSTA enabled.
Am I missing something ?
As I understand it, VSTA is not a 'new VBA' nor built into Office 2007, but a separate 'Super-VBA with .NET' that must be licensed from Summit, and distributed as part of an external application. I think it's just targeted at ISVs wishing to extend Office, but the blurb about it also contains this gem:
Perhaps the feature most applauded by enterprise BDMs and SI’s is that VSTA customizations are seamlessly opened by any version of Visual Studio enabling professional developers to continue to enhance applications originally created by end user developers – a feature requested by many enterprises because applications often grow in sophistication over time.
I've not bothered googling BDMs and SI means le Système International d'Unités to me, but I took this mean that you can take the horrible mess of excel VBA that your traders used to turn worthless morgages into goldmine CDOs (and then bailouts), and your 'real developers' can open it in Visual Studio and sort the mess out (or just quit...).
also VBA and VSTA can exist together:
http://blogs.msdn.com/vsta/archive/2006/07/31/684514.aspx
If I understand correctly, VSTA is a new technology that provides a "standard" short-cut route to extensibility for application vendors. So it may appear in Office apps in the future or it may not, but it's not there now.
If it becomes supported by Excel, Word and the like, then the UI (Visual Studio Shell?) should be distributed as part of the package.
But I may be miles off-base...
VSTO 2005 is available to install by itself as a complete development environment
Read more here...
http://msdn.microsoft.com/en-us/library/54ds2za4(v=vs.80).aspx