Amazon S3 SelectObjectContent Support Missing for .NET v 5.0?

Question

I found what appears to be a breaking change in the AWS SDK between .NET v4.8 and .NET v5.0 / .NETCore v3.1. Following the tutorial in an official blog, I found I could not compile/run the examples in .NET v5.0 or .NETCore v3.1 using the synchronous method SelectObjectContent. The AWS SDK API was clear this was a callable method, but my Visual Studio/Rider saw it was implemented as an internal method, so I couldn't cleanly access it. In fact, I couldn't even compile.

However, after exhaustive attempts, I realized moving back to .NET Framework v4.8 it worked as advertised, even using the same AWS SDK nuget (v3.7.0.21).

Is there a preferred way to access that function, or was a breaking change introduced accidentally that's not documented? I'm not sure how to differentiate whether this is a problem with .NET Framework or AWS SDK, so I'm unsure where to report it. The code is from AWS, but this is dependent on .NET Framework version.

Answer 1

The synchronous method is gone because it is intended to be this way for .NET/.NET Core projects and the respective SDK.

GitHub user normj who works for AWS stated in a thread:

The reason the .NET Core version only has async is because the underlying http client available in .NET Core only supports async operations. We debated about keeping the sync methods in the .NET Core version and have them just call the async versions and then block. The problem with that is the SDK would not be following best practice for the platform and more importantly it could mask a potential performance problem.

Thus the guide you followed isn't necessarily wrong but it could be a bit misleading - you just have to use whichever is available to you.

Also, despite using the same version of the AWSSDK, depending on what framework your project is targeting, it will reference a different DLL found in the lib folder of the package, which explains why for .NET Framework projects the method is available, but for .NET Core/.NET, it is not. The properties for the DLL in Solution Explorer in Visual Studio will also indicate this (note the Path property).