error CS0433: The type 'ImageFormat' exists in both
'Aspose.Slides, Version=23.2.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56' and
'System.Drawing.Common, Version=6.0.0
@simoncropp,
Thank you for contacting support.
Please share the simplest project that reproduces the error you are encountering.
A post was split to a new topic: The Type ImageFormat Exists in Both Aspose.Slides and System.Drawing.Common
@simoncropp,
Our developers have investigated the case. You should use extern alias for Aspose.Slides.
More details:
Hello,
is the “external alias”-suggestion only valid for the current version or is it supposed to stay the same in future versions?
@AndreN,
The issue is not related to Aspose.Slides directly because there may be two other libraries with the same issue. This is a C# mechanism used when two versions of assemblies with the same fully-qualified type names are added to your project. Therefore, it should also remain the same for future versions of Aspose.Slides for the case.
This is a C# mechanism used when two versions of assemblies with the same fully-qualified type names are added to your project
Namespaces should be globally unique. please internalize those types. or take a nuget dependency on System.Drawing
The issue is not related to Aspose.Slides directly because there may be two other libraries with the same issue
so fix it in the other places as well
Therefore, it should also remain the same for future versions of Aspose.Slides for the case.
The current situation it no really viable moving forward
Your business is building utility libraries for developers to use in other libraries and applications. You should be in the business of making ergonomic APIs. It’s truly bizarre that you are asking us to justify why your namespaces shouldn’t collide with any other namespace, let alone one as fundamental to .NET as the System.Drawing.Common namespace.
Instead, you need to justify to us why you can’t (or don’t want to) internalise the types you are using from the System.Drawing.Common namespace.
Please describe the issue where the above solution does not work for you.
Implementing your extern alias simply turns the compile-time error into a runtime error. It allows my solution to compile, but running tests against the code produces:
Unable to load DLL 'aspose.slides.drawing.capi_vc14x64' or one of its dependencies: The specified module could not be found.
Cool, now I have to waste my time debugging a non compile-time issue when you could have just internalised those types.
Also:
- This is a breaking change on a minor version increment
- It seems like you could have made this not a breaking change, but instead you’ve elected to offload that problem onto your customers.
- Imagine how much more difficult it would be to reason with your own codebase if the libraries upon which you depend took this laissez-faire approach to namespaces.
1 Like
@valdisthomann,
Thank you for your feedback.
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): SLIDESNET-44006
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
@valdisthomann,
Our developers have taken your criticism into account. We are exploring other options.
Could you please share information about your project structure and the runtime environment?
@valdisthomann,
As an alternative way, please also try using netstandard2.0 version of Aspose.Slides that is also included in our NuGet package.
how do we do this in nuget?
do you actually verify these workarounds before proposing them?
what i dont understand is: why is there such significant push back on fixing this?
Either internalize the System.Drawing types, or reference System.Drawing.
Is there some technical reason the above are not possible
This will continue to cause friction for customers of Aspose, especially any new customers. It would seem to be in your best interest to remove this friction
We will provide you with instructions shortly. Thank you for your patience.
As for the System.Drawing types, thank you for bringing the issue to our attention. .NET 6 no longer supports System.Drawing for Linux and other non-Windows platforms:
Therefore, the current System.Drawing types are our implementation of GDI, both for Windows and for all other systems. However, this causes the difficulties you encountered. We are going to leave direct support for the native implementation of System.Drawing only for non-Windows systems, and for Windows the System.Drawing types will be used from the original package. Thus, we will eliminate name conflicts for both Windows and non-Windows systems and improve the user experience.
Thanks again for bringing this issue to our attention. We are sorry that you are upset and will do our best to help you resolve this situation as soon as possible.
You can try changing your project using the netstandard2.0 version of Aspose.Slides like this:
- Download the latest release assemblies: Downloads ---New Releases-aspose.slides-for-.net-23.5(dlls-only)
- Add the netstandard2.0 assembly as a reference instead of the Nuget reference.
Sample project: SlidesNetstandardSystemDrawing.7z (8.9 MB)
As I mentioned above, the System.Drawing types will be used from the original package for Windows in the next releases. We apologize for any inconvenience.
Therefore, the current
System.Drawingtypes are our implementation of GDI, both for Windows and for all other systems.
so why cant your make them internal?
You can try changing your project using the netstandard2.0 version of Aspose.Slides like this:
Download the latest release assemblies: Downloads ---New Releases-aspose.slides-for-.net-23.5(dlls-only)
Add the netstandard2.0 assembly as a reference instead of the Nuget reference.
This is not a viable long term workaround. we would prefer to wait until the actual root cause is fixed
Unfortunately, I don’t have such technical information. I hope our development team will resolve the issue you are encountering as soon as possible.
given this has been broken for over 3 months, perhaps it is time to involve the “development team”
@simoncropp,
I’ve requested plans for the issue from our developers for you. We will let you know soon.