Ok thanks Laurence.
I have a presentation to do on VSTO and thirdy part components as aspose for example. Essentially we need to implement a web app which is able to answers ordinary client request like serve up a result of a merge doc to the client, consider that the templates have to be built manually from the customers than I can't embed them in my project, there are many other standard functions which have to be implemented but don't matter now, the mergte mail is the main one anyway.
In few words this is what I think and I'd like to have your opinion:
VSTO. The Office object models and the Office primari Interop assemblies (PIAs).
What we had before .NET was VBA, a simple development environment integrated into the Office apps and a rich object model that was accessed via COM.
Unfortunately VBA is too simple, only VB, embedded into the docs and not .NET integrate and COM is too complicate, slow and unmanaged.
Visual Studio and .NET provided a way to address all these problems, solving the VBA limitations and get the power of .NET like OOP, exception handling, web services, code access security etc the answer is Microsoft VSTO.
What the keys goals?
1) VSTO is in Visual Studio, can get the power of .NET to put code behind Excel 2003 and Word 2003 docs and templates.
2) Can be programmed in VB.NET and C#.
3) The code is now always separated by the docs avoiding the risks of macro viruses thanks .NET code-access security.
4) Data-binding support.
5) Design time views.
6) Windows form controls support.
7) Server-side programming.
8) XML support for Word and Excel.
9) Document centric solution with managed code
10) Data islands stored in docs available when client is offline
11) Fields can be marked with [cached] attribute to provide serialization.
12) The ServerDocument class accesses cache without Office installed on the server.
13) XML schema based programming.
14) Managed ActionPane
15) Simplify the
Probably the most important scenario offered by VSTO are the data islands with data cached. A server can pre-populate or extract data without having to program Excel or Word, then a client offline can access the docs and its data.
Disadvantages.
1) Interop assemblies don’t need Office installed because they are OLE Objects,
they are COM wrapper, but they need COM interfaces with its overheads.
2) Deployment: Office professional Edition 2003, PIAs, VSTO runtime plus appropriate .NET security policies.
3) Performances and scalabilities, they are only wrappers around COM interfaces.
4) .NET code access security. Both the document and the related assembly must have full trust credential. Setting the security can be complicate or unsecure because it is based on “evidences”: Signing – Authenticode or strong names or trust location URL.
5) Not managed code.
6) All the documents templates for both Word and Excel are built by the user manually then templates are merged with datasources and a result is produced, a doc is saved or sent by email.
Rosario