Skip to content

feat(bau): add msbuild support #68

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

Draft
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

PowerUser64
Copy link

@PowerUser64 PowerUser64 commented Feb 19, 2025

I've written this integration with compiler.nvim for MSBuild to ease the pain of having to use MSBuild on windows. I've based this work on @Gaweringo's work that adds windows support in #58, because MSBuild only runs on windows. I can change this and/or rebase pretty easily if needed, since I just have one commit here.

This integration provides the following functionality

  • execute Build, Run, Clean, and sequentially Build and Run targets for msbuild projects
  • supports multiple project files (.sln) in the same directory (this jkhappens sometimes)
  • auto detects build configurations (debug, release) based on the contents of each .sln file
    • currently, release configurations are removed from the list (if there are others), since compiler seems to prefer to present only one type of build configuration in other cases (eg. plain .cpp file only has one build type). I can remove this behavior if this isn't the case, although it makes the menu a bit messier to use.

Also of note is that msbuild provides LOTS of default targets for each project (there are 438 in one project I have), so I'm only scratching the surface by including the build, run, and clean targets. There are others (like Rebuild), that could potentially be useful too, but so far I've only added these ones so far to bring parity with the default C/C++ configuration. I could add others if it'd be welcome.

The only thing this requires is that msbuild.exe be accessible through the user's PATH, which it isn't the case by default on windows. It'd be possible (and likely not very hard) to make some basic logic to find the executable on the filesystem with globing (more about this on SO), but it somewhat feels like stepping outside the scope of this plugin since it adds some potential for variability. I can write some documentation on the wiki to explain this PATH stuff if needed.

I'm marking this as a draft for now since #58 is unmerged and I have code from it. Also, I'd like to use this for a bit longer before it gets merged (maybe two weeks from now at most). There could be a bit more tweaking to do with the default list of targets.

Thank you to @Gaweringo for all your work on adding windows support to begin with! I might not have attempted this if it weren't for that.

@PowerUser64
Copy link
Author

I should also note, I haven't written much lua code before, so there's a chance I made some rookie mistakes or wrote things in a way that could be improved. Please don't be afraid to say so if this is the case anywhere!

@thedeany
Copy link

@PowerUser64 I've pinned your repo in my config to test this out, but I'm not having much luck. I have a solution with upwards of 70 .csproj projects in it. When I open Compiler and choose to build, it reports

MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.

I was hoping it would build the project in which the current file resides. Is this what should be happening? Or do I need to specify the project somehow? I've tried running the build command with a .csproj as the active buffer as well to no avail.

Any help would be appreciated. Thanks for all your work on this!

@PowerUser64
Copy link
Author

PowerUser64 commented Apr 17, 2025

Thanks for testing this out! I have not tested this with projects that are quite that large, so I don't think I can solve this on my own. Although, it probably wouldn't be too difficult since you have an environment for it.

It sounds like you need to add some code that can detect which csproj project you want to compile, which you can do somewhere in here (the file should be at ~/AppData/Local/nvim-data/lazy/compiler.nvim/lua/compiler/utils-bau.lua, assuming you're on windows and using lazy.nvim as your plugin manager). This is the code that builds the msbuild command.

All you would need to do is add a way for compiler to get the csproj you want and provide it as an argument to msbuild. The basic command it generates right now is MSBuild.exe -t:Build -p:Configuration=Debug (with some variance depending on whether you run, build+run, clean, etc.). You would need to add a way to specify what csproj file should be used.

It might be necessary to generate compile commands for the entire list of csproj files accessible through the .sln and make entries for each of them in the compiler menu. I work mostly with smaller vcxproj projects rather than csproj so I can only offer limited help on this one.

If you find something that works though, feel free to make a PR to the msbuild-init branch on my fork of compiler.nvim and maybe we can get it merged here too! At least, we'll increase neovim's support for M$'s dev tooling another 1%. It's very poorly supported with nvim from what I've found, so anything helps.

In fact, if you use anything that helps you work with msbuild (or related ms tools), I would love to know, since I feel like I'm one of the only ones on the planet interested in doing this, and you're the only other one I've heard of trying to do this 😂. Personally, I've started using overseer.nvim in my config a bit, without going through compiler in some cases (compiler.nvim is a wrapper for overseer in a lot of ways), which has helped me gain some more control over it.

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

Successfully merging this pull request may close these issues.

3 participants