Bill R.

Hello,

My shop is upgrading to VS 2005 Pro (rather than EE) and it won't have VSTO. Am wondering what I'm really going to be missing. Also considering making a push to have the biz purchase the tools but again not sure it is really necessary (ROCE is after all a concern).

I understand some of the things I get from VSTO are:

Design-time support of custom Ribbon tabs, Office menu, Quick Access Toolbar, command bars and commandbar controls, menu items, context menu items.

Adding Outlook options page and folder property pages at design-time.

Trapping any built-in controls on Outlook toolbars and handling them in your own way instead of the standard one.

Version-independent event processing for Outlook Application, Item, Items and Folders.

Context-sensitive binding of your toolbars or their separate controls to Outlook folders or item classes.

Determining keyboard shortcut processing settings at design-time.

Adding Action Panes in Excel and Word 2003 and custom Task Panes in Office 2007 at design time.

And some of the things I wont have to do are:

You needn't bother about numerous differences between Office applications when writing your code in VSTO.

You needn't write code to create and show Ribbon tabs (controls), Office menu, Quick Access Toolbar, traditional Office toolbars, toolbar controls, menu and menu items, context menu items depending on the current Outlook folder, its name or type, or the current Outlook Inspector type.

You don't have to write code to trace Outlook context (active Explorer and Inspector are just Add-in Express properties).

You don't write code to add Outlook Options page and folder Property page.

From the above looks like the real benefit comes along when using OUTLOOK and working with the Office GUI. I'm going to be working with Excel 2003 exclusively on an upcoming project and am more interested in the interoperability rather than the 'fluff... Also, seems that I can still get the benefits offered by VSTO but that I'd instead have to write them myself and that IS ok.

Therefore, the benefit offered by VSTO seems small.... Yes

At a deeper level, recalling the DOTNET wrapper atop the COM object, is this still the case Meaning, in the world of VS2005 are we still just building a wrapper atop old tech And if we are NOT when using VSTO, is it cumbersome to build

I suppose I'm really asking is regardless of VSTO or roughing it, what type of object is actually built.. Managed or not

Also, what about deployment I recall when building a DOTNET obj to be consumed by Excel (Office), one had to have a strong name and had to register the obj. Same rules apply in VS2005 with or with out VSTO

Thanks for your wisdomSmile



Re: Visual Studio Tools for Office VSTO: Whats the REAL benefit?

Bill R.

Hmmm, maybe I got myself confused there... The BOLD points I nabbed from the following:

Add-in Express 2007 for MicrosoftR VSTO

which I assumed were explicit benefits of VSTO.

Now I see that the tools Add-in Express 2007 offers functionality in addition to the benefits offered by VSTO.

So please disregards tthe bullets BUT PLEASE comment on the :

At a deeper level, recalling the DOTNET wrapper atop the COM object, is this still the case Meaning, in the world of VS2005 are we still just building a wrapper atop old tech And if we are NOT when using VSTO, is it cumbersome to build

I suppose I'm really asking is regardless of VSTO or roughing it, what type of object is actually built.. Managed or not

Also, what about deployment I recall when building a DOTNET obj to be consumed by Excel (Office), one had to have a strong name and had to register the obj. Same rules apply in VS2005 with or with out VSTO

Thanks!




Re: Visual Studio Tools for Office VSTO: Whats the REAL benefit?

Cindy Meister

Hi Bill

Firstly, a possible misunderstanding in your second posting: As far as I know, there is no version of "VSTO Express", only Visual Studio Express. And since the Express versions don't support Add-ins, VSTO can't possibly be used with an Express version.

Another confusing factor might well be the differences between VSTO 2005 and VSTO 2005 SE. The latter is a download, free of charge and can be installed with VS 2005 Pro. This is the only production version of VSTO currently available that has any support for Office 2007. It helps you with creating application level COM Add-ins and using it will avoid many of the problems associated with developing managed code Shared Add-ins (as opposed to writing an Add-in in, say, classic VB6) such as needing a Shim.

The full VSTO 2005, which is a product you have to buy (but can also be installed together with VS 2005 Pro) mainly provides you with document-level customizations. You can, for example, place WinForms controls on Word documents and Excel worksheets, create Actions Panes, and take advantage of data caching within the document.

With those basic clarifications out of the way, to get to your specific questions:

<<At a deeper level, recalling the DOTNET wrapper atop the COM object, is this still the case Meaning, in the world of VS2005 are we still just building a wrapper atop old tech And if we are NOT when using VSTO, is it cumbersome to build >>

Yes, this is still the case. Office (and Windows) remain COM.

<<I suppose I'm really asking is regardless of VSTO or roughing it, what type of object is actually built.. Managed or not >>

A hybrid, actually. The DLLs are managed code with a COM-exposed interface. The VSTO loader and the PIAs take care of the interface.

<<Also, what about deployment I recall when building a DOTNET obj to be consumed by Excel (Office), one had to have a strong name and had to register the obj. Same rules apply in VS2005 with or with out VSTO >>

Deployment is a definite pain-point. If you search that term in this forum you'll turn up quite a few discussions :-) There is extensive documentation, and it still presents problems, especially with SE Add-ins, although the VSTO installer takes care of some of the registration issues. But basically, it's managed code and still follows the security rules of the version of the .NET Framework for which it was developed. (Meaning it requires evidence that can be any combination of location, strong name and code signing.)

Hope this answers some of your questions :-)






Re: Visual Studio Tools for Office VSTO: Whats the REAL benefit?

Bill R.

Thanks for your reply!

The "Express" package I mistakenly referred to in my first post was actually a 3rd party tool, which I realized and tried to address in my 2nd post.

I believe that you have confirmed building DLL's for Office, even when using VS2005 against Office 2003, are still Managed objects with a COM wrapper (just like it was in VS2002). These same rules apply:

1) Within VS Project properties, checkbox the REGISTER FOR COM INTEROP option

2) Apply a STRONG NAME to the DLL

3) Register the DLL using Regsvr32 (for 32-bit Win OS's)

4) Add the reference to your MS project from the VBE (the MS Office Application Visual Basic Editor)

Just like you point out, deployment is still an issue since you need ADMIN rights (or thereabouts) to register the app on a users machine - certainly more access than a typical enterprise level employee has at their disposal.

This in mind AND your assessment regards what VSTO does, it seems the product is overkill.

Also, VSTO 2005 can be purchased as an add-on for VS2005 but for the life of me, can't seem to find a link ONLY for that product.

Finally, it appears consumers of apps built with VSTO 2005 need to install components to make it work with their Office install.

Thanks again for your 1st reply and am looking forward to your 2ndSmile





Re: Visual Studio Tools for Office VSTO: Whats the REAL benefit?

Cindy Meister

Bill R. wrote:

I believe that you have confirmed building DLL's for Office, even when using VS2005 against Office 2003, are still Managed objects with a COM wrapper (just like it was in VS2002). These same rules apply:

1) Within VS Project properties, checkbox the REGISTER FOR COM INTEROP option

2) Apply a STRONG NAME to the DLL

3) Register the DLL using Regsvr32 (for 32-bit Win OS's)

4) Add the reference to your MS project from the VBE (the MS Office Application Visual Basic Editor)

Yes... But you wouldn't use VSTO to create this kind of DLL.

Just like you point out, deployment is still an issue since you need ADMIN rights (or thereabouts) to register the app on a users machine - certainly more access than a typical enterprise level employee has at their disposal.

This in mind AND your assessment regards what VSTO does, it seems the product is overkill.

Depends on what you need :-)

Also, VSTO 2005 can be purchased as an add-on for VS2005 but for the life of me, can't seem to find a link ONLY for that product.

I don't know what kind of link you're referring to, but here's one that compares VSTO with the other Visual Studio packages.

Finally, it appears consumers of apps built with VSTO 2005 need to install components to make it work with their Office install.

Mmm. Ideally your setup project would take care of most of this. Assuming, of course, that the user (or admin, more likely) has already installed the .NET Framework and therefore the PIAs. Your setup would check for these things. And it would need to install the vsto loader besides your project. All that is discussed in the extensive deployment documentation.






Re: Visual Studio Tools for Office VSTO: Whats the REAL benefit?

Bill R.

Thanks again!

What's difference between 'my' DLL and the one that VSTO creates

Ahh yes... Depends on what I need... What I believe that I DO NOT need is embedded DOTNET forms within my Office documents. But, it probably make more sense to take as much code out of VBA and through it instead into VB/C# so perhaps I do need it. This is still confusing !!!!!!

Where's that link I've previoulsy seen the compasion page between the flavors of VS but am explicitly looking for a link to purchase VSTO for VS2005 (to work with Office 2003) and I do not belive that shows up in the comparison sheet.

Here's the link I'm referring to regards the components to run VSTO solutions on a clients machine:

Microsoft Visual Studio 2005 Tools for Office Second Edition Runtime (VSTO 2005 SE) (x86) . This seems download seems to be a requirement.

Here's where I'm going.... We have an Excel file which shells out to a DOTNET app and the app does a number of things from calling web services to pushing data to backend databases and then to finally updating the calling Excel file. Experience has taught that this approach is full of issues the biggest being that VBA doesn't wait for the app to finish BEFORE continuing. I've tried various fixes including the venerable SHELLWAIT function but still nothing seems to work.

Combine that with 'other' non-desirable behaviors and and there we end up with a mix of toxic goo just waiting to explode.

There may be a requirement coming along which requires us to even further add more bells to the app and I'm worried this will become a bigger mess than it already is.

So I want to integrate the pieces of the application as tightly as possible and am wondering is VSTO is the way to go and it seems beyond creating pretty GUI elements, VSTO doesn't offer much else.

I'm also concerned about distrobution since this app is and will be considered a 'one off' where it probably won't be considered an offically installable application but rather an ON DEMAND install requiring an admin - the SHELL option offers a BIG PLUS in this dept since there is nothing to install !





Re: Visual Studio Tools for Office VSTO: Whats the REAL benefit?

Adrian Leeming

Just a thought as you say excel does not wait until your application has finished, if you are calling it via VBA why not make the exe a com automation server and do a create object and call a method on that com interface as that would wait until it had finished.

You could check using windows installer interface if your exe had been installed or possibly shell the exe as you do now but with an argument that says do nothing so it forces it to do the advertised install or registers its com object whatever is needed, then loop until you can create the com object.

Maybe these musings will give you some ideas

Adrian.





Re: Visual Studio Tools for Office VSTO: Whats the REAL benefit?

Cindy Meister

Hi Bill

I'm afraid I can't offer you much more, given the very general "musings" on your side... I also have the impression you're still not differentiating between VSTO 2005 and the SE version. The SE version (for creating Add-ins) is a free download. I don't know of any links for purchasing any version of Visual Studio, but then I'm not North American based so couldn't buy anything from the MSFT site...

The difference between what VSTO creates and "your DLL" is that VSTO is tightly bound to the Office application (Excel, in your case) and uses the VSTO loader (which ameliorates various problems Office has co-ordinating with managed code). VSTO also requires full trust on the client machine. A VSTO project is never just a DLL, but includes at the very least a manifest. Your DLL is a general, managed code DLL not bound to anything in particular and not necessarily requiring full trust.

No question that the .NET Framework provides classes and structures that facilitate using web services and database connections, compared to VBA. You could still do it all in VBA (by referencing outside libraries), but not as comfortably (or perhaps as quickly executing).

Since Shell is COM and your DLL is not, there might be reasons why ShellWait isn't working for you. The framework.interop newsgroup might be able to give you some pointers in this regard.

<<So I want to integrate the pieces of the application as tightly as possible and am wondering is VSTO is the way to go and it seems beyond creating pretty GUI elements, VSTO doesn't offer much else.>>

VSTO offers a way to tightly link managed code to Office documents (as an alternative to embedded VBA), or to create a managed COM add-in (rather than doing this with Delphi or VB6 or some other COM language) avoiding some of the pitfalls inherent in Shared Add-ins. If you need neither of these, nor the integrated data caching, then VSTO probably isn't what you're looking for. In that case, you should be pursuing the interoperability questions in the newsgroup for which I provided the link.

Bill R. wrote:

What's difference between 'my' DLL and the one that VSTO creates

Ahh yes... Depends on what I need... What I believe that I DO NOT need is embedded DOTNET forms within my Office documents. But, it probably make more sense to take as much code out of VBA and through it instead into VB/C# so perhaps I do need it. This is still confusing !!!!!!

Where's that link I've previoulsy seen the compasion page between the flavors of VS but am explicitly looking for a link to purchase VSTO for VS2005 (to work with Office 2003) and I do not belive that shows up in the comparison sheet.

Here's the link I'm referring to regards the components to run VSTO solutions on a clients machine:

Microsoft Visual Studio 2005 Tools for Office Second Edition Runtime (VSTO 2005 SE) (x86) . This seems download seems to be a requirement.

Here's where I'm going.... We have an Excel file which shells out to a DOTNET app and the app does a number of things from calling web services to pushing data to backend databases and then to finally updating the calling Excel file. Experience has taught that this approach is full of issues the biggest being that VBA doesn't wait for the app to finish BEFORE continuing. I've tried various fixes including the venerable SHELLWAIT function but still nothing seems to work.

Combine that with 'other' non-desirable behaviors and and there we end up with a mix of toxic goo just waiting to explode.

There may be a requirement coming along which requires us to even further add more bells to the app and I'm worried this will become a bigger mess than it already is.

So I want to integrate the pieces of the application as tightly as possible and am wondering is VSTO is the way to go and it seems beyond creating pretty GUI elements, VSTO doesn't offer much else.

I'm also concerned about distrobution since this app is and will be considered a 'one off' where it probably won't be considered an offically installable application but rather an ON DEMAND install requiring an admin - the SHELL option offers a BIG PLUS in this dept since there is nothing to install !