Add global.json to csharp template

This is a bug report

Description

.Net core has changed the way they define projects and solutions. The CSharp template created by the framework works well as long as you can build it with an older SDK version. So, if you’ve just dowload the last version of .Net core, create a CSharp project using serverless and try to run commands like dotnet restore or dotnet build you will get an error.

The way to avoid it is to create a build.json file with the following contents:

{
    "sdk": {
        "version": "1.0.0-preview2-003131"
    }
}

When you run a dotnet command, the CLI tries to find this file in your current folder or any parent folders. The recommendation is to put the file at solution level, not at project level. So, it would be great if your framework creates the file in the folder that the user run the create command, not in the created folder.

To check that the CLI is using the right version:

• Install the right version of the SDK (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md)
• Run dotnet --version (you should see 1.0.0-preview2-003131 in your terminal window)

I’m using the version 1.15.3 of the serverless framework.

[vgaltes]

Hello both,

that’s awesome. I agree it would be good idea to pin the SDK version in the global.json. Things change quickly in the .Net core land 😛

So I think we can close this issue waiting for @slang25 PR? Let me know if I can help you.

I’ve noticed that there’s no C# or F# template when using the Azure provider. It would be great to add one there as well.

Thanks!

[slang25]

Hello again

Good news, I have found what was causing the issues on the previous PRs, when zipping up the package the aws dotnet lambda sdk would use zip if it found it on your path, if not it would use the built in .NET compression library, when it did the latter the files in the zip had the wrong permission.

I will resurrect both PRs later today and bring them up to scratch. I think pinning the sdk version a global.json is a good idea, as the sdk on the machine will move forwards while we’ll need to match what AWS support.