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.

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

Allow MSBuildWorkspace to output a binary log #42319

Merged

Conversation

jmarolf
Copy link
Contributor

@jmarolf jmarolf commented Mar 10, 2020

THIS ADDS A NEW API!!!!

In the course of human events, it sometimes becomes necessary to get a binlog in order to understand what has gone wrong.
Tools like dotnet-format (or anything using MSBuildWorkspace) are unable to get a binlog today.

  • Moves the msbuild dependencies from 15.1 -> 15.3 (the release BinaryLogger was added)
  • Add a new api to allow Solution/Project load to output a binary log

Copy link
Member

@JoeRobich JoeRobich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems pretty straightforward.

src/Workspaces/Core/MSBuild/MSBuild/MSBuildWorkspace.cs Outdated Show resolved Hide resolved
@JoeRobich
Copy link
Member

@jasonmalinowski Any thoughts about adding a binary logging options to MSBuildWorkspace?

Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As called out, this needs better API to either specify the log path, or (my preference) just let you pass the ILoggers directly so they can choose any number of logging formats with appropriate logging levels, etc.

@jmarolf
Copy link
Contributor Author

jmarolf commented Mar 16, 2020

Updated this PR to let you pass in a logger during project or solution load mirroring the way the api works for progress reporting

I still kept the version of MSBuild at 15.3 because its unclear to me what our back-compat story is here. Famously the csc task does not work with older versions of MSBuild. It seems like we may be guiding users down the wrong path by not taking dependencies on newer versions of MSBuild if that allows them to get into a state where the msbuild they use (and therefore the compiler) is older than the language features they may want to use.

@jmarolf jmarolf force-pushed the feature/ouput-binary-log-for-msbuildworkspace branch from 59a3938 to 02bed3a Compare March 16, 2020 17:54
@jmarolf jmarolf dismissed jasonmalinowski’s stale review March 17, 2020 10:35

updated PR with suggested changes

Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It appears this is missing a back-compat method since adding new parameter is a breaking change.

Copy link
Contributor

@RikkiGibson RikkiGibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish I could approve a PR just on the basis of the PR description making me laugh

@jmarolf jmarolf dismissed jasonmalinowski’s stale review March 23, 2020 20:50

made requested changes

@jmarolf jmarolf force-pushed the feature/ouput-binary-log-for-msbuildworkspace branch from 203938d to 20c6a60 Compare March 23, 2020 23:33
@jmarolf
Copy link
Contributor Author

jmarolf commented Mar 26, 2020

alright @jasonmalinowski can you take a look at this when you get the chance?

@jmarolf
Copy link
Contributor Author

jmarolf commented Mar 30, 2020

@jasonmalinowski I have the horrifying ability to merge this at any time. Please stop me.

@cartermp
Copy link
Contributor

So do I

Copy link
Member

@JoeRobich JoeRobich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think maybe some cut and paste errors got in

jmarolf and others added 5 commits March 30, 2020 19:42
…r_ResolveReferences.cs

Co-Authored-By: Joey Robichaud <joseph.robichaud@microsoft.com>
…r_ResolveReferences.cs

Co-Authored-By: Joey Robichaud <joseph.robichaud@microsoft.com>
…r_ResolveReferences.cs

Co-Authored-By: Joey Robichaud <joseph.robichaud@microsoft.com>
…r_ResolveReferences.cs

Co-Authored-By: Joey Robichaud <joseph.robichaud@microsoft.com>
@jmarolf jmarolf requested a review from JoeRobich March 31, 2020 14:33
Copy link
Member

@JoeRobich JoeRobich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Just had one question

@@ -39,6 +39,7 @@ indent_size = 2
[*.{cs,vb}]
# Sort using and Import directives with System.* appearing first
dotnet_sort_system_directives_first = true
dotnet_separate_import_directive_groups = false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missed this earlier, is it intentional?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I get yelled at if I add spaces to the usings so this is an implicit style that wasn't captured in the editorcofig. I see no place where separators in usings exist for roslyn

@jmarolf jmarolf merged commit 6f01902 into dotnet:master Mar 31, 2020
@jmarolf jmarolf deleted the feature/ouput-binary-log-for-msbuildworkspace branch March 31, 2020 17:43
@ghost ghost added this to the Next milestone Mar 31, 2020
Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jmarolf for the work! Sorry I had a review started last night and functionally this all looks great...

@@ -186,7 +192,7 @@ public void EndBatchBuild()
MSB.Execution.BuildManager.DefaultBuildManager.EndBuild();

// unload project so collection will release global strings
_batchBuildProjectCollection.UnloadAllProjects();
_batchBuildProjectCollection?.UnloadAllProjects();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why a ?. here? It feels like a Contract.ThrowIfNull() is more appropriate because we shouldn't have been able to get here without a build already going, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I agree. I'll create a mop up PR


In reply to: 401259147 [](ancestors = 401259147)

private static async Task<(MSB.Evaluation.Project project, DiagnosticLog log)> LoadProjectAsync(
string path, MSB.Evaluation.ProjectCollection projectCollection, CancellationToken cancellationToken)
private static async Task<(MSB.Evaluation.Project? project, DiagnosticLog log)> LoadProjectAsync(
string path, MSB.Evaluation.ProjectCollection? projectCollection, CancellationToken cancellationToken)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When could projectCollection ever be null?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its nulled out and re-allocated at the start of each Start/End build. so it can easily be null if things are ever called slightly out of order. How does roslyn typically handle complex lifetimes like this that the compiler can't track? I was inclined to say that if your object has a complex lifetime beyond some kind of Initialize method then it should be considered nullable. Happy to refactor this so the lifetime isn't so complex though.


In reply to: 401260471 [](ancestors = 401260471)

@@ -153,7 +158,7 @@ private DiagnosticReportingMode GetReportingModeForUnrecognizedProjects()
if (!_pathResolver.TryGetAbsoluteSolutionPath(solutionFilePath, baseDirectory: Directory.GetCurrentDirectory(), DiagnosticReportingMode.Throw, out var absoluteSolutionPath))
{
// TryGetAbsoluteSolutionPath should throw before we get here.
return null;
return null!;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wat.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

¯_(ツ)_/¯


In reply to: 401261909 [](ancestors = 401261909)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants