The Microsoft Office team approached the C++ team after seeing the Visual Studio announcement for support for debugging applications running on C++ from Windows through the Blizzard blog post. They had a need for a similar workflow, but for Macs instead of Linux. The C++ team worked closely with the Office engineers to adapt the same underlying technology for Mac.  

The following blog post is written in conjunction with Anthony Penniston, an Office engineer we worked closely with to deliver this capability. Thank you, Anthony, for working with us!

What does this team do?

Anthony’s team in Office works on delivering core productivity verticals such as document storage and syncing, collaboration, predictive intelligence, authentication, and single sign on. Due to the nature of working on Microsoft Office, the team is very much cross-platform oriented in the products they deliver and feels a lot of unique pains.

Specifically, since Office delivers scalable, robust, responsive, and cross-platform products, the team must build their products natively in C++, using several different compilers and build systems, while still operating on the same unified codebase. As a result, every change they make typically affects the same product on multiple platforms.

How does this team accomplish their work?

Before working with the C++ team on a remote debugging solution for Mac, Office engineers looking to investigate Apple-specific behavior really faced some challenges. They had to either attempt to guess the behavior from source code and logs or acquire a Mac system and learn how to use XCode to debug the behavior natively. Additionally, investigating platform-specific behavior ended up compounding in difficulty because much of the team primarily has expertise and experience in Windows. Neither of these workflows were practical for ad-hoc investigations by the engineers. As a result, a lot of investigations ended up being often delayed and Apple-specific issues were resolved by less-than-ideal workarounds and through many iterations of trial-and-error guesswork. This was by far an unproductive way to move forward in their work. For many Windows engineers who may only briefly need to investigate one-off issues for Apple-specific behavior, being able to use the familiar Windows tooling is a huge benefit and timesaver.

The team really wanted to stay developing in Visual Studio for all their needs because it has the reputation as an industry-standard and industry-leading tool for developing and debugging C++ applications on Windows. Visual Studio helps them make sense of their codebase and quickly turn around questions into answers and ideas into implementation through features they use like IntelliSense, code browsing and navigation, and auto-completion. Since the Microsoft Office organization primarily develops on Windows, alongside several other platforms, it takes a great deal of investment to build proficiency in any tool ecosystem. Being able to reuse the skills they’ve built with their Windows tooling and apply that across platforms is incredibly valuable to the engineers. So, when Anthony saw that the C++ team developed functionality to allow users to debug Linux from the comfort of Visual Studio, he was super excited to reach out to the team and learn more about how this functionality could possibly be adapted for Mac.

Adopting the Mac targeting support

Once Anthony contacted the C++ team with his request, the C++ engineers were able to engage and collaborate with the Office team to produce a prototype that would fit his needs for remote Mac development in Visual Studio. This was done pretty rapidly and within a few weeks. Since the C++ team was able to move quickly on this request, by the time a one-week hackathon was over, they had that they were able to demo to the Office team and raise awareness of this new product effort. At the demo, they were able to attract a lot of other Office engineers to this idea and these engineers were keen on seeing more, so over the course of the year, the C++ team continued to collaborate with the Office team to further refine the experience into the out-of-box remote debugging functionality for LLDB in Visual Studio 2022 present today, which not only met all of the team’s technical requirements, and addressed all the feedback given, but was also easy to onboard engineers unfamiliar with the workflow.

We spoke to Anthony after this experience, and he stated: “End-to-end it was an engaging and energizing experience to see an ambitious idea turned into reality.“ Also, Anthony pointed out that “[what stood out to me the most was] the engagement, responsiveness, and attention to user feedback of the VS team to improve and iterate on the design. The VS team had the polished feature ready-to-go in VS 2022 with all our asks in place and checked in with us to make sure our use cases were covered and our path to adoption was smooth and unblocked”

This concept not only improved their specific workflow but will also improve others’. This Office engineering team had some initial apprehension towards cross-platform development on Mac, specifically worries about encountering Mac-specific failures or behaviors, as this meant either investigation through guesswork or a considerable time investment into setting up a Mac system and learning the toolset, for what is often a one-off investigation. However, now, with VS 2022’s remote debugging capability for Mac, combined with being able to easily provision Mac systems in Office, the engineering team feels empowered to take on platform-specific investigations using the VS toolchain that they are already familiar and comfortable with.

Conclusion:

A special thanks to Erika Sweet, Paul Maybee, Sinem Akinci, Ion Todirel, and the rest of the Visual Studio C++ team who, over the course of a several months to a year, helped make the Office team’s cross-platform ideal workflow a reality. The Office team left with an overwhelmingly positive experience and hopes for more collaboration in the future (and looking forward to soon leveraging this same VS technology to debug Mac core dumps on Windows).