PDFNet.DLL Seems to be built for AMD processor

Technical Support Apryse SDK
1

Yes, PDFNet for .NET is a true .NET component and can be used by any .NET language (e.g. C#, VB.NET, etc). The assembly doesn’t use PInvoke or COM interop and does not require/depend on other unmanaged non-system components.

At the same, PDFNet for .NET, a ‘mixed’ component and is not a ‘verifiable’ since it has some native dependencies (e.g. for printer driver support, XPS printing, GDI, efficient image libs, COM interop etc - these feaures are by definition impossible to do in ‘verifiable’ .NET components).

2

‘Any CPU’ selection means different things in different versions of Visual Studio, however you can definitely make and make the app work correctly on both x86, x64, and other platforms.

The issue is not PDFNet specific any there are many solutions:

a) The simplest option is to select x86 in your project solution. With this option the app will work on both x86 and x64 sytem.

b) A bit more complicated option is that you select ‘Any CPU’ mode in your app. As part of the app install you would copy/install a version of PDFNet that matches the target hardware (i.e. x86, x64). This is possible because both versions have the same signature/cert.

c) Alternatively you can register both DLLs in GAC.

d) In case you do not want to haver any app ‘installer’ and you still want to use ‘Any CPU’ there are also multiple options some which are outlined here http://stackoverflow.com/questions/108971/using-side-by-side-assemblies-to-load-the-x64-or-x32-version-of-a-dll.

On Friday, October 12, 2012 11:21:13 AM UTC-7, CodeScrubber wrote:

This means I cannot create an ‘Any CPU’ .NET component in C# directly dependant PDFNet for .NET and have it work correctly on both 32 and 64 bit Windows?

On Friday, October 12, 2012 12:53:55 PM UTC-4, Support wrote:

Yes, PDFNet for .NET is a true .NET component and can be used by any .NET language (e.g. C#, VB.NET, etc). The assembly doesn’t use PInvoke or COM interop and does not require/depend on other unmanaged non-system components.

At the same, PDFNet for .NET, a ‘mixed’ component and is not a ‘verifiable’ since it has some native dependencies (e.g. for printer driver support, XPS printing, GDI, efficient image libs, COM interop etc - these feaures are by definition impossible to do in ‘verifiable’ .NET components).

On Friday, October 12, 2012 8:50:12 AM UTC-7, CodeScrubber wrote:

Is this true?
Could someone from PDFTron explain the following from http://www.pdftron.com/pdfnet/features.html

  • .NET (for .Net Framework 1.1x and above) - a 100% .Net component that can be used from any .NET language (such as C# and VB.NET.).

Doesn’t processor architecture imply native code?