Tracker.exe and FileTracker32.dll source?

[tamaynard]

          There were a variety of factors that went into deciding to release as we did.
          - Previously, MSBuild was built as a sub-component of Visual Studio, and it had been relocated several times (though several source control systems!) over its lifecycle. Extracting just the subfolder would have been difficult, and older versions would not have built.
          - Internally, the release of Visual Studio 2015 corresponded with a clean break between Team Foundation Version Control and Git, so this repo has roughly the same amount of history as we have access to in the internal Git repo.
          - We did not release all of the code that makes up MSBuild internally. There are many deprecated or uninteresting components that we wanted to remain private, and excising them from one point-in-time release was easy.
          - We also held back some components for licensing reasons: `tracker.exe` and `FileTracker.dll` use the [Detours](http://research.microsoft.com/en-us/projects/detours/) library, which is distributed as source but licensed commercially. To maintain license compliance, we kept that code internal.
          - Legal and policy reasons created incentives to release less source.

Originally posted by @rainersigwald in #621 (comment)

Now that Detours is MIT licensed, is there a chance that the source for Tracker.exe and FileTracker32/64.dll could be released, perhaps? I filed a ticket in the VS Developer Community portal a few months ago regarding an issue with build steps that emit output using the CreateFile2 API not being tracked, causing constant rebuilds. After a quick review of Detours, I feel that I should be able to submit a patch for the issue myself, if given the opportunity. Given the niche case I'm trying to cover I understand that it may not be a priority over higher-priority issues, which is why I am proposing a review on your end of the decision to release the source for these components. Assuming there are no further licensing issues (I have no reason to believe there would be, given the functionality of those components can be primarily implemented using only Detours), I see no reason why the msbuid team would not want to take advantage of the open-source ecosystem to assist in maintenance of these modules. Any thoughts or comments from anyone else?

[JanKrivanek]

Thank you @tamaynard for the report and for the offer to contribute.
Coincidentaly the issue was discussed last week and scheduled for fixing. In general we are not allowed to give any promisses neither dates. But this specific issue (CreateFile2 not being intercepted) should hopefuly be resolved soon.

There has been vague plans on replacing our Tracker with Detours - this however currently doesn't meet the bar. Neither does the OSS-ing of the existing code. Those discussions are reocurring regularly though.

[tamaynard]

Thank you for the prompt response @JanKrivanek. It's reassuring to know that the original issue is being addressed. I understand licensing is not the only consideration when releasing source; I know I have code I wouldn't rather see the light of day for various reasons (niche, "ugly", build issues, deprecated dependencies, etc.). If the issue is being addressed then releasing the code at this time is indeed a moot point, therefore I'll close this issue for now.

[swallerick]

I'm just leaving this here to say that I too would appreciate being able to look through the Tracker.exe source code. I'm working on a parser and instrumentation tool, and incremental rebuilds are not working as expected only with the Visual Studio generator, and it would be nice to see some of the internals to help develop a workaround for my issue.