-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generated WorkerExtensions.csproj project is restored at build time #1864
Comments
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 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: #1888 |
Closing this as we will track the official workaround in #1888 |
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.
The text was updated successfully, but these errors were encountered: