Why is OpenStudio.dll no longer included in the installers?

[chriswmackey]

Enhancement Request

I'm opening this as an enhancement request but it may be more of a question and I just have not found the right answer yet. Starting from OpenStudio 3.5, it seems that there is no longer an OpenStudio.dll included in the Windows exe installer and the only way that I have currently found to obtain this .dll is from the OpenStudio NuGet package.

This seemed odd to me because all of the other csharp dlls are in the installer but I am missing the critical one that I need in order to be able to make use of the CSharp bindings.

So I first wanted to ask if this is the intended setup and I am just not understanding how I am now supposed to be making use of the CSharp bindings (eg. should I be adding a different one of these dlls instead of the OpenStudio.dll that I have historically used?) If it is the intended setup, could you instruct me on which dll should be added to enable me to import OpenStudio SDK in .NET. Or do I need to add all of them?

If this is not the intended setup, it would be really nice if future OpenStudio installers could put back the OpenStudio.dll somewhere in the installation folder. I have verified that the latest OpenStudio 3.6.1 installer also lacks the OpenStudio.dll

Thanks, as always.
CC: @jmarrec , @MingboPeng

[jmarrec]

@chriswmackey I think you may be reporting the same issue as

• openstudiolib.dll not found without C++ API installation #4897

The openstudiolib.dll isn't installed if the C++ API is unchecked during installation of 3.6.0 and 3.6.1, which means the CLI can't be used. Not sure if this is the intended behavior now but it's different than previous versions.

Is this what you are reporting? (Basically I'm asking if you can try with the C++ API component selected). If so, can close this issue, fixed in:

• Fix #4897 - openstudiolib.dll/libopenstudiolib.so not found without C++ API Component selected in IFW #4900

[chriswmackey]

Thanks @jmarrec ,

I believe that my issue is different because I see the openstuidolib.dll in the installation folder and this is fine.

My issue is that this is what I get with the OpenStudio NuGet package:

But this is what I get from the OpenStudio installer released here through GitHub whenever I check the boxes for all of the options.

Here's the bin folder:

Here's the CSharp folder:

Neither of those folders has the OpenStudio.dll that comes with the NuGet package. Am I correct that there's no way to get the OpenStudio.dll that's distributed on NuGet with the installer that is distributed here on GitHub?

[jmarrec]

Got it. Thanks.

I do see OpenStudio.dll being built correctly on CI. But indeed it's not installed. 99% sure this is due to the CONFIGURATIONS DEBUG part of this line, apparently it's @MingboPeng that last touched it. Do you happen to recall why you added "CONFIGURATIONS DEBUG" here?

OpenStudio/csharp/CMakeLists.txt

Line 68 in 82304dc

install(FILES "${OPENSTUDIO_CSHARP_DLL}" DESTINATION CSharp/openstudio/ CONFIGURATIONS DEBUG COMPONENT "CSharpAPI")

git blame: https://github.com/NREL/OpenStudio/blame/82304dcc76303e8a4c49c87500dc64ffe65248f5/csharp/CMakeLists.txt#L68

[jmarrec]

Actually I'm pretty sure I see why that has happened. This is a left over from refactoring: 84f36ac#diff-eb198a8407cb15ec84351a8a476aa8b60112377c0b12be331baa2874ea20c786L79

[MingboPeng]

Ops, I thought there was a post-process to copy all files into the installer folder.

I didn't realize this CMakeLists also creates the installer. @jmarrec thanks for helping.
Let me add the new OpenStudio.dll to the installer.
"${CSHARP_LIBRARY_OUTPUT_DIRECTORY}/${CMAKE_BUILD_TYPE}/netstandard2.0/OpenStudio.dll"

[jmarrec]

I'm fixing it right now @MingboPeng

[MingboPeng]

Thanks!

[jmarrec]

#4933 (review)

I replaced the CMAKE_BUILD_TYPE with a genex too. This was working on CI because we do pass explicitly cmake -DCMAKE_BUILD_TYPE:STRING=Release when building on MSVC. But MSVC by default is Multi-configuration and CMAKE_BUILD_TYPE is empty if used like this.

[chriswmackey]

Thanks for getting to the bottom of this, @jmarrec and @MingboPeng . I'm looking forward to having this back in the next installer release.