“Classes within the System.Drawing.Printing namespace are not supported for use within a Windows service or ASP.NET application or service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions.”
So we would like to know if this is the case and change our code if it is.
Interesting point. I immediately have a question how else can your print from a .NET application?
Do you actually have these problems?
During the page layout and rendering process - no .NET printing classes are used. Only .NET drawing classes are used.
However, if you print using Document.Print then it definitely goes through the standard .NET printing infrastructure and printing classes.
If this turns out to be really causing problems, then we should look at printing via XPS. Aspose.Words can save as XPS and you should be able to print that on Windows. We will investigate what’s the best way to do that. If you come up with a solution, let us know.
I work with Amin, who posted the original question, above.
We have been in touch with Microsoft. Surprisingly, they have confirmed that there is no supported way to print from managed code in a service or an ASP.NET application(!!!). System.Drawing.Printing is out, for the reason listed above. The managed XPS printing classes are also out, because they are part of WPF, which is not supported server-side. I can give you more details of the information from Microsoft if necessary.
So, that only leaves one option: print XPS using the new XPS Print API. That API is coming out in Windows 7, and will be available as an ad-on pack for older versions of Windows.
Do you think that Aspose might be interested in writing some code to call the XPI Print API directly from Aspose Words? It would be really, really good for customers like us, who are using Aspose Words entirely on the server-side.
Yes, can you please email me the info you got from Microsoft, it will be helpful. Send to roman dot korchagin at aspose dot com.
Yes, I was aware about the upcoming API for the XPS Print path. We were planning to make a sample project and an article showing how to get XPS from Aspose.Words to the XPS Print Path.
When we get more details and more experience with this we might add some functions directly into Aspose.Words. Maybe printing page by page to speed up the process so the whole document does not have to be created at first.
But initially it will just work that you take complete XPS from Aspose.Words and send to printing, this will work.
We have scheduled a sample project for printing via the XpsPrint API to be implemented asap. I think it will be ready within 2 weeks or so.
Initially, it will be a simple project taking only printer name and job name as parameters. There will be no passing of print ticket etc, this can be added on later by us or by customers themselves. Here is how the requirements look now. Let me know if you have anything to add.
------------
We need to write a sample project that prints using the XpsPrint API.
You need to develop the sample either on Windows 7 (I can give you a virtual machine) or on Windows Vista. If you develop this on Vista, you need to install the platform update first
I would prefer the sample project to be written in C#. So try writing it in C# first. But XpsPrint API is quite difficult for PInvoke. So if using C# is too hard, let me know. We will need to write a wrapper DLL in C++ then.
The sample project should implement a class that looks something like this:
public class AsposeXpsPrintHelper
{
// This method sends the print job and waits for its completion. It is synchronous
// and does not return until the job is printed successfully or encounters an error.
//
// If there is any error in invoking XpsPrint API or the spooler reports a problem,
// then this needs to be thrown as an exception with a good error message.
//
// The stream contains the XPS document that was saved by Aspose.Words.
// Printer name is required.
// job name is optional.
public void Print(Stream stream, string printerName, string jobName);
}
The sample project should also include code that shows how to use Aspose.Words.Document to convert a DOC file into XPS stream and print using AsposeXpsPrintHelper.
The Print method should work something like this:
a. Call StartXpsPrintJob function https://docs.microsoft.com/en-us/windows/win32/api/xpsprint/nf-xpsprint-startxpsprintjob
b. Copy data from the .NET stream containing XPS document to the print job stream.
c. Listen for the job status changes.
d. Wait for the job completion or error.
e. If error, retrieve the error message and throw it as a .NET exception.
f. Cleanup all unmanaged resources.
For people using Aspose server-side, like us, it will also be handy to be able to interrogate basic information from Windows (which printers are available, and which trays/paper sources do they have). I don’t know if that is even possible with the XPS Print API, and as you suggest, it may fall outside the scope of your initial sample. (I guess a workaround is to retrieve that information using the existing Win32 API, rather than XPS Print)
Also, if it is necessary to write a wrapper DLL in C++, is it an option to use C++/CLI so that .NET sees the DLL as being a managed assembly? Does that offer benefits (in terms of deployment, security or …?)
The XpsPrint API allows only to start and submit a job and monitor its status.
Everything else has to go through the standard Win32 API I suppose. At least that’s what one of the MS KBase article you suggested said.
At this stage I do not see us at the Aspose.Words team coding wrappers for lots of this functionality immediately, but we could gradually add more (with the help of customers) to the sample project. It could also be that Microsoft might write some of these wrappers themselves and add them to .NET later on.
If a wrapper DLL in C++ is needed, it will probably be easier for the client code to call into a managed DLL. That will allow to hide all low level things completely inside the DLL.