Support the "release" configuration when using dotnet

[MitchellGerdisch]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

In the CLI with the dotnet sdk, when running pulumi up or another command, a dotnet build command is executed.
It’s always being built in debug mode (the default configuration).
It would be preferred to be able to run the dotnet build with the release configuration.

Affected area/feature

[AaronFriel]

I would expect debug (or rather, default!) builds to be faster, and as Pulumi is rarely limited by the performance of the language executed, this might be an anti-pattern.

Were we to implement this, I'd recommend we benchmark using some of our large SDKs. My prior is that this would make deployments substantially slower with azure-native.

[SineLung]

Hello, in my case providing support for the release configuration would be helpful in two aspects

• If the #if DEBUG directive is present in our codebase, running Pulumi CLI will cause unexpected behaviors when doing a new deployment on the production environment, as I would expect the release configuration to be used for compilation and not the debug one. It doesn't feel right to give up on those directives just because the Pulumi CLI doesn't support release configuration.
• If in the code we are referencing specific binaries in the Release folder, they will not get updated as expected during the execution of dotnet build by the Pulumi CLI and we might reference an outdated version of them. For instance, one way to deploy Azure Functions is to upload its binaries with the FileAsset class. I don't want to manually build in release mode from Visual Studio every time before running Pulumi CLI.
  We are currently taking the files in the Debug folder but it would have been preferable to take it in the Release folder as the compilation is more optimized.

Bonus : Code compiled in release mode runs faster than debug mode as the compiler makes a lot of optimizations

[Frassle]

It’s always being built in debug mode (the default configuration).

Specifically it builds in the default configuration because we just don't pass any /c option.

It would be preferred to be able to run the dotnet build with the release configuration.

I'm fine with adding an option for this. Most sensible place I think would be the runtime options so you could write in your Pulumi.yaml:

runtime:
  name: dotnet
  options:
    configuration: Release

And we would simply pass the value given there to the /configuration flag of msbuild.

[AaronFriel]

Hi @SineLung - have you measured this? Our .NET SDKs can be quite large, and any steps to optimize the program can actually make Pulumi much slower.

We find that the most time consuming steps of the execution time of Pulumi programs are:

1. Downloading and installing dependencies (nuget for .NET, or setting up a venv, npm install, etc.)
2. Building or setting up the runtime
3. Provider execution time - that is, the time the Pulumi Engine and Provider plugins (pre-compiled) spend running, or typically, waiting for cloud service API calls to complete.

If these factors are removed, the language and whether it's compiled or interpreted, optimized or not, rarely make a difference. In fact, compiled languages can take much longer to start (step 2) in some circumstances.

If in the code we are referencing specific binaries in the Release folder, they will not get updated as expected during the execution of dotnet build by the Pulumi CLI and we might reference an outdated version of them. For instance, one way to deploy Azure Functions is to upload its binaries with the FileAsset class. I don't want to manually build in release mode from Visual Studio every time before running Pulumi CLI.

@Frassle should weigh in here, as I don't think I understand this. If you're building binaries manually, I don't think Pulumi is using them, that's not part of the deployment method that Pulumi expects.

[AaronFriel]

I would go a step further - if we could run .NET programs directly without a build step (dotnet run --no-build), that might be even faster. @Frassle do we support that?

[SineLung]

It’s always being built in debug mode (the default configuration).

Specifically it builds in the default configuration because we just don't pass any /c option.

It would be preferred to be able to run the dotnet build with the release configuration.

I'm fine with adding an option for this. Most sensible place I think would be the runtime options so you could write in your Pulumi.yaml:

runtime:
  name: dotnet
  options:
    configuration: Release

And we would simply pass the value given there to the /configuration flag of msbuild.

It would be perfect to have that option here !

Hi @SineLung - have you measured this? Our .NET SDKs can be quite large, and any steps to optimize the program can actually make Pulumi much slower.

For one of our Pulumi projects, a full rebuild in debug mode took 15 seconds.
In release mode it took 9.9 seconds.

[Frassle]

I would go a step further - if we could run .NET programs directly without a build step (dotnet run --no-build), that might be even faster. @Frassle do we support that?

Not directly like that, but we do support the "binary" option to tell the plugin to directly run an executable rather than working through project files. You could use that to ensure you always ran the release binary but it would then be on the user to remember to rebuild when needed.