• 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.

SimConnect.dll Versions


While trying to solve a problem between SimConnect and an application (ADE) I found that I have two types of SimConnect.dll, and that for RTM, SP1 and SP2.

- The first resides in Windows\WinSxS (the SP2/X-Pack):
name: "SimConnect.dll"
Version: 10.0.61637.0 (FSX-Xpack.20070926-1421)
size: 44.5 KB

- the second resides in ..\FSX\SDK\Core Utilities\SimConnect SDK\Lib\managed:
name: "Microsoft.FlightSimulator.SimConnect.dll"
version: 10.0.61637.0 (FSX-Xpack.20070926-1421)
size: 106 KB

The Versions are identical, the names slightly different and the sizes very different.

Which type is used for what??

many thanks

The version in the SxS folder are the ones that will be used when FSX is running, the other one is the one that should be referenced if you want to use SimConnect in a C# project.

The dependency manifest you include in your executable or dll determines which client DLL is loaded from the side by side folder. In C# this will be done automatically for you by the managed simconnect assembly you reference in your project. In C++, the simconnect.h header file will do this for you via a #pragma directive.

This allows you to have multiple client DLL versions installed on the same client computer.

The server however doesn't like a newer DLL version, so for example, running the new simconnect for ESP as the client against an FSX server will cause the FSX server to generate invalid version exceptions the moment you try to register a definition. However, the FSX SP2 client works fine with ESP, the FSX RTM client works fine against any version of FSX. It seems the client DLL must be lower or the same as the server, but not a version ahead.

If you want to target a specific version of FSX (or ESP), there are devilish ways to eliminate the manifest and load the proper DLL at runtime, which is addressed in other posts here.


Last edited:


Staff member
FSDevConf team
Resource contributor
Well that explains very well why we stick with the RTM version of SimConnect in ADE. Mind you I could not have explained that even Iif I already knew the answer :)
so if you are developing in C++ on a PC with Acceleration installed, but not exploiting capabilities unique to that platform, can you force the compilation to target the RTM simconnect dll by editting the simconnect.h ?

I *think* I'm discovering that the simconnect programs I'm writing (C++) on my PC have unwittingly become Acceleration only, which is not what I intended *at all*.

We had a discussion on here recently where I think Pete Dowson pointed out that the SP2 and Acceleration SimConnect.dlls are identical.

Anyway, I'm developing using Acceleration SDK and my code runs fine on FSX SP2 systems. So I don't believe it should be possible to create an Accleration only add-on. (Unless it references the EH-101, Mustang or F-18 gauge components.)

ah that makes sense - there are just 3 simconnect dll's - rtm, sp1 & sp2.

I guess it's ok just requiring the sp2 dll although this will exclude rtm/sp1 users. The embarrassing fact is I didn't know that installing SP2 myself would force users of my software onto that release...


bevor I get the tag of being bad mannered, I want to thank you all for your replies to my original question.

I am pleased, that this thread around a "simple" question turned into a fruitful exchange of knowhow among experts, with me looking on!

Please carry on!


There are legacy versions of the SimConnect interfaces installed with the later versions of the SDK so you can target any version you want (see "Core Utilities Kit\SimConnect SDK\LegacyInterfaces"). Each of the Legacy subdirs has a managed DLL you can reference for managed addons, .h/.lib files for C++ addons, and a .msi file to install that version of SimConnect on a remote client.
On the subject, I wanted to add:

a) you can detect what simconnect client is installed (or not), by scanning the WinSxS folder and look for simclient folder names.

The folder name in the side by side looks like this in XP or Vista:


Microsoft.FlightSimulator.SimConnect = the string to look for.

10.0.61259.0 = the version to look for.

Strings to look for:

Microsoft.ESP.SimConnect - for ESP
Microsoft.FlightSimulator.SimConnect - for FSX (all versions)

Versions to look for: - ESP RTM
10.0.61259.0 - FSX SP2 or Acceleration
10.0.60905.0 - FSX RTM

b) Specifying which version to use by your client


When you include the simconnect.h file, it has a #pragma comment(lib, "") directive that points to a particular version of simconnect.

The directive in simconnect.h to reference SimConnect RTM is this:

#pragma comment(linker,"/manifestdependency:\"type='win32' " \
    "name='" "Microsoft.FlightSimulator.SimConnect " "' " \
    "version='" "10.0.60905.0" "' " \
    "processorArchitecture='x86' " \
    "publicKeyToken='" "67c7c14424d61b5b" "'\"")

For SP2:

#pragma comment(linker,"/manifestdependency:\"type='win32' " \
    "name='" "Microsoft.FlightSimulator.SimConnect" "' " \
    "version='" "10.0.61259.0" "' " \
    "processorArchitecture='x86' " \
    "publicKeyToken='" "67c7c14424d61b5b" "'\"")

In C++, you can disable this reference by defining the SIMCONNECT_H_NOMANIFEST compiler symbol


before including the simconnect header file. This will require you to add it yourself to the manifest.

You can remove or change that in two ways:
b.1 - modify the simconnect.h header to the version you want, so you point to the right lib file

b.2 - provide a manual manifest that will tell the loader to use the right side by side assembly when your .DLL or .EXE loads.

In Visual Studio 2005, you have to use the MT.EXE tool in the VC/BIN folder to do this (that tool is also part of the Windows SDK).

In Visual Studio 2008, you add a manifest reference directly to your project (you can also use MT.EXE but it is not distributed with VS2008).


The interop DLL assembly provided by ACES that you reference in your .NET project makes that reference for you. There are few options here outside of writing your own interop assembly and link it to the native simconnect.lib (been there, get ready for very interesting marshalling problems given that most simconnect structures are in fact unions with variable length). You can also use the MT tool if needed to change that, but that would mean your interop DLL will likely not work because the library will not match up.

c) Another way to detect what a client has installed:
Create two dummy DLLs, one referencing RTM SimConnect, the other SP2 SimConnect in their respective manifest. Use LoadLibrary() from your code (.NET or C++) to load the library. It will fail is the corresponding version of SimConnect is not found on the client. The returned handle (C++) or IntPtr (.NET) is 0, the GetLastError will tell you usually error 2, "file not found".

What does a manifest look like?

Here's an example for a C++ dll in VS 2008:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      <assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
      <assemblyIdentity type="win32" name="Microsoft.FlightSimulator.SimConnect" version="10.0.61259.0" processorArchitecture="x86" publicKeyToken="67c7c14424d61b5b"></assemblyIdentity>

The first dependency looks for the shared runtime library version 9 (VS2008), the second looks for Simconnect SP2.

By incorporating a manifest in your file (either during linking or using the MT tool), you can control what version of Simconnect you compile against.

What creates the manifest incorporated in my file?

The manifest is usually automatically generated based on the include files (#pragma), linked libraries or assemblies at link time. Additional dependencies can be added in the project as well in VS2008. The linker looks through all the dependencies and generates the manifest resource for you. You can also modify it and manually add your own lines. There are tools (MGEN) you can also use for this, but you will not need this. In most cases, let the linker do this for you.

How is the manifest incorporated in my file?

The linker does this for you, and inserts a special resource entry in your DLL or RES. The O/S loader looks for this special entry and takes over from there, before you even get to run your entry point routine.

A few quirks with manifests: I found that using LoadLibrary() or LoadLibraryEx() will not work if you are referencing the same assembly in the manifest AND a separate standalone DLL. If you get a dll load error, look to your manifest first.

How do I know if my file will load and the computer is configured with the right client?

A handy troubleshooting utility to use is DependencyWalker (www.dependencywalker.com), which loads your gauge or DLL and looks at the entire manifest tree. Anything missing will pop up there.

If you get an error, your file won't load. A side by side is missing, or if not in side by side, a dll is missing in your application's folder or the search path.

If you get a warning and the dependency has an hourglass next to it, it's an optional dependency (delay loaded) that you probably don't need, but will be used if present by something you referenced somewhere. Vista and XP have different load delay dlls you will see.

One gotcha: If you load dlls manually via the windows API LoadLibrary calls, for example, to specify a folder where the dll you need is located, it will blow up during the load if the same library is in the side by side folder. This is by design. In this case, you will have no errors in dependency walker, but a big problem at runtime.

The tool is amazing to find out why your stuff doesn't load on a client, and will ensure your side by side configuration is also correct.

From code, look for the WinSxS contents and see what's installed there.

Hope this helps,

Last edited: