Port System.Printing to C#

[bgrainger]

System.Printing is currently a C++/CLI assembly. There would be advantages to rewriting it in C#, as detailed in this comment: #5305 (comment) CC @ThomasGoulet73

I haven't reviewed all the code in the project line-by-line. There is obviously some P/Invoke, some COM, and some native types in AsyncNotifyUnmanaged.cpp, which should make the port potentially complex, but not impossible.

Are there critical blocking issues that would make a port to C# impossible? What are the reference cycles related to System.Printing and would those still exist following a C# port?

Or is this primarily about the effort of rewriting thousands of lines of C++/CLI in C#?

[kant2002]

kant2002@d91ae72

I done that using ILSpy and it requires A LOT OF polish, but my experience in doing that tells me that first should be solved cyclic dependencies in non-breaking fashion and would be good if that would would be accepted here. We should try maintain compatibility with .NET Framework, otherwise whole work would be futile IMO. So I think in order to successfully port System.Printing to C# would be good to solve cyclic dependencies first, and that proceed with rewrite. That would be massively easier for anybody.

Effort for me was not doing that in one big rewrite attempt, like it was with DirectWriteForwarder and I cannot find a way to do that, if somebody can give me ideas, I can try doing porting in more reliable fashion.

Porting that code would be very mundane, but I would say relatively easy, since nothing depends on unmanaged parts, like TTF reading in DirectWriteForwarder.

[wstaelens]

In case somebody works in printing, pretty please take a look at:

• XPS documents in .NET Core can't be opened #3546
• .NET 5 - Printing - XPS requires STA Threads #4000
• XPS huge memory issues #6296 (and the list of XPS/printing issues in this topic)

[batzen]

@wstaelens I don't think that porting to C# should be mixed with bug fixes.

[wstaelens]

@batzen regarding #3546 is an issues as a result from porting .NET Framework to .NET (Core) where a part was not converted (properly). The standard microsoft print driver from the DDK generates XPS files when printing, but these XPS files generated from the default print driver in the DDK cannot be opened because something was not fully ported. The XPS is generated in .piece files but that part was forgotten.

I don't know how deeply it is nested in System.Printing or if it is only in the System.IO.Packaging but anyway, if somebody is looking to porting System.Printing, this should be looked at as it involves printing and it is broken now.
I just don't hope somebody ports code from .NET to fully managed C#, while the .NET port from .NET Framework itself isn't ok.
Hence my comment.

The other onces are mainly memory issues that could be maybe easily resolved when code runs in C#. Fixing memory issues in managed code is often easier. Thus important to check when porting imo.

[bgrainger]

FWIW, in my mind this would be a line-by-line port (by hand) of each file, preserving the existing comments and semantics exactly as they are in the C++/CLI. (Any deviation from the C++/CLI behaviour in the port would be considered a bug.)
This would provide a base upon which bug fixes, optimisations, etc. could be made.

[kant2002]

Would be good if some test application/test was written or collected, because that rewrite should be tested not only manually, but also on working code. That will helps a lot with surpise issues later on.