Fix missing entry point exception with Amazon.Lambda.TestTool

[normj]

Issue #, if available:
aws/integrations-on-dotnet-aspire-for-aws#138

Description of changes:
While using a Lambda Project that is both an executable like ASP.NET Core Minimal API but also has some class library based Lambda functions the test tool would end up picking up the version of Amazon.Lambda.RuntimeSupport that is references in the project instead of the version shipped with the test tool. The class library like Lambda functions would fail to start because the referenced version of Amazon.Lambda.RuntimeSupport was compiled as a library without an entry point, meaning not an executable.

The fix is to only build RuntimeSupport one way which is an executable. Setting the OutputType to Exe for all builds of Amazon.Lambda.RuntimeSupport just adds a bit of extra assembly metadata but it does not prevent it from being packages as a dll in a NuGet package.

I have built local versions of the NuGet packages with RuntimeSupport and build and deploy and tested with Amazon.Lambda.TestTool and everything work as expected. I confirmed with an ASP.NET Core minimal API Lambda function with extra class library style Lambda functions.

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

[philasmar]

This entire property group is now redundant, no? Since we always set OutputType to Exe on line 35. Even on netstandard2.0, OutputType will be Exe.

[normj]

Removed the redundant section

[philasmar]

Why are you doing a version downgrade?

[philasmar]

Why are we only removing the Net7 version only?

[normj]

Because .NET 7 csproj file was actually deleted from the repo. This is a msbuild target used for local builds not what the CI system uses and it had gotten stale. It was currently failing because we previously deleted the .NET 7 version.

[Copilot]

Pull request overview

This PR fixes a missing entry point exception that occurs when using Amazon.Lambda.TestTool with Lambda projects that combine executable patterns (like ASP.NET Core Minimal API) with class library-based Lambda functions. The fix ensures Amazon.Lambda.RuntimeSupport is always compiled as an executable, preventing the exception when the test tool references the project's version instead of its own bundled version.

Changes:

• Modified Amazon.Lambda.RuntimeSupport to always build as an executable by unconditionally setting OutputType to Exe
• Removed conditional compilation directives from Program.cs that previously controlled when the Main entry point existed
• Updated build scripts and Dockerfiles to remove the ExecutableOutputType parameter since it's now always set in the project file

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
Libraries/src/Amazon.Lambda.RuntimeSupport/Amazon.Lambda.RuntimeSupport.csproj	Set OutputType to Exe unconditionally with explanatory comment
Libraries/src/Amazon.Lambda.RuntimeSupport/Program.cs	Removed conditional compilation directives around Main method
Tools/LambdaTestTool-v2/src/Amazon.Lambda.TestTool/Amazon.Lambda.TestTool.csproj	Removed ExecutableOutputType parameter from publish command and version downgrade
LambdaRuntimeDockerfiles/Images/*/Dockerfile	Removed ExecutableOutputType parameter from build and publish commands
buildtools/build.proj	Removed BlazorTester70 package build step
.autover/changes/9ea31abe-8afa-4b3f-9145-addeec1e94ab.json	Added changelog entries for patch releases

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The version is being downgraded from 0.11.1 to 0.11.0, which is unusual for a bug fix. The .autover changelog indicates this is a Patch release which would typically increment the patch version. Consider whether this version change is intentional or if it should be incremented instead.

Suggested change

	<Version>0.11.0</Version>
	<Version>0.11.2</Version>

[Copilot]

The removal of the BlazorTester70 package build appears unrelated to the stated purpose of fixing the missing entry point exception. This change is not mentioned in the PR description. If this is intentional (e.g., dropping .NET 7 support which is end-of-life), it should be documented in the PR description and changelog.

[normj]

Closing this approach because if I mark Amazon.Lambda.RuntimeSupport with OutputType as Exe it breaks Native AOT compilation. Normal JIT is unaffected but we can't regress on the Native AOT experience.