Skip to content
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

Closed
dfederm opened this issue Aug 25, 2023 · 2 comments
Closed

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

dfederm opened this issue Aug 25, 2023 · 2 comments

Comments

@dfederm
Copy link

dfederm commented Aug 25, 2023

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
Copy link
Contributor

jviau commented Sep 6, 2023

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: #1888

@jviau
Copy link
Contributor

jviau commented Sep 6, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants