Roslyn: Build fails due to VSIX extensions. Access to user path denied.

[TobiasBreuer]

Used version:
Current master branch (forked but in synch).

Steps to Reproduce:

1. Fork, Clone, Branch (Standard Workflow)
2. In root folder, execute the commands like described at here
3. See this result:
   

These errors also occur when trying to build the Solution in VisualStudio itself.
I used VS2015 Update 2 and Extensibility Tools installed on Windows 10.
The build configuration in VS when opening the Roslyn solution is per default Debug and Mixed platforms
When this also failed, I ran the Clean command within VS to rebuild but than I had about 40000+ IntelliSense errors and the 4 - 5 build errors regarding the VSIX packages as seen above remained to occur.
I checked the folder path given in the error message and verified that it doesn't require any privileged rights. Running the build as admin also doesn't solve the issue.

Expected Behavior:
Succesful build on initial checkout.

Actual Behavior:
Unable to build.

[DavidArno]

I too am observing this problem with Vs2015 Update 2.

It occurs on Windows 7 and 10.
The cache file in question is definitely write accessible.
This occurs both in VS and on the cmd line.
Even tried a build straight after a reboot in case something was locking the file, but it still fails.

The work around I found was to navigate to each project that failed in turn, eg ..\roslyn\src\VisualStudio\Setup and to build the project in isolation: msbuild /v:m /m VisualStudioSetup.csproj. This is likely only really a practical solution if only a couple of VSIX's fail to build and you aren't repeatedly rebuilding whilst testing a change.

[Pilchie]

This is a bug in the VSSDK tasks/targets. It's been fixed, and there is a newer version in their NuGet, but we don't consume that yet :frowning:.

[bkoelman]

I've also run into this (Update2 on Win81), while building from the command line.
Build succeeded after removing the /m switch (multiple cores).

msbuild /v:m Roslyn.sln

But then on building within VS, they showed up again. The fix was to disable parallel build in VS by setting number of concurrent builds to 1 (see https://msdn.microsoft.com/en-us/library/y0xettzf(v=vs.90).aspx).

Hope that helps!

[DavidArno]

@bkoelman,

Unfortunately, that work-around doesn't work for me.

[TobiasBreuer]

@bkoelman:
In my case this is a valid workaround. Even though its now (obviously) really slow, the build now succeeds from within VisualStudio after changing the number of concurrent builds to 1. Thanks for the hint 👍

[Azarien]

Doesn't work, /m or not /m.

This project is unbuildable as of now.

[jasonmalinowski]

Just a status update on this so everyone is on the same page: there's a fix available in a NuGet package, but we can't just easily move to that since that will break some other things @Pilchie is also working on. We're still figuring out a good solution here.

[jasonmalinowski]

This _should_ be fixed now since the bug was fixed in the NuGet package. Sync to latest in _master_ and you should see this working. The fix will be in _future_ hopefully by tomorrow.

[DavidArno]

@jasonmalinowski

What about the feature branches?

[jmarolf]

@DavidArno we merge changes from master into future daily. Changes should be in sometime in the next 12 hours

[jasonmalinowski]

@DavidArno: for compiler feature branches, those are "owned" by whoever is working on that feature. @jaredpar could generally coordinate, or if you have a specific branch that's causing a headache then file a bug here and we can focus on that one.

[DavidArno]

@jasonmalinowski,
The branch I've been using is features/patterns, which I think is "owned" by @gafter. Hopefully he'll apply the fix there soon...