Does edtFTPnet/PRO support .NET 8? Which assembly to reference for .NET Framework, .NET Core and .NET 5+

edtFTPnet/PRO installs two assemblies whose names differ by three letters, and the one you reference has to match the framework your project targets. Point a .NET 5 or later project at the .NET Framework one and it either refuses to build or throws the first time your code touches the library.

Two names are used throughout, because the file names are easy to confuse:

  • the .NET Framework assembly is edtFTPnetPRO.dll, built for .NET Framework 4.7.2.
  • the .NET Standard assembly is edtFTPnetPROSTD.dll, built for .NET Standard 2.0.

The Windows installer puts both of them on disk, in the same folder. You reference exactly one.

Which assembly do you need?

Answer from the <TargetFramework> (or <TargetFrameworkVersion>) element in your project file, before changing anything, then read only the case you land on.

Case Your project targets Reference Read
A .NET Framework 4.7.2, 4.8 or 4.8.1 edtFTPnetPRO.dll Case A
B .NET 5 or later (so .NET 6, .NET 8, .NET 9), any .NET Core release, or .NET Standard 2.0 / 2.1 edtFTPnetPROSTD.dll Case B
C .NET Framework 4.7.1 or earlier neither, yet Case C

If the project multi-targets (<TargetFrameworks>, plural), or you want one reference across a solution that mixes .NET Framework and .NET 5+ projects, you are in Case B.

One assembly covers everything in Case B because .NET Standard 2.0 is consumable by .NET Core 2.0 and every later runtime, .NET 5 through .NET 9 included. There is no separate .NET 6 build, no separate .NET 8 build, and none is needed.

The short version

In Case C, none of this applies yet: go straight to Case C and retarget the project first. For Cases A and B:

  1. Run the edtFTPnet/PRO installer on a Windows machine. The download on the website is the trial build; if you have bought a licence, take the installer from the Downloads area of your EnterpriseDT account instead. Both assemblies land in C:\Program Files (x86)\Enterprise Distributed Technologies\edtFTPnetPRO.
  2. Add a reference to exactly one assembly, the one your case names. Never both: they contain the same types under the same namespaces.
  3. Supply the licence owner and key before your code calls Connect(), by the route your case allows.

Then, per case:

  • Case A (below): reference edtFTPnetPRO.dll. A trial installation writes the licence to the registry for you, so evaluation needs no code.
  • Case B (below): reference edtFTPnetPROSTD.dll, deploy edtFTPnetPROSTD.deps.json beside it, and set LicenseOwner and LicenseKey in code. Nothing else reads a licence in this assembly.

What the installer puts on disk

Everything below is in C:\Program Files (x86)\Enterprise Distributed Technologies\edtFTPnetPRO.

File What it is Needed by
edtFTPnetPRO.dll the .NET Framework assembly, built for .NET Framework 4.7.2 Case A
edtFTPnetPROSTD.dll the .NET Standard assembly, built for .NET Standard 2.0 Case B
edtFTPnetPROSTD.deps.json the dependency manifest for the .NET Standard assembly; names the packages it needs at runtime Case B, deploy it with the DLL
edtFTPnetPRO.xml the API documentation that drives IntelliSense; not needed at runtime by either assembly optional, both
edtftp.exe the interactive FTP command shell and scripting engine optional, both
Help\html\ the Developer's Guide, as installed HTML reference

The trial installer additionally generates a 30-day trial licence during installation. Trial and production assemblies carry the same file names, and they are not interchangeable with each other's licence keys.

There is no Linux or macOS installer. If you develop on either, run the installer on any Windows machine and copy edtFTPnetPROSTD.dll and edtFTPnetPROSTD.deps.json out of that folder into your project.

Case A: your project targets .NET Framework

Reference edtFTPnetPRO.dll.

The minimum is .NET Framework 4.7.2. Since 4.8 and 4.8.1 are in-place upgrades of the same framework, a project targeting either of those works with the same assembly and needs no other change.

This assembly is the complete library. The Windows Forms visual components, the design-time property editors that appear in the Visual Studio Properties window, FTPFileSystemWatcher and the certificate manager dialog (ShowCertificateManager) exist only here.

The licence owner and key can reach it three ways:

Route How Where it is documented
Windows registry values LicenseOwner and LicenseKey under HKEY_CURRENT_USER\Software\Enterprise Distributed Technologies\edtFTPnet PRO; a trial installation writes these itself. Per-user, so a Windows service or app pool running as a different account does not see them Developer's Guide, How to use the license file
application config license.owner and license.key keys in the appSettings section of app.config or web.config same
in code assign the LicenseOwner and LicenseKey properties, or call Unlock(owner, key), on the connection object same

They are not equal in strength. See a licence you did not configure below before you rely on the config-file route.

Case B: your project targets .NET 5 or later, .NET Core, or .NET Standard

Reference edtFTPnetPROSTD.dll, and copy edtFTPnetPROSTD.deps.json next to it wherever the assembly is deployed.

The licence must be set in code. This is the difference that costs the most time, because nothing reports it until the first connection attempt:

using EnterpriseDT.Net.Ftp;
using EnterpriseDT.Util.Debug;

SecureFTPConnection.LogLevel = LogLevel.Debug;   // optional; set before the connection is created
SecureFTPConnection.LogToConsole = true;

var ftp = new SecureFTPConnection();
ftp.LicenseOwner = "your licence owner";
ftp.LicenseKey   = "000-0000-0000-0000";
ftp.ServerAddress = "sftp.example.com";
ftp.Protocol = FileTransferProtocol.SFTP;
ftp.UserName = "someuser";
ftp.Password = "somepassword";
ftp.Connect();

The .NET Standard assembly reads neither the Windows registry nor appSettings. If you are evaluating and a trial installation has already run on the machine, the trial owner and key are the LicenseOwner and LicenseKey values under HKEY_CURRENT_USER\Software\Enterprise Distributed Technologies\edtFTPnet PRO; the owner is trialuser. Copy both into your code as above.

Logging is the same story. The edtftp.log.level and edtftp.log.file application settings do nothing here. Set SecureFTPConnection.LogLevel and either SecureFTPConnection.LogToConsole or SecureFTPConnection.LogFile in code, as in the sample.

What this assembly does not contain, all of it Windows Forms related: the visual components and their design-time support, FTPFileSystemWatcher, and ShowCertificateManager. Protocol support is identical to the .NET Framework assembly, FTP, FTPS, SFTP, SCP and HTTP/HTTPS included, and so is the rest of the API.

Two consequences that follow from what is absent:

  • It is not Windows-only. With no Windows Forms dependency, no registry access and no platform-invoke, it runs on Linux and macOS under any runtime that supports .NET Standard 2.0.
  • IntelliSense needs a rename. Visual Studio looks for an XML documentation file whose base name matches the assembly, so copy edtFTPnetPRO.xml beside the DLL and rename the copy edtFTPnetPROSTD.xml.

This is also the assembly for the multi-target and mixed-solution readers the routing table sent here, because .NET Framework 4.7.2 consumes .NET Standard 2.0. The price is that every project in that solution, .NET Framework ones included, gives up the registry and config-file licence routes and must set the properties in code.

Case C: your project targets a framework below the minimum

The current release needs .NET Framework 4.7.2 or .NET Standard 2.0. A project targeting .NET Framework 4.7.1 or earlier (.NET Framework 4.6.2, 4.6.1, 4.0 and 3.5 among them) is below that line, and neither assembly in the current installer will load in it.

Two ways out:

  • Retarget the project to .NET Framework 4.7.2 or later, then follow Case A. The library API is unchanged by retargeting, so your existing code compiles as it stands. If you are moving to .NET 5 or later in the same exercise, follow Case B instead.
  • Stay on the release you already have, accepting that it receives no further security fixes. Releases covered by your original purchase remain available from the Downloads area of your EnterpriseDT account.

When it doesn't work

Ordered by how often each appears in support tickets. The case tags say which readers each applies to.

1. A .NET 5 or later project references the .NET Framework assembly (Case B)

edtFTPnetPRO.dll is compiled against .NET Framework 4.7.2 and binds to framework assemblies that .NET 5 and later do not ship, System.Windows.Forms and System.Design among them. Depending on how the reference was added, the project either fails to build or builds and then throws when your code first touches the library. Point the reference at edtFTPnetPROSTD.dll instead. Both files sit in the same folder, so for a file reference it is a one-line change; if the reference came from the NuGet package, remove the package as well and read failure 2 first.

This is the single most common report, and it usually arrives phrased as "edtFTPnetPRO.dll does not work with .NET 8". The library supports .NET 8; the file being referenced is the wrong one.

2. The package on nuget.org is years out of date (Cases A and B)

The public edtFTPnet-PRO package predates .NET Standard support entirely and carries only a .NET Framework build, so a project that restores it and then targets .NET 6 or .NET 8 fails exactly as in failure 1. A .NET Framework project will load it, and go on working, but it is many releases behind on protocol support and security fixes. The package is not being refreshed, because a public feed offers no way to restrict downloads to customers with a current support agreement. In both cases, remove the package reference and reference the assembly from your edtFTPnet/PRO installation.

3. The library reports no licence at all (Cases A and B)

License owner and/or key not found. Please set the LicenseOwner and LicenseKey properties.

Thrown from Connect() by both assemblies when no owner and key reached them. In Case A it means none of the three routes produced anything, most often an app.config that was never copied beside the executable. In Case B it appears even on a machine where a trial installation has written a perfectly good key into the registry, because that assembly does not look there; set the two properties in code, as in the Case B sample.

Evaluators on .NET 5 or later hit this first and read it as an expired or broken trial. The trial licence is fine; it has not reached the library.

4. A production key is rejected, or a production assembly is running unlicensed (Cases A and B)

This trial assembly cannot be used with a production license

The trial and production assemblies have the same file names and different contents. This message means a production key was handed to the trial build, which is what you get from the website download. Replace the assembly you referenced with the one from the Downloads area of your EnterpriseDT account, keeping the same file name. The reverse pairing, a trial key on a production assembly, does not raise this message but stops working when the trial expires.

5. The library uses a licence you did not configure (Case A)

The three routes in Case A are consulted in a fixed order, and the registry wins. A connection object reads the registry values as it is constructed; the appSettings keys are consulted only when the registry produced nothing. So on any developer machine where the trial was once installed, the trial licence silently overrides the production key in app.config, and the application starts failing on the trial's expiry date with no configuration change to explain it.

Assigning LicenseOwner and LicenseKey in code overrides both, because the assignment happens after construction. Use the in-code route wherever the deployment machine's registry contents are not under your control.

6. The .NET Standard assembly loads on your machine but not on a target machine (Case B)

edtFTPnetPROSTD.dll has package dependencies, and edtFTPnetPROSTD.deps.json is the manifest that names them for the runtime. On a development machine the restore has already put them where the host can find them; on a bare target machine it has not. The dependency assemblies are not in the installation folder and are not yours to copy by hand: run dotnet publish on your own project and deploy its whole output, manifest included, rather than copying edtFTPnetPROSTD.dll on its own.

Confirming which assembly is actually loaded

When a project has been migrated more than once, the reference in the project file and the DLL beside the executable can disagree. The library says which build it is, at Debug level, once per process, the first time your code uses it:

Running .NET standard version

comes from edtFTPnetPROSTD.dll, and

Running .NET version

comes from edtFTPnetPRO.dll.

The message is emitted the first time the library is used, so raising the level afterwards will not produce it. As the first thing your program does, before any connection object exists, set SecureFTPConnection.LogLevel to LogLevel.Debug and then either SecureFTPConnection.LogToConsole to true or SecureFTPConnection.LogFile to a path.

If you are on an older release

  • Could not load file or assembly 'edtFTPnetPROSTD, Version=…, Culture=neutral, PublicKeyToken=0dce1ad63760d80b' or one of its dependencies. Strong name validation failed. The .NET Standard assemblies up to and including 12.2.1 were shipped without a valid strong-name signature. Fixed in 12.2.2.
  • An installation that contains edtFTPnetPROCORE.dll instead of edtFTPnetPROSTD.dll is older than 12.1.0, which replaced the .NET Core 3.1 build with the .NET Standard 2.0 build. Upgrade, then follow Case B.
  • Releases before 12.1.0 require .NET Framework 4.0 and describe themselves as "edtFTPnetPRO for .NET 4.0+" in the file properties. The current minimum is 4.7.2.

Related

Other technical articles

Download Free Trial