Azure / azure-functions-dotnet-worker

Azure Functions out-of-process .NET language worker
MIT License
412 stars 173 forks source link

Generated WorkerExtensions.csproj project is restored at build time #1864

Closed dfederm closed 12 months ago

dfederm commented 1 year ago

In many CI scenarios, in particular ones internal to Microsoft, the network is disabled via firewall during the "build" phase of a build and only allow network access (and only in a very restrictive way) during the "restore" phase. This helps secure the build supply chain.

Because WorkerExtensions.csproj is generated on demand and is restored as part of the build of the parent project, this breaks this requirement and these project types are effectively unusable by many Microsoft-internal teams.

Please ensure all activity that required network access happens during "restore".

PS. You shouldn't ever need to dynamically produce a project and then build it. You should be able to do all the necessary work within the parent project. Reach out offline if you need help with this.

jviau commented 12 months ago

This is a known drawback of our SDK, unfortunately it is unavoidable. We have already worked with the NuGet, dotnet, and MSBuild team to brainstorm ways to avoid this inner build, but there is no way around it. The issue is our design mandates a 2 stage restore. Extensions have 2 packages really, the worker package - which you reference in your csproj. And the host/webjobs package, which is explicitly NOT part of your projects restore graph, instead it is discovered post-restore from the first worker package you referenced. This leaves us with a 2 stage restore: we must first restore the worker packages, then scan them to discover and restore the webjobs packages. Additionally, this scanning can only happen as part of the build target and not during the restore target (for multiple reasons, but primarily we rely on reference assembly resolution).

The recommended workaround today is to add a dummy project to your solution which contains the webjobs packages and restore that ahead of time, so when the inner-build restore occurs it will discover the locally cached packages and not reach out to the network.

One of the outcomes of the sync with MSbuild/dotnet/NuGet teams was the idea for a tool to help. I opened an issue here: https://github.com/Azure/azure-functions-dotnet-worker/issues/1888

jviau commented 12 months ago

Closing this as we will track the official workaround in #1888