Hi
Thanks for your reply. We are still evaluating what Aspose Words and Cells as we’d like to use these components and avoid Microsoft Office Interop Word and Excel for well known reason (avoid COM object, OLE aut on the server for scalab and perform problems etc).
Well Aspose components cover almost all the requirements. One is missing (it is not supported yet by Aspose) and it is the printing issues. I thought to use Interop Word for this particular issue only and buy the Aspose components, but I have read that VSTO supports only Office 2003 and not 2000.
I ask you sorry, this is not the right forum to talk about Microsoft or other components but I need to implement Aspose with my requirements and the printing issue is not supported, my questions are do you know any other way which is not Interop Word to select a printer and print a word doc? Are the old doc (Word 2000) still printable with COM interfaces which are not VSTO?
Sorry, some of these questions can seem silly but I am quite confused.
Rosario
Yes, I think it is a good idea to use Office Interop for printing as a temporary workaround until Aspose.Words.Viewer release.
When MS says that VSTO supports only Office 2003 and not 2000 that means Office 2003 as an application. You need MS Office 2003 installed on production computer and VSTO will be interacting with it. VSTO can not interact with Office 2000. But that is not related to documents. Using VSTO you can use actually work with documents created with any version of Word beginning with Word’97 as they are all compatible.
So to sum up, VSTO can work with documents made with Word 2000 but cannot interact with Word2000 itself as an application.
Hi thanks for your answer.
So if I create, mailmerge etc a doc with Aspose I can then print with VSTO? I am happy with that but in order to keep VSTO installed on the server does the user need to install them separately independently if they install or not Office and which version of it?
If I understand what you mean the Interop word assemblies do not expose directly word objects but intermediate objects which can work with the application but acn also simply work with documents. I mean when we add as reference Microsoft.Office.Interop.Word.dll and we refer as:
Word.ApplicationClass ac = new Word.ApplicationClass();
We could have the Word app installed at all and when we refer to the Active Document and we assign the printer we are not assigning the printer to Word but just to the interop object?
Well I know it is not the right place but this is my scenario, we’d like to buy Aspose which can solve most of the requirements, but some of it need the printing, our customer have different release of Office (mostly 2000 and 2003), possibly on the server none of these will be installed, are Aspose + VSTO complete for creating, formatting and printing doc and rtf documents?
I also tried with winspool.Drv but I didn’t succeded, when Aspose.Words.Viewer is ready?
Rosario
Sorry, I don’t quite understand what your question is. Please give me a more detailed description of your application scenario, especially how the interaction with users will be organized.
Please mind that VSTO needs Office 2003 to be installed. Otherwise, it won’t work.
Concerning Aspose.Words.Viewer release date I cannot provide more info.
Best regards,
Hi
Well you are right the scenario it is confusing for ourself as weel as we have to migrate a huge windows app to a web only app. We are still prototyping, one of the issue is the Office integration.
Well, in the old application (windows) all the Office integration (90% they are mail merge) are on the client, so also sending email with docs attached and printing the merge result is done on the client side. Keeping these functionalities on the client for a web application means develop massive client code, depending on the technologies you want to use: Javascript, VBScript, Applet Java, ActiveX etc. As soon as we think about these client side coding managers and customers get mad, they want a SERVER SOLUTION, I appreciate and I understand that I also don’t want to distribute ActiveX with my web app, but we can have other problems.
Well, A classical SERVER SOLUTION means working with COM interfaces, or with new VSTO interop services which are essentially COM wrapper (the same?) and we know that Office apps are not supported by Microsoft on the server because everyone know they are not server apps and for a web site with many simultanous requestes we could have serious problems of scalability and performances.
I read about Aspose and all promising stuff, I really like these components, you don’t need Office, they are quick, the object model is simple etc. Problems is you don’t support something we need, for example the printing (and I think the RTF generation) so I have to interface this lacking with other stuff like for example VSTO and at this point I am confused because reading the documentation they said that VSTO support only 2003, what this means exactly I don’t understand. I need only use it to send docs to the printers (on the server). Our customers have 2003 and 2000, but because it is only a server solution we could ask to buy one licence only for the server, it is not too bad, but I have to add Aspose and if I can avoid to force the customer to buy something which Microsoft don’t support is better is it? I read somewhere you can use VSTO without Office installed. We also need generating RTF, so we still need these assemblies. Another confusion is on the assemblies to use in Visual Studio 2005, are they not compatible for different Office version? Don’t understand. Can document generated with VSTO (but what about Aspose?) be opened with Word 2000 and Word 2003 versions? I really don’t understand what to suggest to the managers, I am still so confused. The ideal would be to have only one product that makes everything for you but ideal things don’t exist in the IT world.
Well, documents, generated with MS Word 97-2003 have the same binary format and generally are compatible, which means you can always open document generated in one version of Word with another version of Word. There is some information that is lost in the process, like list and table styles for example, which appeared only since Word XP. Some advanced shape formatting can also be lost when opened in older versions of Word. But generally the documents can be pretty well transferred between different versions of Word (Word 97 or higher).
Platform interop assemblies exist for Word XP and Word 2003 only. They are different but use basically the same object model, and some guys report that they manage to make application be compatible with both of them by using late binding. I have not tried it myself, so I cannot confirm it definitely. You can also work with Word2000 and Word97 via COM interop just by adding reference in your project to corresponding COM objects (they will appear in the Add Reference | COM tab if you have the appropriate Office installed on your system).
If you need MS Word for printing only you can use DDE communication. This approach will make your app to be compatible with any version of MS Word, beginning with Word 97. I have not worked with DDE myself but here is a good link on the topic.
And in several months we will be able to offer you a complete solution including printing and RTF support, but we cannot provide an exact deadline for this yet, unfortunately. So it is up to you what train to take
Best regards,
Thanks
I think it is anyway better using late binding trying to use interop assemblies than dde commands (that could be last chances). Have you got any code examples for interop late binding? Just for printing as my doc will be created with Aspose.
Regards
Rosario
I am afraid we don’t have any interop examples. We simply don’t use it, as we actually provide an alternative to interop. I am sure there are plenty of examples in the internet. I myself would recommend searching www.codeproject.com . I am sure they have something useful on the topic.
Best regards,
Thanks I had a look at DDE but I didn’t like it then I used something like this:
// The type of the Word application. Used for dynamically creating.
Type wordType = Type.GetTypeFromProgID("Word.Application");
// The main Word application object.
object wordApplication = Activator.CreateInstance(wordType);
// Show Word.
wordType.InvokeMember(
"Visible",
BindingFlags.SetProperty,
null,
wordApplication,
new object[]
{
true
});
// Get the Documents collection.
object wordDocuments = wordType.InvokeMember(
"Documents",
BindingFlags.GetProperty,
null,
wordApplication,
new object[]
{
});
// Open a given Word document.
object FilePath = Path.Combine(Environment.CurrentDirectory, "rosariotest.doc");
object o = Missing.Value;
object[] parameters = new object[1] { FilePath };
object wordDocument = wordDocuments.GetType().InvokeMember("Open",
BindingFlags.InvokeMethod | BindingFlags.OptionalParamBinding,
null, wordDocuments, parameters);
// Print the active document
wordType.InvokeMember("PrintOut", BindingFlags.InvokeMethod, null, wordApplication, null);
// Close the application.
wordType.InvokeMember(
"Quit",
BindingFlags.InvokeMethod,
null,
wordApplication,
new object[]
{
});
It works it can be used by other people until you don’t support printing.
Rosario
Look like that could be really useful to other customers. Thanks for providing this fine piece of code. I have a question though - what references do I need to add to the project to make it working?
Hi
You don’t need to add any reference as this is late-binding, the only things you need are
using System.IO;
and
using System.Reflection;
to add on the top of your unit. Theoretically it should work with all Office versions starting from 2000 (and probably earlier) but I have not tested, I have tested only on my machine where Office 2003 is installed, when I’ll test on Office 2000 next days or next weeks I’ll let you know.
Regards
Rosario
Wow, that is impressive. Late-binding is perfect as it is supposed to be independent of Word version.
Thanks again for providing the code.
Be carefull here, late binding doesn’t solve the world problems, it is just safer. When you use late binding, you instruct your application to use IDispatch for a particular object’s interface, Invoke is used to make the Automation calls, performances can be bad if your interaction is huge. Early binding references a type library, to keep compatibility you should reference the earliest version of the Office application you intend to support but you have to be carefull to compile your version always with the reference always to the same type library version.
If your app doesn’t interact too much (in my case is just for printing a doc) well I think the late binding is better as I don’t risk to broke the reference as I don’t have one at all, some compilers automatically refresh your references with the latest library is installed and that can broken you application.
Anyway the commands you invoke with late binding have to be versions compatible anyway. Eventually with late binding you can Invoke a “Version” command and handle different target Office versions in different ways.
Regards
Rosario