WE have created one dll in .NET framework 8.0 which was working fine with all required aspose product depeendency, Today we have requirement to upgrade that dll in new project with Target Framework (.NET 8.0)
Now with upgraded project, when it executes this line its giving error as below,
using (MemoryStream mhtmlStream = new MemoryStream())
{
// Use the correct MHTML save options
var mhtmlOptions = Aspose.Email.SaveOptions.DefaultMhtml;
mhtmlOptions.MhtFormatOptions = MhtFormatOptions.WriteHeader |
MhtFormatOptions.DisplayAsOutlook |
MhtFormatOptions.WriteOutlineAttachments |
MhtFormatOptions.WriteCompleteEmailAddress;
// message.Headers.Clear(); // Clear headers to avoid duplication in MHTML
message.Save(mhtmlStream, mhtmlOptions);
}
Here this message.Save(mhtmlStream, mhtmlOptions) line gives an error as below, System.IO.FileNotFoundException: ‘Could not load file or assembly ‘System.Security.Cryptography.Pkcs, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’. The system cannot find the file specified.’
I did try to Install latest version package for System.Security.Cryptography.Pkcs 10.0.0 but still it gives the same error, then trying to upgrade it back to 7.0.0 but while upgrade it giving error as ,
Warning As Error: Detected package downgrade: System.Security.Cryptography.Pkcs from 8.0.1 to 7.0.0. Reference the package directly from the project to select a different version. AsposeDocumentProcessor → Aspose.Cells 25.11.0 → System.Security.Cryptography.Pkcs (>= 8.0.1) AsposeDocumentProcessor → System.Security.Cryptography.Pkcs (>= 7.0.0)
I did try to upgrade lower version of Aspose.cell and ASpose.email to 25.9.0 but still same error.
Summary MailMessage.Save throws a FileNotFoundException because the runtime cannot locate the System.Security.Cryptography.Pkcs assembly that the Aspose.Email library expects. The project targets .NET 8, but the package graph contains a reference (direct or transitive) to an older version of System.Security.Cryptography.Pkcs, causing a version mismatch at runtime.
Why it happens
Aspose.Email (and related Aspose libraries) have a dependency on System.Security.Cryptography.Pkcs that matches the version shipped with the target framework or a newer NuGet package.
An explicit or transitive reference to an older version (e.g., 7.x) forces the compiled metadata to look for that exact version, which is not present in the .NET 8 shared framework.
The NuGet restore therefore ends up with a downgrade warning, and at runtime the loader cannot find the requested assembly.
What to do next
Inspect the package graph
dotnet list package --include-transitive | grep System.Security.Cryptography.Pkcs
Identify which project or transitive dependency is pulling in the older version.
Remove or override the old reference
Delete any <PackageReference Include="System.Security.Cryptography.Pkcs" Version="7.*" /> line from your .csproj files.
Add an explicit reference that matches the version required by Aspose (or simply let the SDK resolve the version that ships with .NET 8):
(Do not specify a version unless you need to force a particular one.)
Update Aspose packages
In the NuGet package manager, update Aspose.Email (and Aspose.Cells if used) to the latest stable build that declares support for .NET 8.
If you must stay on an older Aspose version, choose a build that targets .NET Standard 2.0, which does not depend on the newer System.Security.Cryptography.Pkcs assembly.
Restore, clean, and rebuild
dotnet restore
dotnet clean
dotnet build
Ensure the bin and obj folders are cleared so no stale binaries remain.
Verify the resolved version
After the build, open the generated <project>.deps.json file in the output folder and confirm that the entry for System.Security.Cryptography.Pkcs points to a version that exists in the .NET 8 runtime (typically the version that comes with the shared framework).
Run the code again
The call message.Save(mhtmlStream, mhtmlOptions); should now succeed without the FileNotFoundException.
If the problem persists, repeat step 1 to locate any other package that may be forcing a downgrade and add an explicit version override for that package as well.
Note: The guidance above is based on the typical cause of assembly version mismatches in .NET 8 projects and does not rely on any undocumented version numbers.
I could not fully verify this explanation against the retrieved sources. Please double-check the behaviour in your environment and confirm the exact SDK/version.
I could not fully verify this explanation against the retrieved sources. Please double-check the behaviour in your environment and confirm the exact SDK/version.