"dotnet new" in a folder with a dash in it causes broken Project Reference (using Amazon.Lambda.Templates)

[Marcus-L]

Repro instructions (Windows):

mkdir dash-lambda
cd dash-lambda
dotnet new lambda.aspnetcorewebapi
cd test\dash-lambda.Tests
dotnet restore

Error message:

C:\Program Files\dotnet\sdk\1.0.0\NuGet.targets(525,5): warning MSB3202: The project file "C:\Users\Marcus\Data\Development\dash-lambda\src\dash_lambda\dash_lambda.csproj" was not found. [C:\Users\Marcus\Data\Development\dash-lambda\test\dash-lambda.Tests\dash-lambda.Tests.csproj]

Cause: template is changing the "-" character to a "_" in the ProjectReference in dash-lambda.Tests.csproj:

<ItemGroup>
  <ProjectReference Include="..\..\src\dash_lambda\dash_lambda.csproj" />
</ItemGroup>

Should be:

<ItemGroup>
  <ProjectReference Include="..\..\src\dash-lambda\dash-lambda.csproj" />
</ItemGroup>

[normj]

Thanks for reporting the issue.

[Marcus-L]

Found another thing - the serverless.template also should be modified, it must use the dash in the name of the assembly (the namespace is properly escaped with "_"). This was generated:

"Properties": {
  "Handler": "dash_lambda::dash_lambda.LambdaEntryPoint::FunctionHandlerAsync"
}

should be:

"Properties": {
  "Handler": "dash-lambda::dash_lambda.LambdaEntryPoint::FunctionHandlerAsync"
}

[normj]

I opened up the dotnet/templating#1193 issue on the dotnet/templating repository to find a fix for this issue but it doesn't look like there is a fix you in the templating engine. Sounds like a fix is coming, or probably came out yesterday as part of the .NET Core 2.0 release. But if I make that change then users with the pre .NET Core 2.0 cli will be even more broken.

[Marcus-L]

I think fixing the templates for SDK/CLI v2.0/1.1.0 using the new syntax from dotnet/templating#1168 would be the least-bad option (obviously it's never great to introduce bugs even if only for older CLI versions). As of today new (2.0/1.1.0) versions of .NET Core SDK/CLI are shipping with the VS2017 15.3 or .NET Core 2.0 update, therefore many (most?) developers focusing on .NET Core should be getting the updated CLI soon. The .NET Core download site doesn't even have a direct link to download 1.x any more. It seems as though it's not just dash but also dot causing problems from the looks of #134, so I'd vote for unbreaking things going forward rather than supporting the old SDK CLI. Up to you of course.

If you updated Amazon.Lambda.Templates with the new syntax, users with the current Amazon.Lambda.Templates already installed would not be affected, and would get the fix if/when they upgraded their templates (which hopefully they'd do sometime later after installing an up-to-date .NET Core SDK). New users attempting to install the fixed template package without an up-to-date SDK would be super confused while trying to debug seemingly unrelated template issues on their own, maybe we could put something in the Blueprints README.md or update the blog post with the exact error message (not exactly sure what it'd be, maybe "project file BlueprintBaseName._1.csproj not found" or something) so it shows up in search results and put a note about requiring .NET Core SDK/CLI 1.1.0+/2.0+.

[normj]

I think you are right eventually but it does take awhile for people to move to the new bits, I'm still helping people on VS 2015 and project.json. Especially since updating Visual Studio to 15.3 doesn't include .NET Core 2.0 and you have to install it separately. I'm disappointed that there doesn't seem to be away to say a template NuGet package requires a min version of the cli.

It also gets a bit tricky on our end because we reuse the same blueprints in Visual Studio without using the dotnet/templating code. We will need to recreate that same new BlueprintBaseName._1 logic in VS.

I think we should give the new tooling a couple months to become the standard and then I would feel more confident making the change.

[ebekker]

Any progress on this? Maybe time to just move over to the new bits now?

[costleya]

We are testing the changes.

[normj]

Version 3.0.0 of Amazon.Lambda.Templates released today now has this fixed.