Add managed build client - #884
Conversation
|
Also, this pull request includes the commit from #866, so that PR should be merged first. |
There was a problem hiding this comment.
Are you missing an argument to match the {0} ?
|
Note, you should ignore the first commit for review purposes, as well, since it's in #866. This should significantly reduce the review size. |
1ff6149 to
11daace
Compare
|
👍 |
11daace to
00acdb9
Compare
|
Could I get one more sign off here? |
|
@VladimirReshetnikov I think I've addressed your feedback -- unfortunately it seems Github doesn't want to update the comments for the new diffs. |
There was a problem hiding this comment.
AFAIK, Dispose() does not call ReleaseMutex(). Should ReleaseMutex() be within a finally block?
There was a problem hiding this comment.
Yeah, I mistakenly thought dispose releases the mutex. This should be in a finally block.
Re-adds the managed client to the build task. Previously the managed client was removed since we wanted to keep the native client around for startup time. However, not spinning up extra processes was a significant perf win and we're now convinced that the native client is unnecessary, so this is the first step in bringing the managed client back.
After reinserting the managed client into the build task, I will delete the native clients and build new csc2/vbc2 executables that perform their same function using the managed client code. When we're confident that works, I will replace the csc2/vbc2 exes with a '/shared' option on the csc/vbc exes and delete csc2/vbc2 entirely (fixing up the tests as appropriate).
Right now the build task references the CodeAnalysis DLL because there are significant helper functions in the assembly which are useful and not easy to extract. If having an independent task is important we should refactor those useful pieces (specifically, some command line argument parsing and C# identifier matching) into linkable pieces.
@jaredpar @AlekseyTs @gafter @VSadov @VladimirReshetnikov @pharring