Wednesday, February 4, 2015

Amazon SDK Samples Target Framework, Reference Mismatch

Quick Description:  After installing the Amazon SDK for .NET, a Visual Studio (in this case SSIS Script editor for 2012 (VS2010)) solution from one of the samples doesn't recognize the reference for AWSSDK.  In an SSIS script task, this is also an issue building a new solution using the SDK.  All usage of the namespace in the project's code generate 'type or namespace name 'Amazon' could not be found' errors.

Problem:  In this case, it was caused by a mismatch between the reference dll version and the project target framework version.  VS 2010 can't target Framework 4.5, so it should default to 3.5.  However, I'm just not really sure which dll the (AWSSDKAndSamples_2.3.18.0) are targeting by default, if you're using VS 2010 (script editor) because I tested on both a 3.5 machine and a 4.5 machine, and although both came up targeting 3.5, the .dll was mismatched on both.  I brought the S3 sample up targeting both 3.5 and 4.x and in both cases, had to remove the existing reference and add the correct one for the target version.

For Standard VS 2010.  To solve the problem in standard VS 2010, make sure both the Reference and the target Framework are the same version.  Logically, this should already be the case with the sample.

To check your Target framework, right click your project, and under Target framework, select either 3.5 or 4.x. (3.5 is the only option that is available for VS2010 and AWS SDK.

To add a new reference to the right framework (adding the reference appears to be the clincher, switching between target framework versions didn't help me).  Right click references, select Add Reference and browse for AWSSDK.dll.  If you chose a default install the .dll is in C:\Program Files (x86)\AWS SDK for .NET\bin\Net35 or Net45.

For a Script Task in SSIS (technically VS2010), unfortunately, I think you might be out of luck.  I was unable to get it to work in the script task.  If you are magic and got it to work, I would *love* to know how.  My workaround is probably not acceptable for most people, but will get you where you need to go.  I made sure 4.5 was installed on the SSIS box, and then wrote a console app in VS2013 to be launched by an SSIS Execute Process task.  It's not ideal.  The other option, of course, is to upgrade to SQL/SSIS 2014 which can target 4.5.