Azure Functions Isolated dockerfile using SDK Containers

Azure.Functions.Container.targets

<Project>

    <!-- Targets that replicate the behavior of the azure functions isolated dockerfile using the
    SDK container tech -->

    <Target Name="EnsureValidFunctionsTFM">
        <PropertyGroup>
            <_MinimumSupportedFunctionsTFM>6.0</_MinimumSupportedFunctionsTFM>
            <_MaximumSupportedFunctionsTFM>8.0</_MaximumSupportedFunctionsTFM>
        </PropertyGroup>
        <Error Condition="[MSBuild]::VersionLessThan($(_MinimumSupportedFunctionsTFM), $(TargetFrameworkVersion)) or [MSBuild]::VersionGreaterThan($(_MaximumSupportedFunctionsTFM), $(TargetFrameworkVersion))" 
            Text="The Azure Functions isolated worker supports between net$(_MinimumSupportedFunctionsTFM) and net$(_MaximumSupportedFunctionsTFM) as the target framework." />
    </Target>

    <Target
            Name="AssignFunctionsBaseImage"
            BeforeTargets="ComputeContainerBaseImage"
            DependsOnTargets="EnsureValidFunctionsTFM">
        <!-- We're replicating the data in this dockerfile: https://github.com/Azure/azure-functions-core-tools/blob/8878ab9455b83142f614e27557cf1ee7f1b414a1/src/Azure.Functions.Cli/StaticResources/Dockerfile.dotnetIsolated -->
        <PropertyGroup>
            <FunctionsRuntimeVersion Condition="'$(FunctionsRuntimeVersion)' == ''">4</FunctionsRuntimeVersion>
            <ContainerBaseImage>
                mcr.microsoft.com/azure-functions/dotnet-isolated:$(FunctionsRuntimeVersion)-dotnet-isolated$(_TargetFrameworkVersionWithoutV)</ContainerBaseImage>
            <ContainerWorkingDirectory>/home/site/wwwroot</ContainerWorkingDirectory>
            <!-- Functions only support amd64 runtimes -->
            <ContainerRuntimeIdentifier>linux-x64</ContainerRuntimeIdentifier>
        </PropertyGroup>
        <ItemGroup>
            <ContainerEnvironmentVariable
                    Include="AzureWebJobsScriptRoot"
                    Value="$(ContainerWorkingDirectory)" />
            <ContainerEnvironmentVariable
                    Include="AzureFunctionsJobHost__Logging__Console__IsEnabled"
                    Value="true" />
        </ItemGroup>
        
        <ItemGroup>
            <ContainerAppCommand Include="/opt/startup/start_nonappservice.sh" />
        </ItemGroup>
    </Target>

</Project>

this is is working if you add <ContainerAppCommand Include="/opt/startup/start_nonappservice.sh" /> in line 21 and using dotnet publish --os linux --arch x64 /t:PublishContainer -c Release as publish command

ah, I do see that from the base image. Good catch - though I wonder if this is a gap in the SDK tooling itself (i.e. should we inherit this from the base image?).

"Cmd": [
    "/opt/startup/start_nonappservice.sh"    
]

I assume dotnet publish /t:PublishContainer it sets the images entrypoint to your projects main executable by default - this totally makes sense for api and worker projects.

This does not work for Azure Functions for dotnet-isolated, where the project needs to be started by the Functions host runtime instead. So yep i guess we need a workaround for Functions.

I added your change to the sample so it would be more correct for future readers :)

And to be clear, this kind of extensibility is exactly what I was hoping for when we made these extensibility points in the SDK - sorta like dotnet run, the SDK bakes in some defaults but allows specific use cases to override that behavior!