Add annotation to manually specify project command line arguments. (Needed for AWS Lambda support)

[normj]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

We are looking into how we can support adding a AWS Lambda Function to the DistributedApplicationBuilder. A Lambda function can be written as an executable or as a class library. The class library programming model being the more common approach.

The executable approach is not an issue for Aspire but for the class library we need to customize the execution arguments. Lambda functions coded as a class library are started with a host executable and the depsfile and runtimeconfig are overriden at startup. The class library is passed in as an argument to the host executable. For example if we had .NET project called "ClassLibraryLambdaFunction" that contained a Lambda function it would be executed using the following:

dotnet exec --depsfile ./ClassLibraryLambdaFunction.deps.json --runtimeconfig ./ClassLibraryLambdaFunction.runtimeconfig.json ../../../../AspireExtensions/LambdaHost/Amazon.Lambda.RuntimeSupport.dll ClassLibraryLambdaFunction::ClassLibraryLambdaFunction.Function::FunctionHandler

Having this configured in the launchSettings.json file by the user is not practical and as part of an AddAWSLambdaFunction method I want to be able to setup all of these command line arguments for the user and return a LambdaProjectResource that is a subclass of ProjectResource.

Describe the solution you'd like

When adding project to the DistributedApplicationBuilder you can only specify the launchSettings profile name for configuring how the project should be started. I would like to propose adding a LaunchSettingsOverrideAnnotation annotation where all of the command line arguments for the "dotnet" command can be specified. The ApplicationExecutor would look for the annotation and if exists use it for setting up the parameters for the process.

Update February 2nd, 2025

The issue has gotten long and a bit off the original ask. We currently have a work around by writing a launchsettings profile during Aspire startup that matches the arguments set in the AppHost plus other settings to launch a class library. The work around works but it feels hacky to write to the launchsettings.json file which will cause users to change files.

The ideal solution for us is to have APIs as part of Aspire that essentially defines a launch profile in memory and hand that off to either the dotnet run or the IDE depending on whether Aspire has an IDE attached to it. I understand that is a larger task because it requires changes to the protocol for Aspire to talk to the IDE.

[eerhardt]

@normj - have you considered making the "class library" dotnet run-able? This can be done by adding MSBuild logic to set

• RunCommand
• RunArguments

See https://github.com/dotnet/sdk/blob/f7a5c4e3dc7f7ac35a2684192413530a43877a05/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L1111-L1171

These MSBuild properties are used by dotnet run and by VS (and thus by the Aspire AppHost) to launch projects.

In .NET 9, we added functionality to allow MSBuild <Target>s to set these properties, so you can run any logic to determine these values. See Extend dotnet run to invoke a run-command-producing Target (dotnet/sdk#42240).

[normj]

@eerhardt That is an interesting idea. If this was launched via the IDE would the IDE attach the debugger to it?

I do have the challenge that within a class library there could me multiple Lambda functions that need to be started up separately with different argument to identity the .NET method to call. Imagine in an Aspire AppHost the same project being added multiple times to the distributed application but with a different "handler" string that identifies what method to call. Maybe what I could do is have the MSBuild targets for running the class library look at an environment variable that the Aspire AppHost sets on the process. I'll play around and see what I can do.

[eerhardt]

If this was launched via the IDE would the IDE attach the debugger to it?

Yes. That is my understanding (although I have much less experience in the IDE tooling parts).

Look at the '$(UseAppHost)' != 'true' path:

https://github.com/dotnet/sdk/blob/f7a5c4e3dc7f7ac35a2684192413530a43877a05/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L1134-L1138

        <RunCommand Condition="'$(RunCommand)' == ''">dotnet</RunCommand>

        <_NetCoreRunArguments>exec &quot;$(TargetPath)&quot;</_NetCoreRunArguments>
        <RunArguments Condition="'$(RunArguments)' == '' and '$(StartArguments)' != ''">$(_NetCoreRunArguments) $(StartArguments)</RunArguments>
        <RunArguments Condition="'$(RunArguments)' == ''">$(_NetCoreRunArguments)</RunArguments>

This is basically the same thing you have. dotnet exec <some .dll>

[normj]

@davidfowl @eerhardt Has something changed with the IDE integration with Aspire. I my previous hack of using the launchsettings.json to configure a class library to be runnable fails. It shows running in the dashboard but I know it must have failed quickly and the PID is 0 in the dashboard. When I run this AppHost from the commandline dotnet run. I get the following error which I'm pretty sure I didn't get before but not a hundred percent I tried before.

2024-12-05T18:06:58.8810000
 Unable to run your project.
2024-12-05T18:06:58.8810000
 Ensure you have a runnable project type and ensure 'dotnet run' supports this project.
2024-12-05T18:06:58.8810000
 A runnable project should target a runnable TFM (for instance, net5.0) and have OutputType 'Exe'.
2024-12-05T18:06:58.8810000
 The current OutputType is 'Library'.

@eerhardt I did try your trick of setting the RunCommand and RunArguments instead of relying on the launchSettings.json file and that got things working for running the AppHost outside of the IDE but within it fails like I described above.

[davidfowl]

cc @vijayrkn @tlmii

[eerhardt]

The only thing that has changed around that area (that I know of) is the dotnet run functionality that @baronfel added in 9.0 -

[release/9.0.1xx] Extend dotnet run to invoke a run-command-producing Target (dotnet/sdk#42987)

Don't forward along binlog arguments to runnable applications (dotnet/sdk#43430)

[tlmii]

I'm not aware of anything specific that changed in this area from the IDE side - but that doesn't mean there wasn't something that impacted it.

@normj do you know the before/after of your setup of when it worked to now (aspire version, VS version, etc)?

If those error messages you listed were happening from the command line execution of the class library project too, then it seems like maybe its not the IDE integration that's preventing it from working (though you might be hitting a related issue we're tracking about how we display quickly-exiting executables)?

Is the launchsettings.json hack you did something we can try to replicate with any class library to try to repro this? If so do you have complete steps for it to make sure we're doing the same things?

[normj]

You can reproduce the error using my Lambda Aspire proof of concept (POC). It doesn't require an AWS account or credentials to run. The POC was made back in September and using a class library worked using the launchsettings.json file. We are picking the project back up now turning the POC into a real product and now using the latest bits the class library no longer seems to work.

To repo:

• Clone https://github.com/normj/LambdaAspirePOC
• checkout branch classlibrary-failure
• In VS launch the AppHost
• Notice the PID for ToLowerLambdaFunction project resource is 0 and there is nothing written to the logs. My guess is Aspire didn't even try to run the project because the output type was not an executable. Similar to the error we saw when using dotnet run complaining about the output type. "A runnable project should target a runnable TFM (for instance, net5.0) and have OutputType 'Exe'."

What is supposed to happen is the ClassLibraryLambdaFunction project has a profile in the launchSettings.json that provides the actual executable entry point that should be used.

{
  "profiles": {
    "LambdaRuntimeClient_FunctionHandler": {
      "commandName": "Executable",
      "commandLineArgs": "exec --depsfile ./ClassLibraryLambdaFunction.deps.json --runtimeconfig ./ClassLibraryLambdaFunction.runtimeconfig.json ../../../../AspireExtensions/LambdaHost/Amazon.Lambda.RuntimeSupport.dll ClassLibraryLambdaFunction::ClassLibraryLambdaFunction.Function::FunctionHandler",
      "workingDirectory": ".\\bin\\$(Configuration)\\net8.0",
      "executablePath": "dotnet"
    }
  }
}

In the AddAWSLambdaFunction extension method you can see I set the launch setting profile. https://github.com/normj/LambdaAspirePOC/blob/classlibrary-failure/AspireExtensions/Aspire.Hosting.AWS.Lambda/LambdaExtensions.cs#L22

If you make the ClassLibraryLambdaFunction the startup project you can confirm the profile actually starts up till you get an expected error about "Invalid URI". Through the AppHost it makes sure that URI is correctly set up.

Keep in mind my ultimate goal and the original reason for this issue is I want to get rid of dealing with the launchsettings.json file and from my AddAWSLambdaFunction extension method tell Aspire all of the command line arguments needed to run the class library.

[eerhardt]

Keep in mind my ultimate goal and the original reason for this issue is I want to get rid of dealing with the launchsettings.json file

The best way to do this is to make the project dotnet run-able. We did just that for Azure Functions support in 9.0. Check out:

https://github.com/Azure/azure-functions-dotnet-worker/blob/6338dc2e08d04a78956dd48dd6738888ab215bde/sdk/Sdk/Targets/Microsoft.Azure.Functions.Worker.Sdk.targets#L83-L90

  <!-- This target is used to set up the run arguments for the function app, supporting `dotnet run` -->
  <Target Name="_FunctionsComputeRunArguments" BeforeTargets="ComputeRunArguments">
    <PropertyGroup>
      <RunCommand>func</RunCommand>
      <RunArguments>host start $(RunArguments)</RunArguments>
      <RunWorkingDirectory>$(OutDir)</RunWorkingDirectory>
    </PropertyGroup>
  </Target>

You don't even need to use the ComputeRunArguments target if the RunCommand and RunArguments are static - you can just set the properties directly in a .targets file.

[normj]

@eerhardt I tried making it runnable basically taking what is in the launchsettings into the run properties

  <Target Name="_FunctionsComputeRunArguments" BeforeTargets="ComputeRunArguments">
    <PropertyGroup>
      <RunCommand>dotnet</RunCommand>
      <RunArguments>exec --depsfile ./ClassLibraryLambdaFunction.deps.json --runtimeconfig ./ClassLibraryLambdaFunction.runtimeconfig.json ../../../../AspireExtensions/LambdaHost/Amazon.Lambda.RuntimeSupport.dll ClassLibraryLambdaFunction::ClassLibraryLambdaFunction.Function::FunctionHandler</RunArguments>
      <RunWorkingDirectory>$(OutDir)</RunWorkingDirectory>
    </PropertyGroup>
  </Target>	

and it works when I run the AppHost from the commandline outside of the IDE. But when I run it from the IDE I get the following error complaining about the project being a class library.

fail: Aspire.Hosting.Dcp.dcpctrl.ExecutableReconciler[0]
      run session could not be started: IDE returned a response indicating failure      {"Executable": {"name":"ToLowerLambdaFunction-ccvsfwhd"}, "Reconciliation": 2, "Status": "500 Internal Server Error", "Body": "A project with an Output Type of Class Library cannot be started directly.\r\n\r\nIn order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project."}

If there is a way to get the RunCommand and RunArguments be honored via launching in Visual Studio and the project is attached to the debugger that would give me a great working path. The launchsettings.json path isn't not the right long term solution for us.

[normj]

@tlmii Were you able to try by POC and reproduce the problem? Let me know if I need to create a simpler repo case.