- Data viewer tool diablosport install#
- Data viewer tool diablosport software#
- Data viewer tool diablosport code#
When a server crashes in our infrastructure an automated process notifies us and the core file is archived to a network share. The Linux executable is only deployed in a container and the developers normally don’t have access to it. The Linux build is generated on a build farm that uses a build system on a Linux box to build the server, and its container that gets deployed. However, we deploy our servers on Linux, which requires a build generated on Linux itself. This is useful for normal feature development.
Data viewer tool diablosport code#
We develop our code on Windows and have a Windows version of our servers that can run under Windows.
Let me provide a little background about our build. If you are building with CMake, then you can also leverage Visual Studio’s native support for WSL.) This is a much better solution than running a VM, or even a container. It’s incredibly convenient to hop into WSL, cd into the shared code directory, and build right from there. (As a brief side topic, I want to emphasize that we have found WSL to be the best available Linux environment for developers to test their changes in a Linux build. We run a script I wrote that also installs all the development tools and support libraries needed to build our server within WSL.
Data viewer tool diablosport install#
All our server developers install WSL, using the distribution we deploy on. The Visual Studio Linux core debug workflow is enabled only if you install WSL or add a Linux connection to the Connection Manager. That’s why we are so excited to be able to utilize the new Visual Studio feature that lets us do just that in the familiar environment of Visual Studio! It really is not an exaggeration to say that this is a dream come true. We have always wanted a more intuitive approach for debugging our Linux cores. Since only 2 or 3 of our developers have much proficiency with gdb, they become the de-facto resource for diagnosing production crashes, and that’s not optimal. Putting it simply, our developers would much rather use familiar tools to debug. For one, we don’t deploy source with our binaries, so source is not available in a gdb session on a VM or container.Īnother hurdle is gdb itself: unless you use gdb on a very regular basis, you don’t retain a level of proficiency with it that makes it convenient for our use. But there are numerous disadvantages to this. There is the option to remote login to the VM (or more specifically the container) that crashed and run gdb to diagnose the crash there. However, this presents us with some challenges when a deployed server crashes and we want to debug the resulting core dump. There is nothing quite comparable in the Linux world, even if we were to develop natively in Linux. The other, and most important reason that we develop on Windows is the functionality and robust toolset provided by Visual Studio. Even our server programmers are most familiar with Windows development, and we appreciate the ability for all the programmers on our team to use a common toolset and knowledge base. For one, our team’s core competency is on Windows. There are multiple reasons for this workflow. (The code includes conditional compilation and custom platform-specific code where necessary). This includes our servers, which run on Linux. On Diablo IV we develop all our code on Windows and compile for multiple platforms.
Data viewer tool diablosport software#
The following blog post is written by Bill Randolph, a Senior Software Engineer at Blizzard working on the development of Diablo IV. Blizzard is using Visual Studio 2019 to debug Linux core dumps on WSL.
0 kommentar(er)
