Hello!

I found a previous forum post here:

https://support.west-wind.com/Thread6350IIC1S.wwt

I am in a similar situation. Here's what I've been trying, maybe this is helpful to someone. Maybe someone has a better suggestion.

I created a C# Class Library project in VS Code, and it created a .NET Core dll. I couldn't get wwDotNetBridge to create an instance of it.

I read: https://west-wind.com/wconnect/weblog/ShowEntry.blog?id=57036

And used your sample project to create a new project, using "net472" as TargetFramework, and was able to create an instance of my object and call methods on it.

But now I get an error:

"Could not load file or assembly ‘System.Text.Json, Version=6.0.0.11’"

It seems that's because AWSSDK Amazon has other plans:

"In 2024, more .NET developers are finding themselves in a strange situation: suddenly, tried-and-tested .NET Framework 4.8 applications that interact with Amazon S3 start throwing cryptic build errors or runtime exceptions. The culprit? The AWS SDK for .NET has increasingly shifted toward support for .NET Core / .NET 6+, and full compatibility with .NET Framework is eroding." https://blog.dotnetframework.org/2025/07/03/%f0%9f%9a%ab-why-aws-sdk-for-s3-no-longer-works-smoothly-with-net-framework-4-8-and-how-to-fix-it/

I then tried changing my project's TargetFramework to netstandard2.0 to see if that would help. The simple methods work (return "hi";) but now it can't find AWSSDK.SimpleEmail.

So, I played around a bit, and this actually kind of seems to work.

do wwdotnetbridge
loBridge = getwwdotnetbridge()
?loBridge.loadAssembly("C:\Users\MikeHelland\.nuget\packages\awssdk.core\4.0.0.18\lib\netstandard2.0\AWSSDK.Core.dll")
?loBridge.loadAssembly("C:\Users\MikeHelland\.nuget\packages\awssdk.simpleemail\4.0.0.15\lib\netstandard2.0\AWSSDK.SimpleEmail.dll")
?loBridge.loadAssembly("C:\acedev\aw-aws-ses\bin\aw-aws-ses.dll")
loObj = loBridge.createInstance("Aceware.AwsSes")
?loObj.hi()
?loObj.sendEmail()

I'm able to create the AWS SES client and request objects. I'm still getting an error on SendEmailAsync (and SendEmail is somehow insivible to .NET Core and .NET Standard projects, unlike with a .NET Framework Project), but that's probably an AWS config/permission thing on my side. I hope.

Anyways, that's where I'm at. I thought I'd post this in case (like in the linked forum post) anyone else was having issues, and if anyone else had suggestions.

Also, any pointers for .NET Core dll's in wwDotNetBridge? In case I have to go that route.

Yeah, that library is likely targeting .NET Standard 2.0 which is pulls in a bunch of secondary assemblies. This is similar to running in .NET Core and although you're now using .NET 4.72 it raises the same issues you run into with .NET Core which is namely that you have to explicitly load all dependencies including the implicit ones.

The way I recommend you do this is:

• Make sure you create a Console project that calls your Library project
• Add the library project to your Console project and call one of the functions
• Look at the output target folder and make sure you have all the assemblies there in your path somewhere (except the Console.exe/dll)

The Console project isn't used - it's just to see what the actual required assemblies are.

You can do this with .NET 4.72 or .NET Core - I think in this cases (where the imported assembly is .NET Standard 2.0) the issues are very similar due to the implicit dependencies.

+++ Rick ---

Thanks for the suggestions, Rick.

I bailed on the .NET solution once the ease of developing and deploying it dissipated.

I ended up writing the API call as an HTTPS request in VFP. Signing it to AWS standards is not trivial. If you've never had the pleasure, check out the image here:

https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

I started the day using wwHTTP and wwEncryption, but in the process of getting it to go through I fell back to MSXML2.XMLHTTP.6.0 and vfpencryption.fll. Binary data is used as parameters and return values in the calculation and I wasn't sure if .NET interop was handling that ok.

Anyways, trying to use the AWS .NET SDK from VFP seems like a good idea. But it didn't work out for me.

Yeah once the dependencies get difficult it can be a real pain to do this. But like I said, if you don't know what you need the trick is to build a Console project and see exactly what references are required and make sure you have them all in your folder. It does work even with fairly complex dependencies. I have some Azure library things I'm calling in one app that literally has 30 dependent DLLs that are being pulled (most of them unused, but they have to be there).

Described in this article from the wwDotnetBridge Revisited session at SouthWest Fox last year:

• Finding DLLs: Unpacking NuGet Packages and their Dependencies using a .NET Project

+++ Rick ---