• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS20 Workflow with external EXE or DLL modules on MSFS202x

H

HornetJockey

Messages
47
Country
us-newyork
Hi everyone,

I need to work on an external EXE module (not WASM, for now, for various reasons) that is loaded through EXE.XML (as described in this post on MSFS DEV Forum). So far I have the exe loading no problem, and everything is working, but I find the workflow extremely cumbersome. Every time I make a change and recompile, I need to restart MSFS.

I tried “edit and continue” in the Debug mode, but as soon as I “Attach to process” and attach to MSFS in the debugger, I get an exception saying one of the PDBs is missing (I can supply the exact message).

Is there a better workflow for this? Can I “edit and continue” reliably, as the sim is running? I am accustomed to WASM in-sim development, which reloads the module real time without the need to re-start the sim, and the debugger actually works.

Thanks in advance for any bit of info you may have.
 
You can't just run your exe without the exe.xml overhead? The way I see it, the exe.xml is to start ancillary apps like Little NavMap and head tracker software and that's not how I do it, I don't even have to pause the sim when I am testing my SimConnect exe's, I just write another version, remember to close the previous, build it run it evaluate it rinse and repeat.
About the only pita is that I do my flying on my main monitor and run Visual Studio on the second and every time I open the exe I have to slide the console over, bummer. I could probably write a script for that.
 
Hi,

Maybe I misunderstand, but isn't the "auto launch" setup in the XML just a convenience to avoid having to launch related app(s) separately when starting the sim? In other words, can't you just (re)start your EXE "manually" whenever you want? Including in a debugger.

That's how I've always worked with external SimConnect clients, anyway.

I remember I set up some auto-launch thing at one point, then forgot about it of course and had to figure out later what was going on with my setup.... 😅

Cheers,
-Max

PS.
HornetJockey said:
attach to MSFS in the debugger
Click to expand...
You'd attach debugger to your application, not MSFS.
 
Last edited:
Ok guys, thanks for this!! A little wet behind the ears here :D I was under impression that the ONLY way to run EXE module is through EXE.xml.

This is exactly what I was hoping for - a workflow. So basically, just close/open your exe from wherever folder it was built in?
 
HornetJockey said:
So basically, just close/open your exe from wherever folder it was built in?
Click to expand...
Yep! Or run it from your IDE... or in the debugger. It could even run on a separate PC (with the appropriate network setup).

With WASM, I "Debug/Attach to Process/" and find MSFS in the list of processes...
Click to expand...
Right, since the WASM modules run inside the sim process itself. The external clients are completely separate and only interface to the sim via SimConnect network messages, so they can start/stop at any time.
 
=rk= said:
About the only pita is that I do my flying on my main monitor and run Visual Studio on the second and every time I open the exe I have to slide the console over, bummer. I could probably write a script for that.
Click to expand...
Hey do you mean the console window that opens when you run an app from within VS? If so... you can actually go into the settings for that console window and save its position!

Do you know where I mean...? On any "Command Prompt" window you can open the "title bar context menu" (or whatever it's called) with a click on the icon in the top left. Or ALT+SPACE when the window is focused. There's a Properties menu item in there that most windows don't have. Properties -> Layout -> Window Position -> uncheck "Let system position window".

So if you do that on VS's popup console it should remember which monitor you want it on next time.

Always drove me nuts too 'cuz it would pop up on top of the editor... so if ya wanna go back to editor and still see the console, gotta move it.
 
Thanks! I always love anachronistic things. I mean, why would Microsoft, known for publishing a software called Windows, give it's developers windows with memory, when they can just go ahead and program them into position along with everything else they do! I'm pretty sure I remember "resizable windows," being the standout feature of the first version.

A similar thing happens every time I resize MSFS, or try to stretch it across two monitors and my thought is always, "windows? No? So just boxy little graphics suggesting a view to the world outside my cubicle then."
 
=rk= said:
I always love anachronistic things.
Click to expand...

LOL, yea well, you'd think with the zillion other settings they stuff in VS, "remember position of Run's console window" could be squeezed in (heck maybe it is, somewhere). But it wouldn't be as much fun if one didn't have to rummage through dusty Windows-1-era attics to find what one needs.

I mean we're discussing programming for MSFS, right? If one doesn't have a certain masochistic streak then they shouldn't be here.... 🤣
 
fsdeveloper.com

Debugging WASM gauges How-To

The instructions for debugging WASM gauges in the SDK is... somewhat lacking in completeness. They imply (actually, pretty much state) that once you have attached the debugger to MSFS you do not need to disconnect it for that session. This is not so. If you don't disconnect it, you will never...
fsdeveloper.com fsdeveloper.com
 
You must log in or register to reply here.
Back
Top