Develop Office Client Applications using Visual Studio
There’s recently been some confusing information circulating about the future of VBA in the press that we want to clear up. The report that the next generation of Office will not contain VBA is untrue – the next generation of the Microsoft Office system will definitely contain all of the functionality that developers and power users expect from VBA.
What is correct is that we will no longer license Visual Basic for Applications to new partners, as previously announced on MSDN. Microsoft has traditionally had two main avenues for VBA. The first, and the one the vast majority of users take advantage of, is that VBA was included as a part of the Microsoft Office system and used for recording macros and automating applications like Microsoft Excel and Microsoft Word. Beyond that, Microsoft had a licensing program which enabled third-party ISVs to license VBA to include in their applications. Over the years, a number of partners such as Corel and AutoDesk, have licensed VBA to add application automation functionality to their products. Any existing partner can continue to ship VBA and Microsoft Office will continue to include it.
As noted previously on this blog, one of the most exciting aspects of the release of Visual Studio 2008 is that the functionality for developing applications for Office has now been incorporated into Visual Studio 2008 Professional Edition. This means that all of the functionality previously in Visual Studio Tools for Office and a large number of enhancements are now available to developers for building enterprise-grade applications on Office. Download a trial version at http://msdn.microsoft.com/vstudio and check it out for yourself!
We’re happy to report that the story has been updated and includes a correction at the bottom of the article.
PingBack from http://msdnrss.thecoderblogs.com/2008/01/17/the-reports-of-vbas-demise-have-been-greatly-exaggerated/
There is an interesting post over at blogs.msdn.com
Since I'm a VSTO developer who writes software for an industry that uses both Macs and Windows, and this is the VSTO blog, this question seems apropos: Why no VSTO for Mac? Obviously because of no .Net Framework for Mac…so, why no .Net Framework for Mac?
If giant apps like Wine and Mono can make large chunks of win32 and WinForms run on Intel Macs, there's no reason MS can't figure it out. Considering that the "Rotor" shared-source CLI runs on BSD, and that Silverlight 1.1 has the full DLR for Intel Mac, why no full framework port? There's no downside for developers or users...maybe it's because MS can't see an upside for its shareholders? I would LOVE to be able to sell my VSTO add-ins and document customizations to Mac users--and I'd love to stop having to explain why my 'Microsoft Office' programs don't work on 'Microsoft Office' on the Mac. This is a no-brainer for us insiders, but end users don't really care about frameworks and portability politics--esp. Mac users who are used to hearing "it just works".
I know the Mac platform is the bane of Microsoft's existence when it comes to major app ports, but maybe if you guys would pull together and make a nice portable Winforms and WPF implementation, you can start sharing a lot more core code between major apps ported to different operating systems, and it won't be as painful to suffer through Apple's periodic API/ABI housecleaning cycles...heaven forbid you actually start compiling stuff like Office, IE, and Media Player on top of the CLR so you could leverage some of that tasty VM portability.
There is a .NET framework for Mac, Silverlight 1.1 (2.0) uses it. And there's a PowerPC JIT, XNA on the Xbox 360 uses it.
@Rosyna: You have no idea how different these components are from one another. Although Silverlight 1.1 is a full *CLR*, it has an extremely scaled-down framework 3.5 implementation. Case in point, Silverlight 1.1 for Windows is 4.5mb (9mb for Mac), and requires NO local .Net Framework. The full 3.5 framework is >100mb, so you can imagine they had to cut back considerably to get to 4.5mb for Silverlight. The XNA miniCLR is different still (different BCL parts, different CLR bits).
Mono represents an effort to make a portable, compatible CLR that also has the entire framework implemented. I'm saying, if a small, resource-constrained open source project can cobble together 95% of the .NET framework for any OS, this pretty much proves any resistance on MS's part is just platform protectionism and foot-dragging. MS is supporting no fewer than four separate versions of the CLR right now (win32/64, XNA miniCLR, compact framework, and now the Silverlight DLR/CLR), including several different CPUs and OSes. Everything that isn't x86 Windows is pretty much a tiny niche. Can the Mac really represent a smaller potential user/dev pool than the XBox, for example?
I'm only after VSTO for Mac, but that will only happen if Microsoft wants it to. MS would have to deliver a full .net framework for Mac and harmonize the object models between Mac and Windows Office. Now that the MacBU doesn't have to support the monstrosity that is the PPC VBA system (described here: http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/ ), maybe they can spare some people to start working on something like this instead of just making the GUI cuter.
From several discussions I recently had with Enterprise Architects from various big enterprises over
as we know that this is not possible to execute an Add-in developed using VSTO and dotnet on MAC machine, do we execute it using other dotnet framework other than MS(if exist) which is compatible with MAC machines.
Also is there any other way for VSTO as well?
As with everyone outside our corporate IT dept, I have been assigned a "managed" PC. I am not able to load Studio. I used to develop many VBA modules that were used throughout the company. Our IT dept does not have the same understanding of non-IT needs and does not develop the same user-focused productivity tools. I think this is a big loss for Microsoft and opens the door for other vendors. My preference would be to have a Studio tool that is a basic component of all versions of Office (home as well as business because many develop on home PCs) and that does not involve any additional cost or installation.