Aws-sdk-net: Write-S3Object: Method Not found

[TypicalTom]

Hi,

I've had a look around and I don't think this has been raised before, I've also done some searching of the internet to find similar experiences, I have found this: and neither of the responses have solved my issue.

I am trying to write an object to an S3 bucket using the following cmdlet:

Write-S3Object -Region "eu-west-1" -BucketName "bucketName" -File "X:\FileName"

I'm getting the following error:

Write-S3Object : Method not found: 'Void
Amazon.S3.Transfer.TransferUtilityUploadRequest.set_TagSet(System.Collections.Generic.List`1)'.
At O:\ScriptName.ps1:35 char:9

• Write-S3Object -BucketName "bucketname" -Key $ ...
• ~~~~~~~~~~~~~
  
  
  
  • CategoryInfo : NotSpecified: (:) [Write-S3Object], MissingMethodException
  
  
  • FullyQualifiedErrorId : System.MissingMethodException,Amazon.PowerShell.Cmdlets.S3.WriteS3ObjectCmdlet
  
  

I've tried passing a variety of different parameters with the cmd and I've also checked that the powershell module is installed and imported by successfully executing cmdlets like:

get-s3bucket | get-s3Object

get-s3bucket | Get-S3BucketLocation

My .NET versions are: 4.6.1 and 3.5.30729

If anyone has any help, it would be greatly appreciated.

Thanks,
Tom.

[steveataws]

What shell or environment are you running this command in? Is it possible to launch a vanilla Windows PowerShell command prompt and try the command there?

We've seen combinations of 'method not found' errors when the .net framework, or some other dlls (our sdk dlls for example) loaded in the shell are not compatible with the 3.5 framework and sdk assemblies the tools are built against. Most frequently this happens if you are running the PowerShell Tools extension for Visual Studio - iirc, it seems to cause 4.5 based assemblies to be pulled in which conflict (hence I'm curious if a vanilla shell causes the command to work).

We don't install any of 'our' files to the GAC so we should be able to safely rule out that issue from the linked post.

[TypicalTom]

Hi Steve,

Thanks for the response. I have tried using both powershell v4 and v5 (not core), I've also ensured that the tools are not the core versions, the output of the $PSVersionTable variable is:

Name Value
---- -----
PSVersion 5.1.14409.1005
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14409.1005
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

The tools I've tried are named:
AWSToolsAndSDKForNet_sdk-3.3.286.0_ps-3.3.283.0_tk-1.14.3.2.msi
Which then got uninstalled and replaced with:
AWSToolsAndSDKForNet_sdk-3.3.289.0_ps-3.3.283.0_tk-1.14.3.3.msi

I have been mostly running the commands through the ISE, stepping through the code in debug mode, by vanilla shell, do you mean saving the code as a .ps1 and executing through the command line style interface? I have installed the AWS tools for visual studio on the same VM and I have the options for the CloudFormation and the LamdaFunction as project defaults.

Thanks again,
Tom

[normj]

Closing for lack of activity

[johnwc]

I just had this same issue, and this spacific issue it has nothing to do with .Net 3.5 vs .Net 4.5. It has to do with the release of breaking changes being introduced between release with out a version update of the assembly to notate there is a difference between the two. I was referencing the _AWSSDK.Core v3.3.101.17_ in my own Cmdlet. I noticed if I ran a _AWSPowerShell_ cmdlet first, I would get a 'Method not found' exception in my cmdlet, if ran it afterwards in the same session. I compared the SDK referenced in _AWSPowerShell v3.3.509.0_ to my module and noticed that the AssemblyFileVersion were different, but the AssemblyVersion were the same. I don't think you guys are versioning the assembly correctly when breaking changes are introduced. .Net only uses the AssemblyVersion value to compare if a assembly is the same or not. And, in this case, the two assemblies that are versioned as being the same are NOT the same. So PowerShell is loading the assembly from _AWSPowerShell_ into memory and trying to use it for my cmdlet module which references a different version. This also happens in reverse if I run my cmdlet first, and then a _AWSPowerShell_ cmdlet, it gives a similar error about not matching.

My error

Method not found: 'System.IAsyncResult Amazon.Runtime.SharedInterfaces.ICoreAmazonS3.BeginDelete(System.String, System.String, System.Collections.Generic.IDictionary`2<System.String,System.Object>, System.AsyncCallback, System.Object)'.

Observation

Interface Amazon.Runtime.SharedInterfaces.ICoreAmazonS3

SDK v3.3.101.17 (My module cmdlet)

• AssemblyVersion set to only 3.3 - Should be different
• ICoreAmazonS3 Has NO BeginDelete method

SDK v3.3.101.9 (AWSPowerShell v3.3.509.0)

• AssemblyVersion set to only 3.3 - Should be different
• ICoreAmazonS3 Has BeginDelete method

Side Note: Not sure why a newer version would be missing methods, looks like maybe Async calls where removed in new method?

Update: So... after much more digging, I noticed that the AWSPowerShell module is referencing the .Net 3.5 AWSSDK libraries. Again, since there is no difference in the eyes of .Net CLR between the two libraries, it chokes. There should be some difference between the libraries. Maybe naming the files with Net35 like AWSSDK.Core.Net35.dll?

[campanellaf]

I just had this same issue, and this spacific issue it has nothing to do with .Net 3.5 vs .Net 4.5. It has to do with the release of breaking changes being introduced between release with out a version update of the assembly to notate there is a difference between the two. I was referencing the _AWSSDK.Core v3.3.101.17_ in my own Cmdlet. I noticed if I ran a _AWSPowerShell_ cmdlet first, I would get a 'Method not found' exception in my cmdlet, if ran it afterwards in the same session. I compared the SDK referenced in _AWSPowerShell v3.3.509.0_ to my module and noticed that the AssemblyFileVersion were different, but the AssemblyVersion were the same. I don't think you guys are versioning the assembly correctly when breaking changes are introduced. .Net only uses the AssemblyVersion value to compare if a assembly is the same or not. And, in this case, the two assemblies that are versioned as being the same are NOT the same. So PowerShell is loading the assembly from _AWSPowerShell_ into memory and trying to use it for my cmdlet module which references a different version. This also happens in reverse if I run my cmdlet first, and then a _AWSPowerShell_ cmdlet, it gives a similar error about not matching.

My error

Method not found: 'System.IAsyncResult Amazon.Runtime.SharedInterfaces.ICoreAmazonS3.BeginDelete(System.String, System.String, System.Collections.Generic.IDictionary`2<System.String,System.Object>, System.AsyncCallback, System.Object)'.

Observation

Interface Amazon.Runtime.SharedInterfaces.ICoreAmazonS3

SDK v3.3.101.17 (My module cmdlet)

• AssemblyVersion set to only 3.3 - Should be different
• ICoreAmazonS3 Has NO BeginDelete method

SDK v3.3.101.9 (AWSPowerShell v3.3.509.0)

• AssemblyVersion set to only 3.3 - Should be different
• ICoreAmazonS3 Has BeginDelete method

Side Note: Not sure why a newer version would be missing methods, looks like maybe Async calls where removed in new method?

Update: So... after much more digging, I noticed that the AWSPowerShell module is referencing the .Net 3.5 AWSSDK libraries. Again, since there is no difference in the eyes of .Net CLR between the two libraries, it chokes. There should be some difference between the libraries. Maybe naming the files with Net35 like AWSSDK.Core.Net35.dll?

Did you manage to fix the problem apart from identifying the cause for it?

[johnwc]

@campanellaf my only way of fixing the problem was to make sure that I referenced in my module, the same version they referenced in AWSPowerShell.NetCore module. Then writing documentation for my module that there is a hard requirement for a specific version of AWSPowerShell.NetCore. It sucks, because I now have to monitor the releases of AWSPowerShell.NetCore and update my module's referenced dlls to what there's is referencing. _(I moved my library to be .Net Standard so that it can run both in PowerShell 5 and PowerShell Core. Hence the change to AWSPowerShell.NetCore)_

Also, I'm not sure why I didn't point this out earlier as well. If a .Net library is not strong named signed, then the CLR will not use the version of the library to determine if the library is the same. It will only use the name of the library. This is why it is very important that the different .Net releases of the AWS SDK is named appropriately. Instead of all being AWSSDK.Core.dll, there should be AWSSDK.Core.Net35.dll, AWSSDK.Core.Net4.dll, AWSSDK.Core.NetStandard2.dll, etc...