mhutch
Feature Request: "Reference Search" and "Search in all imported MSBuild files"
Hi,
MSBuild logic is often hard to follow, especially as it's distributed over so many different files, which can come from many different locations (VS, MSBuild, SDKs, nuget packages, etc.).
I often end up searching for variables and item groups in all props and targets files in those folders, which in turn gives many results from files that aren't even imported in the project. That would be so much more useful than anything that the extension does (according to the feature description, haven't installed yet).
I'm wondering whether there's already a way to do this, which I'm just not aware of? How are others doing it?
As it seems that this extension is reading and parsing all imported MSBuild files, it is probably very close already to allow a "Find in all imported MSBuild files" feature? Something like "Find all references" like for code would be awesome, but a find in MSBuild files feature would already suffice.
Thanks, sw
Yup, thanks, I'm using that of course. It's very useful for analyzing builds,
But it still doesn't allow searching through all the imported MSBuild files in a project.
For example, just from today: I am extending the build for a certain project type and want to find out how to get my additional output files cleaned during the Clean target. Now I see from the log viewer that there's an item group named "@(Clean)", and I want to find out how (or rather at which point) the files in this group get populated. I couldn't find any earlier target where this happens - so back to searching through MSBuild files, but how to constrain that search to only those which are used in the project?`
Thanks
You need to right-click the project you're interested in (or its evaluation), and click Preprocess - this will display a flat XML of all imported files inlined in traversal order, then just search that flat text for <YourItemName.
or, you can use the search syntax: $additem YourItemName project(MyProjectName.csproj) will find all places where the item was added under that specific project
You need to right-click the project you're interested in (or its evaluation), and click Preprocess
Don't see that:
It's a binlog from VS, though, maybe that's why it's missing.
Yes, confirmed, I see it when building from the viewer app.
Does the preprocess result include all imported files or only the parts that were used in the build.
Alright, my mistake was to open and use the logs from within Visual Studio. Those are actually lacking all the things I'm interested in. I was already wondering why there weren't several property lists visible like last time I had used it (a while ago - was building from the viewer directly).
The "preprocessed" file is VERY useful. Thanks a lot for pointing me at this. Nice application btw - well done!
A search through imported MSBuild files in VS directly would still be useful, don't you think? Otherwise we can close this as well..
Yes, binlogs from VS suck: https://msbuildlog.com/#MSBUILDDEBUGENGINE
Ideally build from command line using msbuild /bl
Preprocess only includes the files actually imported, and it stitches them together in the right order. When moving the caret in the preprocessed text, pay attention to the yellow breadcrumb bar at the bottom, it will show the chain of imports from the top-level down. You can click on any import to navigate to it. You can also search for whether a file was imported or not imported in a given project by searching for $import or $noimport.
The problem with the VS extension (this repo) is it doesn't know the exact set of imported projects, so it's only guessing. It does guess pretty accurately most of the time, so it does have a list of targets and imported projects that could be searched for. However VS extensibility isn't great here, so I'm not sure whether it's feasible to introduce a new search scope that is the imported projects.
I'd recommend using the binlog viewer for this as it gives you the 100% accurate information.
Yes, binlogs from VS suck: msbuildlog.com#MSBUILDDEBUGENGINE
I knew this, but I had totally forgotten about it until this conversation. Can you recognize VS sourced binlogs? Maybe it makes sense to show a warning for idiots like me that you don't get the full truth from them. 😜
When moving the caret in the preprocessed text, pay attention to the yellow breadcrumb bar at the bottom, it will show the chain of imports from the top-level down.
Yeah, I've seen it, that's pretty cool!
You can also search for whether a file was imported or not imported in a given project by searching for
$importor$noimport
When you are right in the middle of investigating some complicated issue, then the last thing in the world that wou want to do is learning and dealing with a search syntax - but you're explaining it well in the window, though. 👍
I've seen that there is even a "find in files" tab:
So that's even better than the huge single XML! Does it have the same scope?
The problem with the VS extension (this repo) is it doesn't know the exact set of imported projects, so it's only guessing.
Can't it get the same information like the "Imports" subtree in solution explorer is using? If not, can't it iterate the tree nodes via generic EnvDte APIs?
However VS extensibility isn't great here, so I'm not sure whether it's feasible to introduce a new search scope that is the imported projects.
A minimal way might be to do the search manually and print the results in the output window as its own output type. If I'm not mistaken, there's even some standard functionality which opens a document at a specific line when double-clicking. (if the line in the ouput if formatted like a compiler outputs errors and warnings)
Can you recognize VS sourced binlogs?
I could, this is a good idea.
When you are right in the middle of investigating some complicated issue, then the last thing in the world that wou want to do is learning and dealing with a search syntax
This to me sounds like "when you're in the middle of writing a C# program, you can't be bothered to take the time and learn C# syntax" - if you're working with MSBuild at all, you owe it to yourself to take 15 minutes and learn the basics that will help you be more efficient for the rest of your life
Find in Files tab
Find in Files contains all text files embedded in the binlog, which are all the files read by all the projects in the build. It also includes project.assets.json and there's an option to embed custom files in the binlog (EmbedInBinlog item).
The MSBuild language service doesn't do a build, so it's not recording events such as "project file imported" or "project evaluated". What you're describing is possible in an IDE that's not Visual Studio.
It's not impossible, but it's not easy and I doubt we have time for this. Especially since the information is readily available in the binlog.
This to me sounds like "when you're in the middle of writing a C# program, you can't be bothered to take the time and learn C# syntax" - if you're working with MSBuild at all, you owe it to yourself to take 15 minutes and learn the basics that will help you be more efficient for the rest of your life
The search syntax in a tool is something different from the MSBuild "language" itself. Regarding the C# analogon: I really know C# syntax in-and-out, but I don't know how to build RegEx expression that you can use in the VS search feature. I mean - I could have learned it, I just never did because I don't like it :-)
Find in Files tab
Find in Files contains all text files embedded in the binlog, which are all the files read by all the projects in the build. It also includes project.assets.json and there's an option to embed custom files in the binlog (EmbedInBinlog item).
Good to know, thanks for the clarification.
The MSBuild language service doesn't do a build, so it's not recording events such as "project file imported" or "project evaluated". What you're describing is possible in an IDE that's not Visual Studio.
But what I'm describing is about Visual Studio - specifically, the Imports tree:
Wouldn't the MSBuild language service be able to access that tree, instead of trying to "guess" about the imports?
ah, OK, yes, that would be possible in theory. Maybe @drewnoakes will have appetite for it one day