SimConnect.dll Versions

Hello!

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

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

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

Cheers,

Etienne
 
Last edited:

scruffyduck

Administrator
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*.

B21
 
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.)

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

B21
 
Hello

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!

yours

Helli
 
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:

x86_Microsoft.FlightSimulator.SimConnect_67c7c14424d61b5b_10.0.61259.0_x-ww_fb842f5a

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:

1.0.20.0 - 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

C/C++

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:

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

Code:
#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

Code:
#define SIMCONNECT_H_NOMANIFEST
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).

C# / VB.NET

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:

Code:
<?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">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.FlightSimulator.SimConnect" version="10.0.61259.0" processorArchitecture="x86" publicKeyToken="67c7c14424d61b5b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>
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,

Etienne
 
Last edited:
Top