Console application built with .NET 4.80 and Aspose.PDF nuget package
When referencing Aspose.PDF 24.3.0, bin folder contains just Aspose.PDF.dll
When referencing Aspose.PDF 24.4.0+, build falls back to .NET Standard, and bin folder contains 20 other DLLs (Microsoft.DotNet.PlatformAbstractions.dll , System.Memory.dll etc)
This is because previously nuget dependencies contained
[dependencies]
[group targetFramework=“.NETFramework4.0” ]
[group targetFramework=“.NETFramework4.8.1”]
@ashaspose
The development team added support for .Net 8 to the Nuget package (starting from version 24.5). Because package size is limited, the version for .Net Framework 4 has been excluded from the Nuget package. In addition, it was decided to abandon it so as not to complicate product support. During the transition period, you can download a separate *.dll zip for .NET 4 from the website (Download .NET Component DLL to Process PDF | Aspose.PDF API). 123.png (48.1 KB)
While abandoning 4.0 target is understandable, would it be possible to consider maintaining either 4.62-4.8 target (as a separate download) or reducing the required version in the nuget from 4.8.1 to 4.8 (if Aspose.PDF doesn’t necessarily require 4.8.1)?
The issue is that .NET 4.8.1 does not exist for older Windows 10 builds and Server 2019 (which is still supported).
@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,
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
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.
@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.
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.
@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.
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.