@simoncropp,
Please describe the issue where the above solution does not work for you.
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.
@simoncropp,
The issue has been planned to be fixed in Aspose.Slides for .NET 23.6. This release will be published in the second half of June. Thank you for your patience.
This issue is also present in Aspose.cells can you just fix aspose.drawing so all the other aspose products will work?
Can all other aspose products be fixed as well? Having same issue with Aspose.Cells
@jojoshua,
You already created the Conflicts with other Aspose products forum thread. My colleagues will help you. Thank you for your patience.
Hi Andrey,
Thank you to you and the development team for resolving this one relatively quickly - much appreciated.
Cheers,
Valdis