Migration from packages.config to PackageReferences causes Could not load file or assembly "..." or one of its dependencies. Access is denied

Viewed 1268

After upgrading our projects to PackageReferences I am facing the following issue on the build server (on-premise AzureDevOps agents)

"C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Xaml.targets(193,5): 
Error XC1000: XC1020: Build error occurred in the XAML MSBuild task: 
'Could not load file or assembly 'file:///C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\Facades\System.Threading.ThreadPool.dll'
 or one of its dependencies. Access is denied.'"

This happens randomly(50% of the time) for different Dlls. Those dlls are in different directories : Nuget restore directory, Reference Assemblies or any other code dll.

On the server, we are using VS 2017.

Now the thing is this started happening when I migrated the project to PackageReferences. We never had any issues with Access Denied before that. And this is exactly the same code base with the same build infrastructure.

What I tried to do :

  • I tried to check with the process monitor but there is no "access denied" entry there. I could see that it was read correctly
  • Just to be safe I installed the agent on my local machine to see if it's not the build machine problem, and it did happen there as well
  • This does not happen when we build locally with MSBuild nor visual studio

Any ideas would be appreciated. At least to point to the direction of the solution.

[Update]

We actually had 3 whole days w/o the issue happening on the server and now it's back.

We also "managed" to get it once while building locally with msbuild(PS script). From the look of that local build and the next one ( passing one triggered right after), we managed to see that nuget was downloading packages that were successfully downloaded in the previous(failed) build. We do not observe that behaviour with consecutive passing builds. Nuget does not download new packages each time unless cleaned.

[Update2] Debug log file for Nuget restore step and build step.

gdrive

Thanks

M

1 Answers

I would suggest running Procmon on the build agents. This will give you a full audit of all filesystem and registry activity during that time. So start it up on the agents, do a couple of builds on them to reproduce the issue, then pause procmon and look at the logs. Filter down by process, file or path to narrow in on your issue. This should give you a much clearer answer on what is happening and the answer will either present itself or it should be very easy to figure out from here.

Related