@ashaspose
I’ll contact the development team and write what they think about this.
@ashaspose
At the moment, the development team has a clear intention to remove the variant for .Net Framework 4,
but what minimum .Net Framework to leave is not yet completely certain.
I have passed on your comment (wish) to them and they will take it into account when making a decision.
Allow me to throw my opinion in here. Unless there is something in 4.8.1 that Aspose.Pdf is relying on it would be much better to go to 4.8 as the target framework. If there is something in 4.8.1 that Aspose.Pdf is relying on I would love to know what it is.
4.8 can be run on anything from Windows Server 2012 and later and Windows 7 and later. I’ve got a few customer sites still running Server 2016 so I’m blocked from updating Aspose.Pdf to anything after 24.3
@mike.doerfler
I passed the arguments from this topic to the development team. However, it was decided to leave only 4.8.1. The library with 4.0 support can be downloaded from the page,
For old Net Framework.png (46.2 KB)
but this option is temporary.
I’d really like to know what part of Net Framework 4.8.1 is required for Aspose.PDF that is not in 4.8. The MS decision (of which you have no control) to not support 2016 & 2019 is the really bad decision and most surprising considering how good they are with compatibility.
@mike.doerfler
As I thought, the issue is in the size of the nuget package and the need for additional release procedures when making the release.
However, upon request, the development team provided more complete information.
"We have never published version 4.8, I just checked again, we initially added 4.8.1, before that there were 4.0 and 4.0 client profile, when adding 4.8.1 we removed 4.0 client profile, and later, when adding NET8, we removed 4.0.
The issue here is both the size of the nuget package, and the fact that 4.0 is already an outdated version, Microsoft has also stopped supporting it.
The user most likely installed version 4.0 on the 4.8 project, since we removed it from the main nuget package starting with 24.4"
I completely understand getting rid of the 4.0 and 4.0 client profile. With Windows 10 being the last supported workstation OS you are pretty much guaranteed to have at least .NET Framework 4.7.2 as the minimum version.
If you publish a .net 4.8 as part of the NuGet you don’t need to publish .net 4.8.1. What I see a lot of other companies do (and what we do) is publish both a net 4.7.2 and a net 8.0. That covers all of our applications and completely covers all supported versions of Windows - desktop and server.
Targeting .net 4.8.1 is very limiting because it only is available on Server 2022 - MS really should have called it 4.9 if they were not going to support it on 2016/2019. We have customers of our software that are running Server 2016 and 2019 mostly. Server 2022 was too new when 2012 went EOL so many went with Server 2019 for their upgrades. They won’t upgrade a working server until it hits EOL.
That means we can’t upgrade Aspose.Pdf because our customers are running servers that don’t support .net 4.8.1. I’m all for moving forward and would love to be .net 8.0 only, but I still have some large applications (not Aspose) I’m waiting on before I can drop net 4. 7.2
@mike.doerfler
I will pass your opinion on to the development team, but I cannot promise that version 4.8 will appear.
I understand that you can’t promise anything - appreciate you passing the information along. I really don’t understand the decision unless there really is something in 4.8.1 that is required for Aspose.Pdf to run.
1 Like
Just wanted to add that only Aspose.PDF has this .NET 4.8.1 minimum requirement now.
Of the rest, as of 24.10, the highest seems to be Aspose.Words with a dedicated .NET 4.6.2 build inside nuget.
1 Like
@mike.doerfler
@ashaspose
I showed to PM of the developer group the information that you provided.
In any case, this will be taken into account, but I can’t to promise something.
Perhaps there are some internal architectural reasons that are not voiced.
@mike.doerfler
@ashaspose
The development team has suggested
Suggest using .NET Standard 2.0 if they have 4.6+ and there is no problem with this build.
Thanks.
Using .NET Standard build is causing the problem in the first post:
- a lot more DLL dependencies (all other Aspose products are self-contained)
- if there are any other libraries involved, with their own .NET Standard dependencies, lots of runtime version redirecting may be necessary.
This is problematic for older .NET applications that run on Windows 2019 (still supported until 2029), and something that was just nuget upgrade until 24.4, is becoming much more complicated.
Which is why the ask is to reduce the platform requirement in nuget from 4.8.1 to the smallest of 4.8 / 4.7.2 / 4.6.2 (as other Aspose products), which solves the problem.
If it’s technically impossible, there is functionality in Aspose.PDF that critically requires 4.8**.1** specifically, it would be useful to know what exactly that functionality is. It would also likely mean that this functionality is not present in either legacy 4.0 build or .NET Standard build.
1 Like
@sergei.shibanov - if I can add something to @ashaspose reply. If I update all of my PackageReferences to 24.10 for the various Aspose libraries
And I go run my Unit Test projects - I see test failures like this that indicate I’m in DLL hell and need to start adding binding redirects to every application I have that uses Aspose.Pdf
#=zyUP0_1bfZucVGniYnzeOuK_oiX0Gg5rCtA== : Parsing of table ‘name’ has failed.
----> System.IO.FileLoadException : Could not load file or assembly ‘System.Text.Encoding.CodePages, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
While yes it is technically possible to use netstandard2.0 DLLs from NuGet in .NET 4.7.2/4.8 applications it gets messy. Library authors don’t deal with it, but people deploying applications do.
This is an unnecessary complication that could be eliminated if Aspose.PDF changed the NET Framework in the nuget package from net481 to net48 or net472.
I would love to hear WHAT in Aspose.PDF requires the target to be changed to net481 specifically. If there is something specific that only exists in net481 I would be most surprised because the net481 release notes only mention support for arm64, accessible tooltips, and windows form changes.
If you want to reduce the size of the Nuget package then get rid of netstandard2.0. The package already has a net6.0, net7.0, and net8.0 support. The only MS supported one in that list is net8.0.
Aspose.PDF and Aspose.HTML (as of 23.3) are the only Aspose products that I’m running into this with. Even Aspose.Imaging is avoiding this mess, and it probably has lots to deal with because of System.Drawing and linux support.
@mike.doerfler
Thank you for the additional clarification.
I will pass it on to the development team.
Just want to add my preference for .Net Framework 4.8 support for the exact reasons above.
When 4.0 was dropped for 4.8.1, we tried unsuccessfully to use Standard 2 as we still needed to support systems that cannot upgrade to 4.8.1 (max 4.8). Unfortunately with all the pre reqs and binding redirects it just ended miserably.
I agree with the above in that unless there’s a specific need for 4.8.1 over 4.8, the preference should be 4.8. The other Aspose libraries do not require 4.8.1.
2 Likes
@GaryO
I will point out that the issue is in demand and several users have written about it.
Thanks.
I understand the decision to discontinue support for .NET Framework 4.0 due to its obsolescence. However, targeting .NET Framework 4.8.1 exclusively poses challenges, as it is not available on older Windows 10 builds and Windows Server 2019, which are still widely used. It would be beneficial to consider supporting .NET Framework 4.8 or even 4.7.2 to maintain broader compatibility. This approach would align with the support provided by other Aspose products and help avoid potential issues with additional dependencies introduced by .NET Standard builds.
1 Like
@cornelos
I presented the above arguments in a personal message to PM and in an extended call with the development team. I was not given any comments, and unfortunately I can’t say anything about the reaction and plans either.