matt beary
matt beary
Also applies to `AWS::StackName`
My understanding is that 116 only affects the `--template-substitutions` command-line parameter, which I am not using. This issue is when using CloudFormation's [pseudo-parameters](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html)
It looks like it's defined as a common option [here](https://github.com/aws/aws-extensions-for-dotnet-cli/blob/1c9e00610e57e36df8eff5fad931ad690bdd4582/src/Amazon.Common.DotNetCli.Tools/Options/CommonDefinedCommandOptions.cs#L116). I don't know whether it's incorrect for anything other than package-ci, though CLI help message: ``` Matt@DESKTOP-C7GV3UB MINGW64 ~/test/lambda-example/src/lambda-example $...
@normj a little off-topic, but is there any documentation you could link on using it with multiple .NET projects? That would massively simplify a few of our builds.
Digging into this, it looks like things just generally don't work right when the project is not in the same directory as the template: Taking just the first two steps...
Ah! Using `CodeUri` like that should resolve my use-case. I hadn't re-read the spec since [local folders became supported](https://github.com/awsdocs/aws-sam-developer-guide/commit/545f611833598f0d8efa2b177dedc84ac266842b#diff-fb165a3484260652a4d3a856f53b90abd929a4d45c3942e2ca8d74fd6a1fb976). ~~Does `package-ci` support zip file paths there? It looks like that's...
it gives me a workaround in which I don't need to use the project-location flag for my use-case, but doesn't resolve the issue with the help message
Our current deployment script to work around this is to: 1. run `dotnet lambda package-ci` to handle the compilation/uploads 2. run `aws cloudformation package` to handle `AWS::Include` of local resources...
it looks like it's currently re-uploading the artifact entirely, even if it's unchanged. Avoiding this could get a lot of gains: * fewer uploads - saving time, traffic, and S3...