Jun 1, 2017 - We're pleased to announce that the AWS Toolkit for Visual Studio is now generally available (GA) for Visual Studio 2017. You can install it from. Apr 10, 2017 - Behold, Visual Studio 2017 has come to the cloud! Well, AWS at least. Get a glimpse at the provider's most recent, improved support for C#, VS,.
There are some misconceptions in the IT world that Microsoft Continuous Integration (CI) development tools may not operate smoothly on AWS. Some assume that because Visual Studio Team Services (VSTS) and.NET are Microsoft products that they must run better on a Microsoft infrastructure. We’ll show you how that’s not the case with our demo, Using Visual Studio Take, for example, using Visual Studio on AWS. According to, AWS “provides a streamlined option for Visual Studio developers who want to move deployments onto Amazon Web ServicesThe beauty of Amazon’s solution comes in the form of the AWS Toolkit for Visual Studio, a simple and elegant solution.” A second misconception is that if a customer is embedded within the Microsoft product set such as.NET and Visual Studio, the business will face too much disruption and too many changes to the CI process. This is not the case either. Again, using Visual Studio as an example, “Working in an AWS environment does not necessarily mean that developers have to give up the tools that they use on a day-to-day basis,” says. “Visual Studio can be linked to AWS with relative ease.
In fact, the entire process can be completed in a matter of a few minutes.” Simplify and Automate CI for.NET on AWS AWS has multiple tools to simplify and automate CI for.NET environments in Visual Studio:. The AWS Toolkit for Visual Studio is an extension for Microsoft Visual Studio that makes it easy for developers to develop, debug, and deploy.NET applications using AWS. Visual Studio Team Services (VSTS) are additional extensions for Microsoft VSTS and on-premises Microsoft Team Foundation Server (TFS) that make it easy to deploy.NET applications using AWS. The AWS Tools for Windows PowerShell lets developers manage their AWS services from the Windows PowerShell scripting environment.
You can manage your AWS resources with the same Windows PowerShell tools used to manage your Windows environment. AWS SDK for.NET provides.NET APIs for AWS services including Amazon S3, Amazon EC2, Amazon DynamoDB and more. Easy Development on AWS How easy is.NET development in Visual Studio on AWS? In this demo, we’ll walk through the following workflow scenario for developers that are working in Visual Studio on AWS.
We will:. Check in code changes.
Push those changes to a TFS or VSTS server. Launch a TFS build. Push that build up into Amazon S3. Use AWS Lambda to signal to AWS CodeDeploy that deployment is ready.
Push the deployment to an EC2 infrastructure on an Auto Scaling group fronted by a load balancer Check a demonstration that showcases how easy it is to work in.NET using VSTS on AWS! CI for.NET applications in Visual Studio on AWS is simple, fast, and easy.
There are multiple tools available that operate just as they would in a Windows environment. There is nothing new that needs to be learned or changed. The tools work smoothly on AWS and there is little or no interruption of development best practices. Onica is among the top 1 percent of AWS Premier Consulting Partners worldwide, and has migrated more than 10,000 Microsoft Windows instances to AWS. If you’d like to discuss your Windows environment and how it might work on AWS, please.
Update: Toolkit Released The GA version of AWS Toolkit for Visual Studio 2017 has been released to the Original Post Today we released a preview of our AWS Toolkit for Visual Studio that includes support for the release candidate (RC) version of Visual Studio 2017. Because this Visual Studio release contains some significant changes for extension developers, we're making this preview available in advance of the formal release.
We highly encourage you to pass along feedback about any issues you find or whether you were successful using the preview by commenting on this GitHub issue. AWS Lambda.NET Core Support Visual Studio 2017 also contains support for the new MSBuild project system for.NET Core projects. With this preview of the toolkit, we've updated the.NET Core Lambda support to use the new build system.
For existing Lambda projects based on the Visual Studio 2015 project.json-based build system, Visual Studio 2017 offers to migrate them to the new build system when you open the projects. Downloading and Installing the Preview The AWS Toolkit for Visual Studio contains MSBuild target files for AWS CloudFormation projects. In previous releases of Visual Studio, you had to install these files and dependencies for an extension outside of the Visual Studio folder hierarchy. This required us to use a Windows Installer to install the toolkit. Starting with Visual Studio 2017, these MSBuild extensions exist within the Visual Studio folder hierarchy and can be installed from the VSIX extension package without an installer. As the installer technology we use doesn't yet support Visual Studio 2017, we've decided to distribute the preview as a VSIX file only.
To install the preview. Download the VSIX file from the. Double-click the VSIX file. This launches the VSIX Installer process, as shown. After the installer finishes, the toolkit functions as it has in previous versions of Visual Studio. I pushed up a new build that will now include netcoreapp1.1 in the frameworks dialog box during deployment if you project is targeting.NET Core 1.1.
There is another gotcha that you need to be aware. With the new GA tooling of.NET Core it implicitly adds a dependency on the latest patch version of the framework for your target framework. So if you are targeting.NET Core 1.0 it implicitly adds dependency to 1.0.4 and if you target.NET Core 1.1 it adds a dependency to 1.1.1 which both came out last week and the beanstalk AMI haven't been updated yet. The beanstalk AMI will get updated once the Beanstalk team finishes their testing and verification but till then you need override the implicit dependency in your project. To do that edit your csproj file and add the following element in your PropertyGroup section where the target framework is specified. For.NET Core 1.0 1.0.3 For.NET Core 1.1 1.1.0 Full example for context. Another one of the quirks with the new.NET Core tooling is.NET Standard class libraries will implicitly pull in the NETStandard.Lbrary 1.6.1 meta NuGet package which is the.NET Core 1.1 implementation of the NET Standard.
So in your case you have a.NET Core 1.0 application pulling in.NET Core 1.1 dependencies. In your csproj for your class libraries add the following xml element in your PropertyGroup to force it to use the NETStandard.Library NuGet package 1.6.0 which is the.NET Core 1.0 implementation of the standard. First off, thanks for all your work as it was a great help in resolving an issue I had earlier. I have a question, but if it is the wrong forum feel free to redirect me. I love the AWS tools, but would love to know how to do this manually using the EB CLI (or some other mechanism), but I couldn't quite figure out if/how that was possible. If nothing else it would be awesome if there was a verbose setting for the AWS tools so I could see exactly what it was doing.
Is it really just creating an archive after doing a dotnet publish, and then deploying that? Or are there also some environment variables and parameters being passed in? I finally resolved all conflicts and issues. Just as a feedback for others who might run in same troubles as I was. When you move to VS 2017, beyond converting just to project file (from json to csproj), it will try to upgrade your referenced libraries as well, and from that point everything stops working. But best part is that VS will create a backup with your original (old) files so, you can just compare side by side you json with csproj references, stick to versions that worked and continue working with VS2017. I'm not sure why but install does not detect my install of VS2017 Enterprise.
It seems to be only looking for VS2017 Community Edition? The funny thing is it installed on my laptop just fine a few days earlier. The only difference I can think of is my desktop version had the '26228.12' released on March 31, 2017 prior to installing AWS Toolkit for Visual Studio 2017. 4/4/2017 5:12:05 PM - - 4/4/2017 5:12:05 PM - Initializing Install. 4/4/2017 5:12:06 PM - Extension Details.
4/4/2017 5:12:06 PM - Identifier: 12ed248b-6d4a-47eb-be9e-8eabea0ff119 4/4/2017 5:12:06 PM - Name: AWS Toolkit for Visual Studio 2017 4/4/2017 5:12:06 PM - Author: Amazon Web Services LLC 4/4/2017 5:12:06 PM - Version: 1.12.0.1 4/4/2017 5:12:06 PM - Description: The AWS Toolkit for Visual Studio is an extension for Microsoft Visual Studio that makes it easier for developers to develop, debug, and deploy.NET applications using Amazon Web Services. With the AWS Toolkit for Visual Studio, you'll be able to get started faster and be more productive when building AWS applications. 4/4/2017 5:12:06 PM - Locale: en-US 4/4/2017 5:12:06 PM - MoreInfoURL: 4/4/2017 5:12:06 PM - InstalledByMSI: False 4/4/2017 5:12:06 PM - SupportedFrameworkVersionRange: 4.6,) 4/4/2017 5:12:06 PM - 4/4/2017 5:12:06 PM - SignatureState: ValidSignature 4/4/2017 5:12:06 PM - SignedBy: Amazon.com, Inc. 4/4/2017 5:12:06 PM - Certificate Info: 4/4/2017 5:12:06 PM - - 4/4/2017 5:12:06 PM - Subject: CN='Amazon.com, Inc.' , OU=Amazon Web Services, O='Amazon.com, Inc.' I ran an install on a system that had VS2017 Community, Professional and Enterprise editions installed and the vsix package installed cleanly on all three.
Uninstalled the toolkit (again, cleanly) and installed the build tools sku. Install of the toolkit then failed with the logged error (by the way, the (2) shown against the sku in the log is the nickname of the install, which by default is a number but can be customized). I'll follow this up on Microsoft's vsix forums to see if we can get more clarity on what might be causing the failure report from the vsix installer tool.
It looks like that build.NET Core Lambda under Parallels Desktop virtualization doesn't work: Executing publish command. Invoking 'dotnet publish', working folder ' Mac Home Documents code jrt JrtPrototype jrt.Lambda.ProcessJiraWebhooks bin Release netcoreapp1.0 publish'.
Publish: Microsoft (R) Build Engine version 15.1.1012.6693. Publish: Copyright (C) Microsoft Corporation. All rights reserved. Publish: CSC: error CS2001: Source file 'C: Windows TimeZoneHelper.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Utils Jrt.Utils.csproj.
Publish: CSC: error CS2001: Source file 'C: Windows WorklogReminderMailSenderTask.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Utils Jrt.Utils.csproj.
Publish: CSC: error CS2001: Source file 'C: Windows obj Release netstandard1.6 Jrt.Utils.AssemblyInfo.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Utils Jrt.Utils.csproj. Publish: CSC: error CS2001: Source file 'C: Windows DateTimeDayOfMonthExtensions.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Utils Jrt.Utils.csproj. Publish: CSC: error CS2001: Source file 'C: Windows MailSenderTask.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Utils Jrt.Utils.csproj. Publish: CSC: error CS2001: Source file 'C: Windows AppConfig.cs' could not be found.
Mac Home Documents code jrt JrtPrototype Jrt.Utils Jrt.Utils.csproj. Publish: C: Program Files dotnet sdk 1.0.4 Sdks Microsoft.NET.Sdk build Microsoft.NET.Sdk.targets(92,5): error: Cannot find project info for ' Mac Home Documents code jrt JrtPrototype Jrt.Utils Jrt.Utils.csproj'. This can indicate a missing project reference. Mac Home Documents code jrt JrtPrototype Jrt.Amazon Jrt.Amazon.csproj. Publish: CSC: error CS2001: Source file 'C: Windows obj Release netstandard1.6 Jrt.Data.Mongo.AssemblyInfo.cs' could not be found.
Mac Home Documents code jrt JrtPrototype Jrt.Data.Mongo Jrt.Data.Mongo.csproj. Publish: CSC: error CS2001: Source file 'C: Windows IEntity.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Data.Mongo Jrt.Data.Mongo.csproj. Publish: CSC: error CS2001: Source file 'C: Windows Attributes CollectionName.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Data.Mongo Jrt.Data.Mongo.csproj.
Publish: CSC: error CS2001: Source file 'C: Windows Attributes ConnectionNameAttribute.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Data.Mongo Jrt.Data.Mongo.csproj. Publish: CSC: error CS2001: Source file 'C: Windows Entity.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Data.Mongo Jrt.Data.Mongo.csproj.
Publish: CSC: error CS2001: Source file 'C: Windows Database.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Data.Mongo Jrt.Data.Mongo.csproj. Publish: CSC: error CS2001: Source file 'C: Windows IRepository.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Data.Mongo Jrt.Data.Mongo.csproj. Publish: CSC: error CS2001: Source file 'C: Windows Repository.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Data.Mongo Jrt.Data.Mongo.csproj. Publish: C: Program Files dotnet sdk 1.0.4 Sdks Microsoft.NET.Sdk build Microsoft.NET.Sdk.targets(92,5): error: Cannot find project info for ' Mac Home Documents code jrt JrtPrototype Jrt.Data.Mongo Jrt.Data.Mongo.csproj'.
This can indicate a missing project reference. Mac Home Documents code jrt JrtPrototype Jrt.Data Jrt.Data.csproj. Publish: C: Program Files dotnet sdk 1.0.4 Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed. Mac Home Documents code jrt JrtPrototype Jrt.Log Jrt.Log.csproj. Publish: C: Program Files dotnet sdk 1.0.4 Sdks Microsoft.NET.Sdk build Microsoft.NET.Sdk.targets(92,5): error: Cannot find project info for ' Mac Home Documents code jrt JrtPrototype Jrt.Data Jrt.Data.csproj'.
This can indicate a missing project reference. Mac Home Documents code jrt JrtPrototype Jrt.Jira Jrt.Jira.csproj. Publish: CSC: error CS2001: Source file 'C: Windows LoggingModule.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Log Jrt.Log.csproj.
Publish: CSC: error CS2001: Source file 'C: Windows obj Release netstandard1.6 Jrt.Log.AssemblyInfo.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Log Jrt.Log.csproj. Publish: CSC: error CS2001: Source file 'C: Windows GenericLambdaFunctionBase.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Lambda.Core Jrt.Lambda.Core.csproj.
Publish: CSC: error CS2001: Source file 'C: Windows SnsEventFunctionBase.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Lambda.Core Jrt.Lambda.Core.csproj. Publish: CSC: error CS2001: Source file 'C: Windows obj Release netstandard1.6 Jrt.Lambda.Core.AssemblyInfo.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Lambda.Core Jrt.Lambda.Core.csproj.
Publish: CSC: error CS2001: Source file 'C: Windows VoidLambdaFunctionBase.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Lambda.Core Jrt.Lambda.Core.csproj.
Publish: CSC: error CS2001: Source file 'C: Windows LambdaRequest.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Lambda.Core Jrt.Lambda.Core.csproj. Publish: CSC: error CS2001: Source file 'C: Windows LambdaResponse.cs' could not be found. Mac Home Documents code jrt JrtPrototype Jrt.Lambda.Core Jrt.Lambda.Core.csproj. Publish: C: Program Files dotnet sdk 1.0.4 Sdks Microsoft.NET.Sdk build Microsoft.NET.Sdk.targets(92,5): error: Cannot find project info for ' Mac Home Documents code jrt JrtPrototype Jrt.Amazon Jrt.Amazon.csproj'. This can indicate a missing project reference. Mac Home Documents code jrt JrtPrototype Jrt.Bl Jrt.Bl.csproj.
Publish: C: Program Files dotnet sdk 1.0.4 Sdks Microsoft.NET.Sdk build Microsoft.NET.Sdk.targets(92,5): error: Cannot find project info for ' Mac Home Documents code jrt JrtPrototype Jrt.Amazon Jrt.Amazon.csproj'. This can indicate a missing project reference. Mac Home Documents code jrt JrtPrototype jrt.Lambda.ProcessJiraWebhooks jrt.Lambda.ProcessJiraWebhooks.csproj My configuration: Visual Studio Community Edition 15.2 Preview of the AWS Toolkit for Visual Studio 2017 Parallels Desktop 12.2.
Thanks for your initial guidance. I think I found the documents you referenced: I installed the AWS CLI, since I was only using nuget and the visual studio 2017 SDK. I used the CLI to create the user, and then edited the credentials file. sandbox-user awsaccesskeyid = XXXX awssecretaccesskey = YYYY rolearn = arn:aws:iam::AAAAAA:role/RRRRRRR mfaserial = arn:aws:iam::BBBBBBBBBBB:mfa/UUUUU When I changed the aws-lambda-tools-defaults.json file, it seemed to take the new profile name, but the new profile created with the CLI is not available within the AWS Explorer within Visual Studio. Thanks for the log. Unfortunately it doesn't contain anything I can see pointing to the root cause. You say the tool locks up Visual Studio - (1) does the lock up occur between right-clicking the mouse on the project and the context menu appearing, or after selecting the Publish to Lambda menu option and the deployment wizard appearing?
Or sometime during use of the wizard? (2) are you able to use the Lamba node in the AWS Explorer to view functions etc (trying to establish if its a credential issue) (3) what region is your AWS Explorer set to when you try to deploy? (trying to establish if the tools are trying to hit a non-existent endpoint and taking excessive time to timeout). Thanks for taking a look Steve.
The lock occurs after you have gone through the deployment wizard and then press the final button 'Publish' on the review screen. It is after pressing that button and triggering the deployment process that it fails/locks/freezes Visual Studio.
It can be very intermittent yesterday it happened to my colleague but luckily on my workstation I was able to deploy the code. But it is certainly a big deal / potential show stopper issue for us. And we have plans to scale up using Elastic Beanstalk for our development teams. I tried using the CLI Elastic Beanstalk deployment technique but it was not easy to configure properly and I heard that it was being deprecated in favour of CodeDeploy instead.
We have other deployment options ourselves but still the right click deploy from Visual Studio into Elastic Beanstalk makes for a pretty decent developer workflow so it would be nice to have this resolved. I am happy to try and help to get to the root of this. Let me know what you may need me to do. Hi, Thank you for great update. I've tried to use.NET Core 1.1 with VS2017 for AWS Lambda and also for.NET Core 1.0. I finally forgive using.NET Core 1.1 but successfully build-CI with VS2017 +.NET Core 1.0. For person who will challenge with VS2017 there are only a tip you should understand.
As told on, 1.6.1 means use.NET Core 1.1 and dotnet build can be pass but dotnet lambda deploy-function will fail if there are any dependency on NETStandard.Library 1.6.1. You can see for your reference. It is clear reason but I believe it can not be avoid by user code,.csproj settings so I throw away any 1.6.1 dependency and dotnet lambda deploy-function successfully deploy function. I hope.NET Core 1.1 and.NET Standard 1.6.1 compliant dotnet toolkit will be publish in near future. Thanks for great update with VS2017!
For standard Asp.Net MVC apps deployed to Elastic Beanstalk it appears that it is not packaging the webapp correctly. My app (like most) has a Web.config file that has transformations for Debug and Release. When I package the app using Microsoft's Web Deploy, the transformation is applied correctly and Elastic Beanstalk picks up my production database connection just fine. When I use the AWS toolkit for VS 2017 it just uses the untransformed Web.config file. This is a big problem-particularly since setting environment variables for the EB instances doesn't seem to make it to the application itself. I was going to attempt to work around the issue using that route-but something in the IIS image isn't setting those environment variables so that the app process can see them.