DEV Community


Posted on

How To Build Visual Studio Projects From Within WSL

I dislike Visual Studio. I dislike IDEs. I dislike being forced to do things in any given way. That much is obvious.

This is why I've been rolling with vim since 2011, when I was working as an iOS Developer out of my bedroom. I spent a week getting good at the keybindings and shortcuts, and tricking out my editor via .vimrc. My professor who signed my diploma used to nag about my choice in college to work in nano, but I did not know back then that you could re-map the default vim navigation keys, "j k l ;", to "a s d f", as I am left-handed, and my initial repulsion to vim was due to my right-hand deformity and not being able to mentally (and literally) "wrap" my head and hand around the default key bindings.

Anything to avoid Xcode. I even got my iOS projects building via the Xcode toolchain in bash and vim back then.

So, flash forward to 2020. I'm finally working on my own game project. I'm live-streaming to I've got it building and running in both Windows and MacOS. But, I was dual-wielding vim and Visual Studio, bouncing from my WSL to VS, and back-and-forth, lots of alt-tabbing over time.

This one troll from EFnet who goes by the name "oct0pus" is always harrassing me, but actually brought up a good point during one of my recent streams. He said something like:

"Why haven't you configured your project to build from within vim?"

I didn't have an answer at the time, but now I do:

I did not realize that I could, or how I could do it!

I realize that Visual Studio project files are likely the base config that gets passed to the build process, and all I had to do was google around to find the name of that executable.

I stumble upon the name "MSBuild.exe" and realize it is the answer to my problems.

I ask an odd question to myself: "Can I run .exe files in WSL?". I think it is a fair one. It IS supposed to be a Linux environment, after all, but it somehow also allows one to run Windows executable binaries. I guess this makes sense. I don't really know much about how the WSL integrates with Windows, or how the environments are shared yet, but that is the topic of future exploration.

So, after adding the following line to my .bashrc and .bash_profile:

export PATH=$PATH:/mnt/c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio/2019/Community/MSBuild/Current/Bin/ 

and verifying that I can, in fact, build my project so long as I am in the project root folder, by typing:


I then add the following to my .vimrc:

command -bar Build call Build()
function Build()
    execute "!MSBuild.exe"

command -bar Clean call Clean()
function Clean()
    execute "!MSBuild.exe -t:clean"

command -bar Run call Run()
function Run()
    execute "!Debug/Project1.exe"

This creates 3 new functions that you can execute in Command mode from within vim.


In my case, my executable is "Project1.exe".

So, there you have it. I am now able to build projects completely outside of Visual Studio and completely inside of vim. No more IDE for me if I don't want it!

And that feel of liberation is worth more than anything imaginable.

To me, anyway.

The freedom to build in the way that you want to build.

To exist in the way that you choose, not the way that others force upon you.

Considering the recommendation came from someone that I largely consider an Internet bully, I have to honestly say "thanks" to oct0pus for the recommendation. I had to do some initial research to get the setup working, but his comment stuck in the back of my mind more than any of the harassing insults he has thrown at me over the last several years. Normally I am able to ignore baseless criticism and dumb chatter, but when someone is right, they are right.

Here's what that setup looks like:

Honorable mention:

Shoutouts to chz2chz for recommending I stop manually-calculating the size of structs using defines:

#define SIZEOF_MYSTRUCT (sizeof(int) + sizeof(char) + /* etc */ )

and start trusting the results of using sizeof() on a struct itself:


Get $100 For A Virtual Private Server from Vultr:

Discussion (0)