I'm a bit confused about what I can use to develop for: It's a soup of letters: VBA, VSTO, Interop, etc... I'm in need in develop a MS Project 2013 control. So, what can I use to develop it? I prefer develop in C#, but if it isn't possible, I can develop VBA anyways...
Maybe I can help a little bit with the soup of letters. VBA is the oldest technology in your list. It is primarily used for scripting (automating) things in MS Project based on old visual basic operations on the MS Project object model. It typically works inside a specific MS Project file. VSTO is the modern version of VBA that Microsoft introduced to take advantage of .NET. It is still file-centric, but now you can use a modern object-oriented language like C# or VB.NET to write your control. A third approach is to write a separate .NET application that can work with any MS Project file. An example of this is the COM-Addin approach. A COM Addin is C# or VB.NET application that you compile and package separately. Then you register the Add In on the machine so that MS Project knows about it and calls it when needed.
Both VSTO and COM Addins are written in .NET, whereas MS Project only speaks COM. Thus both rely on the Microsoft COM-Interop libraries when they talk to MS Project. These libraries are called 'Primary Interop Assemblies' and they enable the translation between COM calls and .NET calls.
There's a comprehensive book on all of this by Andrew Whitechapel called Microsoft® .NET Development for Microsoft Office. It's no longer sold directly on Amazon, but you can still find it through other sellers. I've left out a few other related techniques that you can find in Andrew's book. Another expert is Rod Gill. He's written a book called VBA Programming for MS Project '98 through 2010 with an Introduction to VSTO. It's more VBA-centric than Andrew's book, but you may find it helpful. I'd recommend that you Google Andrew and Rod and also Misha Schneerson, formerly at Microsoft. Both Andrew and Misha have moved on to other technologies now, but you'll find that they give you good cookbooks for doing this sort of thing.
Hope this helps.
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 need to call some .NET code from Excel 2007, and I'm searching for the best way.
The official "Microsoft-sanctioned" method seems to involve Visual Studio 2008 Professional, but I don't have that. I have VS2005, but that plus VSTO 2005 SE can only do application-level add-ins, not document-level macros.
The problem involves some analysis code that comes as .NET assemblies; I'd like to manipulate it by changing some cells in an Excel worksheet.
Any other ideas?
You could expose your .net objects as COM objects, then call them from VBA...
The last post in this link has some code:
http://bytes.com/groups/ms-access/205532-calling-c-net-dll-vba
You could use Excel-DNA - an independent open-source project to integrate .NET into Excel. It allows creation of Excel add-ins, including high-performance user-defined functions, using managed code. It needs only .NET 2.0 or higher, so your VS 2005 will be fine.
(Disclaimer: I'm the developer of Excel-DNA.)
You can (easily) call any COM components from VBA; you can also (less easily) call other DLLs etc. - even system DLLs.
If you create a COM wrapper for your .NET DLLs you'd be able to call those from VBA. You can do that with VS2005, but the amount of work involved will depend on the complexity of the DLLs' API.
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
I am new to developing for Office Forms Server / MOSS 2007. I have to choose between designing my web-based forms and writing code for them in Visual Studio Tools for Applications (aka VSTA) or Visual Studio Tools for Office (aka VSTO). VSTA is included free as part of the license for InfoPath 2007; VSTO, also free, requires Visual Studio 2005 / 2008. I have licenses for both of the products and cannot easily decide what the pros and cons of each IDE might be.
This explains it better than I can: http://blogs.msdn.com/andreww/archive/2006/02/21/536179.aspx
Given the fact that the license for VSTA comes with InfoPath, I'd probably run with that.
To add to Bennor's answer I would avoid writing code "behind" InfoPath forms entirely. This is a desperate attempt to make 'dumb XML' as much as possible instead of "smart" XML that is entangled with code. Failing this, my next choice is VSTA because historically these solutions (at least the ones I have written) have a lower security risk and can run on more diverse Office environments.
The last resort is to use VSTO. This is my bias... most of my VSTO investments are in Microsoft Word.
Is VBA going to go away any time soon, like VB6 has? Should I not develop new Office applications with VBA? Or should I be developing all new Office Apps with VSTO?
Update: Recently read this article.
Office VSTO offers a great deal of additional functionality over Office VBA, and while I don't believe Microsoft has signaled that it's going to terminate VBA (in fact, they've said explicitly that it will be around at least until Office 14; Office 2007 = Office 12), I think it's well worth the effort to move your applications to VSTO to take advantage of the additional flexibility and power.
I actually don't think that deprecating VBA would be feasible, since a fair amount of Office programming takes place at the macro level by business users and I don't think that's going to go away any time soon. Those folks don't generally have access to a VSTO-capable IDE.
VSTO has new features, but also has a number of major deficiencies compared with VBA.
For one thing, Code Access Security can make it difficult to deploy VSTO applications (that's being polite).
For another, the VSTO development environment is nowhere near as accessible to "Power User" developers as VBA. For example, no macro recorder to get you started.
And a big showstopper is that .NET interop with out-of-process COM objects doesn't work well. For example, if you want to manipulate other Office applications (Word, PowerPoint, Outlook) from within an Excel VSTO application, you will find multiple copies of these applications running in the background, for the reasons described in this KB article.
All this coupled with the huge investment in existing VBA apps means VBA won't be going away any time soon.
Microsoft has stated that VBA will be supported moving forward for the forseeable future, but they are also recommending that new apps use VSTO.
The latest Mac version of MS Office don't support VBA, and 64-bit Windows runs it in a virtual 32-bit out-of-process mode. So if you are planning a new application using Office as a platform, VSTO is definitely the way to go, but you shouldn't worry too much about legacy support.
As #cori points out, it would be a big marketing no-no for MS to just yank support and break so much existing software.
Microsoft have been dropping hints at a managed-code version of Office with an integrated VSTO (presumably in the same way as the VB6 IDE is integrated for VBA, so the VS IDE would be integrated for VSTO) ever since .NET was first released.
Given just how much coding is involved - and given that this would not produce any features that would be visible to users - I very much doubt that this is high on the Microsoft priority list. I can imagine that they layer a managed code set of objects over the top of the existing codebase (much as Joel Spolsky layered a set of COM objects over the existing C codebase when putting VBA into Excel in the first place) and bung a new IDE in as the default, while hiding the old one. Even that would be a major exercise (imagine writing the macro recorder!). Of course, this would make .NET a pre-req for Office, which the Office team will only accept at gunpoint.
They will never actually remove VBA from the products, of course - Excel still supports Excel 4 macros, and Word still has the WordBasic Automation object to support Word 6 macros, and there's no sign of either of those being removed, since there is too much legacy code to support - and no-one has used either of those coding models in a decade.
If Microsoft do ever put a .NET environment into Office (which, frankly, I doubt will ever happen), then they might stop adding VBA support for new Office features. That's the closest they'll get to discontinuing VBA.
Here is a comment from Microsoft regarding future VBA support. In a nutshell, it is not going away on Windows versions of Office (but is discontinued for Mac versions).
VBA is a long way from being depreciated, in fact VBA is to be reintroduced into the next version of Office on the MAC ( http://www.microsoft.com/presspass/press/2008/may08/05-13MacBU2008PR.mspx).
For most people on the ground, VBA and C XLLs (and VB6!!) continue to be the tools of choice. The current .NET linkages are slow and offer zero productivity gain. 3rd part tools such as ExcelDNA ease the pain somewhat but obviously the unmanaged C based (and assembler based) code base of Office doesn't sit easily with .NET.
VBA add-ins are a bit troublesome to deploy, but VSTO is even more so. Also, VSTO involves a bit of overhead, as it needs to start up the CLR before running your code.
But most important of all; VSTO takes away the pain of writing VBA.