Type collision with System.Drawing.Bitmap

[vpenades]

• [ ] question
• [x] bug report
• [ ] feature request

I've created a NetStandard2.0 package that depends on:

• Accord.Vision 3.8.2-alpha
• CoreCompat.System.Drawing.v2 5.2.0-preview1-r131

Then I've created a Net47 WPF application that consumes the previous package.

It complains there's a type collision with the System.Drawing.Bitmap found int System.Drawing and CoreCompat.System.Drawing.

My guess is I have to tell the main application to replace CoreCompat with System.Drawing at runtime. I know about Assembly Binding Redirect, but these are typically used to switch between different versions of the same assembly, not to switch to a complately different assembly.

So, how can I modify the project to compile?

[cesarsouza]

Hi @vpenades,

Thanks for opening the issue! However, most certainly this is not a bug, at least not a bug of this project (possibly of CoreCompat.System.Drawing since they are using the same type name as a the .NET Framework one).

If you do not want your packages to have this dependency in CoreCompat.System.Drawing, then you can simply use the Accord.Vision version for .NET 4.6.2, since it will depend on the real System.Drawing.Bitmap instead of CoreCompat. You would have to change the package you created to be a normal .NET Framework library instead of a .NET Standard2.0 one though. If your target application is WPF and therefore will run in the full .NET Framework I would highly recommend going this route.

However, answering the question, it is very likely that you can make the project compile in it's current state by specifying an alias to either System.Drawing or CoreCompat.System.Drawing, and then using the alias to disambiguate in-code which assembly you will want to use.

Regards, Cesar

[vpenades]

I can't go the Net 4.6.2 route because the root package needs to be cross platform (or at least, make things easier when actual cross platform happens). So I'll try the Alias trick as you suggested. I'll report the results when it's done.

[vpenades]

@cesarsouza I've tried to use the Alias trick you mentioned:

It's not possible for nuget package references. The properties panel that allows you to set the alias appears for direct project references and old local assembly references. But for nuget package references, it seems it's not possible to change the Alias.

So, for now, even if Accord has been moved to Net2.0, in practice is still tied to NetFX, and as you suggested, for now it's best to use it with NetFX.

In the long run, I would suggest to completely remove System.Drawing.Bitmap and replace it with ImageSharp, or some kind of custom, abstracted native image.

[cesarsouza]

Hi @vpenades,

Thanks for the suggestions! In fact, it seems that there are plans to eventually include System.Drawing in a future version of .NET Core. When this happens, the project will not need to reference CoreCompat anymore, instead targeting System.Drawing in all platforms.

By the way, do you actually need to use System.Drawing in your WPF project? If not, I think that the easiest approach for now, and maybe even the more future-proof, would be to simply create a .NET 4.7-specific version of the framework that depends on CoreCompat instead of System.Drawing. This way, you would have a dependency on CoreCompat in both the .NET Standard library and your NetFX application.

The drawback is that you would be limited to use 4.7 onwards, and current users that rely on Windows Forms users would be limited to using up to 4.6.2.

Regards, Cesar

[vpenades]

@cesarsouza I needed System.Drawing so I could display the images in a WPF application, and that's what is causing the type conflict.

But in the long run, I'm aiming for cross platform solutions. The news of MS including System.Drawing into a future version of NetCore will certainly help on this.