Package obsolete

[rominator1983]

We have a rather extensive Support for the XML Word-Format that is known as Flat-OPC.
What we have done is inherit the Package ourself in order to be able to create packages based on XML/String instead of ZIP.

In the wake of the Package-Property getting obsolete I was wondering if there are also plans to drop the creation of fore example WordProcessingDocument based on an already existing package.

If that would be so then we could not work with Flat-OPC and the SDK any more and would need to make major changes to our code base (easily 50 developer days)

[twsouthwick]

We plan to expose IPackage functionality. It's a similar structure to deriving from Package, but has much better composibility.

For now, however, the overloads that take Package will remain in place so that you can supply a custom Package - we just don't expose it as we don't use it directly now and changes to it may not be reflected in the OpenXmlPackage.

[rominator1983]

Thanks for your answer!
That's a relief. Though I now do have some follow ups.
I suppose the package itself will be kept somewhere in a field as before.
I mean it will not get read and transformed to something else? Because if I do some reasonable things with the package even after I have created a WordProcessingDocument then those things will be reflected in the calls to WordProcessingDocument as it has always been?

[twsouthwick]

I'm not sure about that. It would affect things that we may be caching. Can you pull beta002 and give it a try?
Most calls you would have done to the package object you should be able to do to the IPackage now. Operating on that level will correctly be reflected on both the package upon save as well as the OpenXmlPackage.

[markholst]

Hi there - we've just stumbled across this one and would appreciate your advice.

We're using System.IO.Packaging.PackageDigitalSignatureManager, which only takes a Package object. Are you also working with the relevant team to get this upgraded?

Also, is there an easy way to suppress this compiler error? I have tried a few options as identified in this article - https://stackoverflow.com/questions/10608309/disabling-obsolete-error-in-c-sharp. It seems like the only option available to us is to access this property through reflection? Without an easy way to suppress this compiler error, it almost breaks semver conventions and requires a bump to the major version.

I think, without having a suitable alternative, it's probably too soon to set this as a compiler error.

[twsouthwick]

Can you create an issue for the signing manager? That is probably a good reason to continue supporting Package constructors - you should be able to continue as normal.

For the obsolete, if you are using a new enough tool chain (can't remember the version) you can suppress is via the diagnostic id the same way as any warning. If you're not able to do that, please create an issue for that.

[markholst]

I am so sorry, I forgot to follow this up. Your recent post acted as a reminder.

Can you please confirm what the appropriate project will be to log this issue against?

[twsouthwick]

@rominator1983 would you be willing/able to submit the implementation you have to operate directly with FlatOpc? We can then help adapt it to the IPackage interfaces. We have an implementation of saving to FlatOpc and opening from, but not operating directly on - I think that would be a great addition!

[rominator1983]

I will discuss this with my superiors. We talked about that even with Eric White aeons ago. I'm afraid there are still legal reasons that don't permit making that code open source.

[twsouthwick]

Yeah, if anything changes, feel free to open a PR :)

[ernstscheithauer]

@twsouthwick I am a coworker of @rominator1983 and I sent you an email regarding this topic. Please let me know if you did not get it to make sure we get in touch directly.