Wpf: FileFormatException is in WindowsBase and System.IO.Packaging

[ccifra]

FileFormatException is in WindowsBase and System.IO.Packaging

I am working on porting a WPF application to .NET Core. The projects reference the Microsoft.Windows.Compatibility nuget to bring in types that I need. I am running into issues with FileFormatException. When I use it I get a build error that FileFormatException is defined in WindowsBase and System.IO.Packaging.

General

I am seeing this issue with .NET Core 3 preview 1 and Microsoft.Windows.Compatibility nuget version 2.1.0-preview.18571.3. I could probably solve this with an Alias but that seems ugly and I don't even know how to alias an assembly that comes from a nuget.

You can see here where it is defined in more than 1 assembly:
https://apisof.net/catalog/System.IO.FileFormatException

You can also reproduce the issue by creating a default WPF .NET Core app, reference Microsoft.Windows.Compatibility and try to use a FileFormatException.

[karelz]

@danmosemsft @vatsan-madhavan @rladuca any idea what's going on here? Is the type currently defined in 2 places?
The CoreFX version hints that it is typeforwarded from WindowsBase:
https://github.com/dotnet/corefx/blob/a10890f4ffe0fadf090c922578ba0e606ebdd16c/src/System.IO.Packaging/src/System/IO/Packaging/FileFormatException.cs#L15-L19

However, I wonder how WPF dependency on compat pack works ... I heard it raised as a concern recently. cc @ericstj

[rladuca]

As of right now, all of System.IO.Packaging exists both in the compat pack and in WindowsBase. We haven't done the work to remove it from WindowsBase, we have a work item for that already.

[danmosemsft]

You plan to remove it from WindowsBase? The S.IO.Packaging that is in CoreFX today is only a subset.

This is tracked here, but not currently scheduled: https://github.com/dotnet/corefx/issues/29959

[rladuca]

@danmosemsft When I say we have a work item, that work item is not scheduled for the immediate future, but we recognize that we need to do work to clean up the duplicates. As that work gets completed that duplicate list will grow. It's best to wait and do it all in one go, but I don't have any easy solution for developers in the short term.

[danmosemsft]

Yep, I just wanted to clarify that this was not correct:

all of System.IO.Packaging exists both in the compat pack

[danmosemsft]

Meanwhile a possible workaround could be to remove the reference on S.IO.Packaging - you are probably getting that implicitly through referencing the Compatibility pack, which is a meta package. You could remove that and explicitly reference the packages you want (excluding S.IO.Packaging)

[rladuca]

@danmosemsft Yes, you could do that, but how does that interact with publishing? Most WPF applications on .NET Core (that we've seen) tend to publish self-contained. Maybe there is some extra workaround we can add there, but I don't have the requisite knowledge to know how to fix that with VS publish.

[ericstj]

That's fine so long as folks aren't doing runtime compilation. Once it's gone through the compiler there isn't any ambiguity because the assembly names (and thus type names) are totally different.

[ccifra]

Switching to using the individual packages from Microsoft.Windows.Compatibility except for Microsoft.Windows.Compatibility.Shims and System.IO.Packaging seems to resolve the compile issue. I haven't tested everything yet, but I am able to make progress.

[grubioe]

Closing as fixed.