Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dotnetcore 2.1 support for init command #665

Merged
merged 7 commits into from Sep 27, 2018

Conversation

heitorlessa
Copy link
Contributor

@heitorlessa heitorlessa commented Sep 13, 2018

Issue #, if available: #609

Description of changes:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@heitorlessa heitorlessa changed the title Add dotnetcore 2.1 support for init command WIP: Add dotnetcore 2.1 support for init command Sep 13, 2018
@heitorlessa heitorlessa changed the title WIP: Add dotnetcore 2.1 support for init command Add dotnetcore 2.1 support for init command Sep 13, 2018
@heitorlessa
Copy link
Contributor Author

cc @sanathkr @jfuss

Copy link
Contributor

@alexcasalboni alexcasalboni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good!

@gitsno
Copy link

gitsno commented Sep 13, 2018

If you're making dotnetcore 2.1 the default then I think you also need to change the version in the aws-lambda-tools-defaults.json file in the src/HelloWorld folder.
Also the TargetFramework in the HelloWorld.csproj and HelloWorld.Tests.csproj files needs to be changed to netcoreapp2.1

@heitorlessa
Copy link
Contributor Author

heitorlessa commented Sep 13, 2018 via email

@heitorlessa
Copy link
Contributor Author

@gitsno Change made and I also found another file that needed changing so Visual Studio would pick up the changes too (not only SAM).

Followed guidelines here: https://docs.microsoft.com/en-us/aspnet/core/migration/20_21?view=aspnetcore-2.1

Installed latest Visual Studio and it recognized the latest and the target framework to 2.1 too.

Copy link
Contributor

@jfuss jfuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks good. Just a couple questions, that might make it easier to expand this in the future.

@@ -16,7 +16,11 @@ Resources:
Properties:
CodeUri: src/HelloWorld/bin/Debug/netcoreapp2.0/publish
Handler: HelloWorld::HelloWorld.Function::FunctionHandler
{%- if cookiecutter.runtime == 'dotnetcore2.0' %}
Runtime: dotnetcore2.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can runtime just be the value of cookiecutter.runtime?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could for explicit runtimes (non-defaults) but not default as we allow customers to also use the shorthand dotnet to use the latest we support.

I'll change the flow control to only hardcode a value for non-default as it'll keep it clean

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done for explicit and valid runtime value

"framework": "netcoreapp2.0",
"function-runtime": "dotnetcore2.0",
{%- else %}
"function-runtime": "dotnetcore2.1",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there becomes a dotnetcore2.2, we will default to dotnetcore2.1.

What if we had defaults to set here and then explicitly checked the runtime for each dotnetcore version:

if runtime == dotnetcore2.0:
  # stuff for 2.0 version 
elif runtime == dotnetcore2.1:
  # stuff for 2.1 version
else:
  # default

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As of now I don't know of any VS defaults and purely following the migration guidelines. Now that you mentioned, I think it's best to explicit check runtime and remove else altogether until there are known defaults

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@jfuss jfuss added stage/in-progress A fix is being worked on area/init sam init labels Sep 17, 2018
@heitorlessa
Copy link
Contributor Author

@jfuss @sanathkr now all feedbacks are addressed and this also fixes #673

Copy link
Contributor

@jfuss jfuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking the time and adding this example in! 🎉

@jfuss jfuss merged commit 7c35e17 into aws:develop Sep 27, 2018
@sriram-mv sriram-mv mentioned this pull request Oct 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/init sam init stage/in-progress A fix is being worked on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants