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.

Sign up for GitHub

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

Jump to bottom

MSBuild race to write portable assembly attributes file #10116

Closed
jaredpar opened this issue Mar 25, 2016 · 4 comments · Fixed by #15905
Closed

MSBuild race to write portable assembly attributes file #10116

jaredpar opened this issue Mar 25, 2016 · 4 comments · Fixed by #15905
Assignees
@jaredpar
Labels
Area-Infrastructure
Milestone
2.0 (RC.3)

Comments

@jaredpar
Copy link
Member

Many of our builds are failing with the following:

error MSB3491:  Could not write lines to file "d:\j\workspace\roslyn_master---e026a511\Binaries\Temp\.NETPortable,Version=v5.0.AssemblyAttributes.cs". 
The process cannot access the file 'd:\j\workspace\roslyn_master---e026a511\Binaries\Temp\.NETPortable,Version=v5.0.AssemblyAttributes.cs' because it is being used by another process. 
[d:\j\workspace\roslyn_master---e026a511\src\Tools\Source\CompilerGeneratorTools\Source\CSharpErrorFactsGenerator\CSharpErrorFactsGenerator.csproj] ->      
6>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(2992,5):

This is a race condition in MSBuild writing out the temporary files which was previously won't fixed. This is causing build breaks as we are promoting this to an error. For now leaving this as a warning that we ignore.

Root cause: http://vstfdevdiv:8080/DevDiv2/DevDiv/_workItems?id=403105&_a=edit
@davkean davkean mentioned this issue Mar 26, 2016
Closed
@jasonmalinowski
Copy link
Member

@jaredpar Do we need a bug over on MSBuild for this?

@jaredpar
Copy link
Member Author

jaredpar commented Dec 8, 2016

@jasonmalinowski has this come up again recently?

@jasonmalinowski
Copy link
Member

@jaredpar No, just digging through ancient infrastructure bugs.

@jaredpar
Copy link
Member Author

jaredpar commented Dec 8, 2016

CC @rainersigwald

I'm having trouble tracking down where this behavior comes from. I dug through the MSBuild source and couldn't find anything relevant. It happens as a part of the portable targets in this specific bug so it's possible it's there.

Either way there should be a safe way of doing this (safe as in no warning).

jaredpar added a commit to jaredpar/roslyn that referenced this issue Dec 14, 2016
@jaredpar
Fix race condition writing assembly attribute file
228355b 
MSBuild generates the TargetFrameworkAttribute file to the same path on
disk for equivalent combinations of TargetFrameworkIdentifier and
TargetProfile.  This means if two projects in a solution have equivalent
identifiers, their builds will race to write the same file to disk.

This is safe by virtue that the content of the file is the same in both
cases.  Hence it doesn't really matter who wins the race, both projects
see the same output.

This is frustrating though because even though it's safe, MSBuild still
isssue a warning when it happens.  This breaks our desire to have
warning free builds.

To fix this we will instead generate the file to the Obj\ProjectName
directory.  This means every project gets their own indepnedent copy of
the file, eliminating the race.

closes dotnet#10116
@jaredpar jaredpar mentioned this issue Dec 14, 2016
Merged
@jaredpar jaredpar added this to the 2.0 (RC.3) milestone Dec 14, 2016
@jaredpar jaredpar self-assigned this Dec 14, 2016
@jeffkl jeffkl mentioned this issue Dec 14, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jaredpar jaredpar

Labels
Area-Infrastructure
Projects
None yet
Milestone
2.0 (RC.3)
Development

Successfully merging a pull request may close this issue.

Fix race condition writing assembly attribute file jaredpar/roslyn
2 participants
@jaredpar @jasonmalinowski