OpenXML SDK 2.6 with WindowsBase

[MarkusParticipant]

Hi,

I am trying to get OpenXML SDK 2.6 to work since we are having massive troubles with the 10MB isolated storage bug. I successfully built the library but can’t use them in our solution since we need the WindowsBase assembly. I get an error telling me that the System.IO.Packaging type is defined in both assemblies. Is there any possbility to use the fixed System.IO.Packaging alongside WindowsBase?

If I remove WindowsBase I get messages like “The type ‘System.Windows-Freezable’ is defined in an assembly that is not referenced. You must add a reference to assembly ‘WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35”.

I would be glad to hear for either a possibility to use both (Packaging and WindowsBase together) or a solution to how get rid of my errors asking for WindowsBase. Or maybe I am just missing something and it’s a simple trick.

Thanks in advance
Markus

[Eric WhiteKeymaster]

Hi Marcus,

What kind of application are you building, i.e. ASP.NET, UWP, etc? What .NET framework are you using?

What is the code that is referring to System.Windows-Freezable?

It is not common for code to refer to the other bits in WindowsBase, so I am curious what is the circumstance where this occurs. Then we have to put together an approach to resolve the issues.

Cheers, Eric

[MarkusParticipant]

Hi Eric,

we are building an VSTO Add-In for Word 2010. We were using .NET 4.0 until now, but we upgraded to 4.5 so we can use OpenXML SDK 2.6.

There are 2 namespaces which are missing in WindowsBase.
System.Windows.Freezable: We are using System.Windows.Media.Brush to highlight
System.Windows.DependencyObject: We are using System.Windows.Controls.ContextMenu

I was hoping there is a possibility to add references to those specific namespaces and tell them to not look in WindowsBase.

Regards, Markus

[Eric WhiteKeymaster]

I’ll tell you what I would do – I would, just to educate myself, dive into the reference source, and see how complicated those types are. You may be able to mitigate with a minimum of effort.

http://referencesource.microsoft.com/

I have to confess – I am not a linker guru, but there probably is a way to extract your required types from the WindowsBase assembly. Scanning the reference source might provide a clue.

Will you please take a look and let me know what you find?

One more question – can you take a junk copy of your source, and hack out the references, and just those references that cause the dependency on WindowsBase, and see if it is a very select few APIs or if VSTO has a pretty hard dependency on the types in WindowsBase other than System.IO.Packaging?

[MarkusParticipant]

I’ll try checking the reference source for a solution and let you know what I find, thanks for that suggestion.

For the second question: if I understood correctly… I removed the WindowsBase assembly and checked what’s missing. System.Windows.DependencyObject Seems to be necessary for the Ribbon in Word and overall the context menu. We have 3 projects and it doesn’t let me remove the WindowsBase from the project responsible for the User Interface. So I’d say it’s a pretty hard dependency. But I’m not sure if that’s what you meant.

Regards, Markus

[Eric WhiteKeymaster]

So the question is, can we put together another ‘WindowsBase’ assembly that contains everything except System.IO.Packaging.

[MarkusParticipant]

Hi Eric,

that would be the solution for my problem I think.

Right now we are trying out the Hotfix https://support.microsoft.com/en-us/kb/2996568 since it says it fixes exactly that bug. I’m hoping this will help since I’m not sure if I’m able to build another ‘WindowsBase’ assembly that contains everything except System.IO.Packaging.

Regards, Markus

[Eric WhiteKeymaster]

Please let me know if that hotfix fixes things for you. Were you seeing the symptoms of hanging, or of throwing of exceptions?

[Marcel StraußParticipant]

Hi Markus and Eric,

we have the same problem as you – we developed an VSTO Add-In (but for Word 2013) and are running into trouble with the IsolatedStorage with the OpenXML SDK if the filesize gets bigger.

A couple of Months ago, we started to deploy our AddIn using the Windows Installer, instead of the ClickOnce-Deployment. At this moment we ran into issues with the IsolatedStorage (Exception-Message: “Unable to determine application identity of the caller”). After days of investigating and searching on google we found a working solution (see https://explodingmindslimited.wordpress.com/2012/08/31/openxml-and-powershell/). We had to create a new AppDomain for the OpenXml-things we are doing.

At the first look it worked well (and it still works fine for smaller documents), but for bigger files we still run into the IsolatedStorage problem. (Exception-Message: “Store must be open for this operation”)

Unfortunately we can´t remove the WindowsBase.dll aswell, because we need it for some WPF-Applications, the VSTO-Addin and the System.Windows.Threading.Dispatcher-Class.

Did you make any progress yet? It would be nice, if we can find out a solution for this.

Best regards,
Marcel

• This reply was modified 8 years, 1 month ago by  Marcel Strauß.

[Eric WhiteKeymaster]

I estimate that I have spent >500 hours dealing with this bug – first figuring why I was seeing what I was seeing, work-arounds to mitigate, re-writing System.IO.Packaging, and etc. It is nasty, costly bug. I didn’t have any deep desire to re-write System.IO.Packaging, but I hated this bug so badly I would do it.

My specific problem is that I needed to test the Open-Xml-Sdk and Open-Xml-PowerTools on ~500,000 files. Done serially, this takes >50 hours. So I built a system that spreads testing out to many quad-core machines. But because I was running the same executable multiple times, I ran into this bug.

In the end, the only way I could mitigate this (and it was a must, in order to get my job done) was to put the Open XML processing into a separate process. If you need to run more than one process on a single machine, you need to tweak the version number so that the assembly has a unique strong name.

I used MSMQ to communicate back and forth to the separate EXE / process. In the end, I got it to be rock-solid stable. I could test 500,000 documents in two hours.

Given that you MUST make use of WindowsBase elsewhere, you could build your Open XML processing into a separate EXE that is built with the new System.IO.Packaging. You could write code to see if the process is running, and start it if not, and then use MSMQ to communicate to the process, or just pass input/output file names as arguments to the EXE. I hate to have to suggest this, but if you need rock solid stability, IMO, this is how you could get it.

[Anonymous]

You should also ensure you set a reference to WindowsBase. This is required to use the SDK as it handles System.IO.Packaging (which is used for unzipping and opening the compressed .docx/.xlsx/.pptx as an OPC document).

[Author]

Posts