Results 1 to 4 of 4

Thread: Debugging .Net Server API Mods

  1. #1
    Survivor djkrose's Avatar
    Join Date
    Apr 2014
    Posts
    61
    Rep Power
    1

    Debugging .Net Server API Mods

    Hey Moddaaars!

    I figured out how to make real live debugging of mods in Unity 5.3 games (like 7DTD) possible.



    /** Credit: This wouldn't have been possible without the work of olizit, who wrote the original tutorial and custom mono.dll for RimWorld, and who also was helpful via email. Thank you! **/

    Installation with Visual Studio 2017

    1. Install 7DTD Dedicated Server locally on Windows.
      (Debugging should also work remotely, but you have to hassle with ports, ip's, firewalls, etc. You can figure this out later yourself.)

    2. Install Visual Studio 2017 with the "Game development with Unity" workload

    3. Replace the game's <7dtdt server directory>\7DaysToDieServer_Data\Mono\mono.dll with this modified mono.dll:


    4. Set this environment variable with this command in a batch file.

      Code:
      set MONO_MOD_DEBUG=--debugger-agent=transport=dt_socket,address=127.0.0.1:56000,server=y,defer=y
      You can put it in your startdedicated.bat file or define the variable globally in Start -> System -> Advanced System Settings -> Tab Advanced -> Environment Variables. See this tutorial for details. You need to restart VS and the 7DTD server to apply the changes!

    5. Copy your mod and all dependencies in Mods folder.

    6. Open mod solution file with Visual Studio

    7. You need to create a Mono debug symbol file (.mdb), because the normal .Net debug symbol file (.pdb) doesn't work for Mono. You can use the pdb2mdb tool:

      Add this pdb2mdb NuGet package to your project. Alternatively, you can download and install Mono, which has the tool in <Mono_install_path>\bin\pdb2mdb.bat.

      Set your project to build in debug mode. Debug info must be enabled (default).

      Option A - Use post build event:

      Open Project settings and add this post build event:
      Code:
      ..\packages\Mono.pdb2mdb.0.1.0.20130128\tools\pdb2mdb.exe "$(TargetPath)"
      Adjust the tool path accordingly if you are using the full Mono installation.

      Option B - Use MSBuild scripting:

      If you know a bit about MSBuild scripting, you can embed the pdb2mdb tool in your build script (.csproj). This is what I have added:
      Code:
        <!-- Create Mono CLR symbol files (.mdb) -->
        <Target Name="GenerateMonoSymbols" AfterTargets="AfterBuild" Condition=" Exists('$(OutputPath)\$(AssemblyName).pdb') ">
          <PropertyGroup>
            <MonoMdbGenerator>$(SolutionDir)packages\Mono.pdb2mdb.0.1.0.20130128\tools\pdb2mdb.exe</MonoMdbGenerator>
          </PropertyGroup>
          <Message Text="$(ProjectName) -&gt; $(TargetPath).mdb" Importance="High" />
          <Exec Command="$(MonoMdbGenerator) $(TargetPath)" WorkingDirectory="$(MSBuildProjectDirectory)\$(OutputPath)" />
        </Target>

      This step converts the .pdb file to a .mdb file. After a sucessfull build your mod assemblies must contains 3 files <name mod>.dll <name mod>.dll.mdb and <name mod>.pdb. Check if these 3 files are there!

    8. Start up the 7DTD server normally on your local machine (where VS is installed).

    9. In Visual Studio click on Debug->Attach Unity Debugger->Input IP
      Enter parameters matching your local address and port as set in the environment variable.
      Click OK

    10. Set some breakpoints and execute mod functionality in game.

    11. Profit!


    Installation with Visual Studio 2015

    I haven't tested this, but reportedly it works as well, but you need the VS2015 Tools for Unity extension. See original tutorial for details.


    Installation with Xamarin Studio (all platforms)

    It should be possible to get debugging going on non-Windows platforms or without Visual Studio, although maybe not as comfortably. Check out the original tutorial about how to install and run Xamarin Studio.


    Troubleshooting

    • Test if your environment variable is set:
      Enter "set" on a command line. One of the variables should be MONO_MOD_DEBUG.

    • Execute on command prompt to test if the game is listening for a debugger on port 56000:
      Code:
      netstat -n -a | find "56000"
      It should print a line with TCP, the ip, port and LISTENING status. Otherwise the game is not ready for debugging. Check the mono.dll and environment variable again.

    • Is the port free? If the above command returns a LISTENING port before you started the game, some other program may be using the port. Try to change to use a different port.

    • Test connection to the game debugger (only if netstat test worked):
      Code:
      telnet 127.0.0.1 56000
      If screen clears, the connection is ready. Try Visual Studio now.
      If "connection timed out" or some other error appears, the game is not listening on that port for a debug session. Check if you mono.dll is replaced and the environment variable is set. If you don't have the telnet command, see: https://technet.microsoft.com/en-us/...(v=ws.10).aspx

    • Check your firewall settings if anything prevents connecting to the ip/port!

    • The game doesn't start or crashes with the modified mono.dll?
      The modified dll is only for Unity 5.3 and only tested with 7 Days to Die version A16.1. Other games may or may not work. If your game doesn't work, there is not much you can do, unless you want to get into modifying and compiling mono.dll yourself.

    • Debugging server startup code
      You can debug you Api constructor or Api.GameAwake calls when you omit the ,defer=y from the Mono environment string. Then the server will upon start immediately go into pause mode and wait for your debugger to connect. You then *must* attach the debugger so that the server continues to start.


    Let me know whether you made it work or if you hit any problems. I'll update the troubleshooting section for common problems.

    .oO( djkrose )Oo.
    Last edited by djkrose; 6 Days Ago at 11:50 AM. Reason: typo.. it's Unity 5.3, not 3.5

  2. #2
    Colony Founder HAL9000's Avatar
    Join Date
    Feb 2014
    Posts
    1,791
    Rep Power
    1
    Well I know how I'll be spending time off ^^

    Great work, this is going to be very handy!

  3. #3
    Survivor djkrose's Avatar
    Join Date
    Apr 2014
    Posts
    61
    Rep Power
    1
    Here are some additional options to use in the --debugger-agent parameter:

    Code:
    Usage: --debugger-agent=[<option>=<value>,...] ...    
    
    Available options:
      transport=<transport>        Transport to use for connecting to the debugger (mandatory, possible values: 'dt_socket')    
      address=<hostname>:<port>    Address to connect to (mandatory)    
      server=<y|n>                 Mandatory for being the debug target
      loglevel=<i>                 Log level (defaults to 0)    
      logfile=<file>               File to log to (defaults to stdout)    
      suspend=<y|n>                Whether to suspend after startup.    
      timeout=<i>                  Timeout for connecting in milliseconds.    
      defer=<y|n>                  Whether to allow deferred client attaching.    
      onuncaught=<y|n>             Break on uncaught exception
      onthrow=<y|n>                Break on thrown exception
    Most importantly, defer=y makes the game start with or without a debugger attached, and you can always attach a debugger later. Even if you don't, it has the benefit that your log file contains nice stack traces with exact source file and line number.

    I don't recommend to set that on production servers, but theoretically you could. -- And since I'm a badass, I have set this on my 16 slot production server. \_(ツ)_/

  4. #4
    Colony Founder StompyNZ's Avatar
    Join Date
    Apr 2015
    Posts
    3,359
    Rep Power
    1
    Thanks for helping getting this working

    will make api mod dev so much easier

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •