• 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 [SOLVED] Calling Simconnect.dll from within a DLL

D

Depayns

Messages
11
Country
hongkong
Hi guys,

I am trying to build a DLL that could be used by different clients. This DLL should call functions defined in Simconnect.dll.
Until now I cannot get this working.

If I call my functions directly in a exe, everything goes fine, no problem. However, as soon as I externalize the calls in a DLL I keep getting SIMCONNECT_EXCEPTION.
and more specifically, I get the following one: SIMCONNECT_EXCEPTION_ERROR which is not really documented and thus not very helpful.

So my question is: Is it possible to have a DLL call Simconnect.DLL ? Are there some compiling options one need to set ?

Thanks for any pointers or hints.

Cheers,

-S.
 
Hi,

Yes, it is possible. For example my WASimClient project can be built as a static or dynamic library, or used by simply including/building the code itself as part of another project.

There are probably a number of ways to go about this, and there may certainly be several "gotcha's" which are hard to predict w/out understanding your full project/solution configuration/setup.

You're building your project (the one that uses SimConnect) as a library?

And related, do you mean if you statically link to that library from a client program it works (the lib is built into the exe), but not if linking dynamically?
Or do you mean if you just build the exe including the lib's code directly (not building a library at all)?

Can you post an example of what you've already tried?

Personally I like building my library using the SimConnect static lib -- that way SimConnect.dll isn't required at runtime (it's built into the exe/lib which uses SimConnect). This is somewhat besides the point, but my examples below use this method, so it may vary if linking to SimConnect dynamically.

Note that Ws2_32 and Shlwapi libraries are required for SimConnect to work properly. So either the dynamic versions need to be in the runtime path, or the static versions need to be linked in at build time (as in the examples below).

Here are some possibly-relevant entries for building a DLL from the WASimClient project file. These are specifically for a "Release DLL" configuration I have set up for the project. See above link for the full file.

XML: 
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release-DLL|x64'" Label="Configuration">
    <ConfigurationType>DynamicLibrary</ConfigurationType>
   <!-- etc ...  -->
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release-DLL|x64'">
    <LinkIncremental>false</LinkIncremental>
    <IncludePath>$(ProjectDir);$(MSFS_SDK)\SimConnect SDK\include;$(IncludePath)</IncludePath>
    <LibraryPath>$(MSFS_SDK)\SimConnect SDK\lib\static;$(LibraryPath)</LibraryPath>
    <CopyLocalDeploymentContent>true</CopyLocalDeploymentContent>
    <CopyLocalProjectReference>true</CopyLocalProjectReference>
  </PropertyGroup>


  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release-DLL|x64'">
    <ClCompile>
      <!-- this is all pretty much standard config stuff, not unique to DLL vs. static -->
      <FunctionLevelLinking>true</FunctionLevelLinking>
      <IntrinsicFunctions>true</IntrinsicFunctions>
      <SDLCheck>true</SDLCheck>
      <PreprocessorDefinitions>_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE_DEBUG;_WINDOWS;_USRDLL;NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <ConformanceMode>true</ConformanceMode>
      <PrecompiledHeader>NotUsing</PrecompiledHeader>
      <LanguageStandard>stdcpp17</LanguageStandard>
      <LanguageStandard_C>stdc17</LanguageStandard_C>
      <PrecompiledHeaderFile>
      </PrecompiledHeaderFile>
      <AdditionalOptions>/Zc:__cplusplus %(AdditionalOptions)</AdditionalOptions>
      <CallingConvention>StdCall</CallingConvention>
    </ClCompile>
    <Link>
      <SubSystem>NotSet</SubSystem>  <!-- not "Windows" -->
      <EnableCOMDATFolding>true</EnableCOMDATFolding>
      <OptimizeReferences>true</OptimizeReferences>
      <GenerateDebugInformation>false</GenerateDebugInformation>
      <EnableUAC>false</EnableUAC>
      <AdditionalDependencies>SimConnect.lib;Ws2_32.lib;Shlwapi.lib;%(AdditionalDependencies)</AdditionalDependencies>
    </Link>
  </ItemDefinitionGroup>

  <!-- dllmain is only required for a DLL build -->
  <ItemGroup>
    <ClCompile Include="dllmain.cpp">
      <ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release|x64'">true</ExcludedFromBuild>
      <ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release-DLL|x64'">false</ExcludedFromBuild>
    </ClCompile>
  </ItemGroup>

Cheers,
-Max
 
MaxPaperno said:
Hi,

Yes, it is possible. For example my WASimClient project can be built as a static or dynamic library, or used by simply including/building the code itself as part of another project.

There are probably a number of ways to go about this, and there may certainly be several "gotcha's" which are hard to predict w/out understanding your full project/solution configuration/setup.

You're building your project (the one that uses SimConnect) as a library?

And related, do you mean if you statically link to that library from a client program it works (the lib is built into the exe), but not if linking dynamically?
Or do you mean if you just build the exe including the lib's code directly (not building a library at all)?

Can you post an example of what you've already tried?

Personally I like building my library using the SimConnect static lib -- that way SimConnect.dll isn't required at runtime (it's built into the exe/lib which uses SimConnect). This is somewhat besides the point, but my examples below use this method, so it may vary if linking to SimConnect dynamically.

Note that Ws2_32 and Shlwapi libraries are required for SimConnect to work properly. So either the dynamic versions need to be in the runtime path, or the static versions need to be linked in at build time (as in the examples below).

Here are some possibly-relevant entries for building a DLL from the WASimClient project file. These are specifically for a "Release DLL" configuration I have set up for the project. See above link for the full file.

XML: 
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release-DLL|x64'" Label="Configuration">
    <ConfigurationType>DynamicLibrary</ConfigurationType>
   <!-- etc ...  -->
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release-DLL|x64'">
    <LinkIncremental>false</LinkIncremental>
    <IncludePath>$(ProjectDir);$(MSFS_SDK)\SimConnect SDK\include;$(IncludePath)</IncludePath>
    <LibraryPath>$(MSFS_SDK)\SimConnect SDK\lib\static;$(LibraryPath)</LibraryPath>
    <CopyLocalDeploymentContent>true</CopyLocalDeploymentContent>
    <CopyLocalProjectReference>true</CopyLocalProjectReference>
  </PropertyGroup>


  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release-DLL|x64'">
    <ClCompile>
      <!-- this is all pretty much standard config stuff, not unique to DLL vs. static -->
      <FunctionLevelLinking>true</FunctionLevelLinking>
      <IntrinsicFunctions>true</IntrinsicFunctions>
      <SDLCheck>true</SDLCheck>
      <PreprocessorDefinitions>_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE_DEBUG;_WINDOWS;_USRDLL;NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <ConformanceMode>true</ConformanceMode>
      <PrecompiledHeader>NotUsing</PrecompiledHeader>
      <LanguageStandard>stdcpp17</LanguageStandard>
      <LanguageStandard_C>stdc17</LanguageStandard_C>
      <PrecompiledHeaderFile>
      </PrecompiledHeaderFile>
      <AdditionalOptions>/Zc:__cplusplus %(AdditionalOptions)</AdditionalOptions>
      <CallingConvention>StdCall</CallingConvention>
    </ClCompile>
    <Link>
      <SubSystem>NotSet</SubSystem>  <!-- not "Windows" -->
      <EnableCOMDATFolding>true</EnableCOMDATFolding>
      <OptimizeReferences>true</OptimizeReferences>
      <GenerateDebugInformation>false</GenerateDebugInformation>
      <EnableUAC>false</EnableUAC>
      <AdditionalDependencies>SimConnect.lib;Ws2_32.lib;Shlwapi.lib;%(AdditionalDependencies)</AdditionalDependencies>
    </Link>
  </ItemDefinitionGroup>

  <!-- dllmain is only required for a DLL build -->
  <ItemGroup>
    <ClCompile Include="dllmain.cpp">
      <ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release|x64'">true</ExcludedFromBuild>
      <ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release-DLL|x64'">false</ExcludedFromBuild>
    </ClCompile>
  </ItemGroup>

Cheers,
-Max
Click to expand...
Thank you Max for that.

I want actually to use dynamic libraries (but might go for the static route). I will fiddle around with those various options.

just build the exe including the lib's code directly (not building a library at all)?
Click to expand...
Yes, if I include the lib's code in the exe, it works flawleslly, just outsourcing the code in a lib causes the SIMCONNECT_EXCEPTION

Thanks anyways for the above. I will try to figure out what is wrong. FYI I wrote everything in C (C++ when needed) and since I am just a hobbyist coder I might have done things wrong !

Cheers
 
And replying to myself.
Problem solved.

Issue was in Visual Studio where I had turned on some obfuscated options... Starting on a clean slate and having all DLL dynamically linked works now as expected !
 
If that was Visual Studio 2019, I suspect that you may not have been guilty of 'turning things on'. As of the date on this post, the very latest update for VS2019 nuked the debugger for vb.net, C# and C++. Adding a breakpoint caused a CTD in VS and also produced a few very odd compile errors. Removing VS2019 and reinstalling as the latest single package fixed that.

I'd also be a bit careful if you are using Visual Studio 2022. As of about four months ago, it was still unstable (Google 'VS2022 unstable'). I removed it and went back to VS2019 because it wouldn't even compile some of the P3D SDK samples.
 
You must log in or register to reply here.
Back
Top