Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SWIG C# fixes + dotnet support #3960

Merged
merged 54 commits into from Jun 2, 2020
Merged

SWIG C# fixes + dotnet support #3960

merged 54 commits into from Jun 2, 2020

Conversation

jmarrec
Copy link
Collaborator

@jmarrec jmarrec commented Apr 28, 2020

Pull request overview

This includes #3959 which are generally SWIG improvements for C#, and also adds dotnet support so one can build the C# bindings on Unix for eg.

Status:

  • Can build C# just fine on windows and Ubuntu
  • Can generate the nuget package on Ubuntu, I have trouble making it copy the DLLs to the build output folder of a c# project that adds it as a PackageReference
  • (When resolved the DLL location situation manually) I can use the C# bindings in another netcoreapp3.0 csproj
  • Added C# unit tests via xUnit, as a proof of concept.

Pull Request Author

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

  • Model API Changes / Additions
  • Any new or modified fields have been implemented in the EnergyPlus ForwardTranslator (and ReverseTranslator as appropriate)
  • Model API methods are tested (in src/model/test)
  • EnergyPlus ForwardTranslator Tests (in src/energyplus/Test)
  • If a new object or method, added a test in NREL/OpenStudio-resources: Add Link
  • If needed, added VersionTranslation rules for the objects (src/osversion/VersionTranslator.cpp)
  • Checked behavior in OpenStudioApplication, adjusted policies as needed (src/openstudio_lib/library/OpenStudioPolicy.xml)
  • Verified that C# bindings built fine on Windows, partial classes used as needed, etc.
  • All new and existing tests passes
  • If methods have been deprecated, update rest of code to use the new methods

Labels:

  • If change to an IDD file, add the label IDDChange
  • If breaking existing API, add the label APIChange
  • If deemed ready, add label Pull Request - Ready for CI so that CI builds your PR

Review Checklist

This will not be exhaustively relevant to every PR.

  • Perform a Code Review on GitHub
  • Code Style, strip trailing whitespace, etc.
  • All related changes have been implemented: model changes, model tests, FT changes, FT tests, VersionTranslation, OS App
  • Labeling is ok
  • If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
  • If feature, test running new feature, try creative ways to break it
  • CI status: all green or justified

macumber and others added 30 commits July 13, 2018 11:07
Updating master for 2.9.0 release
cwstring.i is only implemented for python and tcl really.
Swig isn't happy if you do two typedef/templates for the same stuff (std::pair<std::string, std::string> here)
…e hiding inherited

````
Severity	Code	Description	Project	File	Line	Suppression State
Warning	CS0108	'MasslessOpaqueMaterial.iddObjectType()' hides inherited member 'ModelObject.iddObjectType()'. Use the new keyword if hiding was intended. [D:\OpenStudio\build-vs\csharp_wrapper\OpenStudio.csproj]	csharp_sdk	D:\OpenStudio\build-vs\csharp\generated_sources\OpenStudioModelResources\MasslessOpaqueMaterial.cs	81	
```
Copy link
Collaborator Author

@jmarrec jmarrec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait for #3960 to go in first.

Comment on lines 17 to 22
<file src="@OPENSTUDIO_CSHARP_DLLNAME@" target="lib" /> <!-- TODO: target should be lib\{framework}, eg `lib\netcoreapp3.0` -->
<file src="@OPENSTUDIO_CSHARP_LIBNAME@" target="build" /> <!-- target to 'build' is probably not right either -->
<file src="@OPENSTUDIO_MODEL_CSHARP_LIBNAME@" target="build" />
<file src="@OPENSTUDIO_TRANSLATORS_CSHARP_LIBNAME@" target="build" />
<file src="@OPENSTUDIO_MODEL_CSHARP_LIBNAME@" target="build" /> <!-- TODO why is this repeated? -->
<file src="@PROJECT_SOURCE_DIR@/csharp/OpenStudio.targets" target="build" /> <!-- To copy native binaries -->
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openstudio_model_csharp.dll is added twice?

Comment on lines 22 to 26
<Copy SourceFiles="@(NativeBinary)"
DestinationFiles="@(NativeBinary->'$(OutDir)\%(TargetPath)\%(Filename).so')"
Condition="'%(Extension)'=='.so'">
<Output TaskParameter="DestinationFiles" ItemName="FileWrites" />
</Copy>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try support for *.so files on Unix.

set(CSHARP_VERSION_PATCH ${PROJECT_VERSION_PATCH_DIGIT})
set(CSHARP_VERSION_BUILD 0)

if (CMAKE_SIZEOF_VOID_P EQUAL 8)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://cmake.org/cmake/help/latest/variable/CMAKE_CL_64.html

Discouraged. Use CMAKE_SIZEOF_VOID_P instead.
Set to a true value when using a Microsoft Visual Studio cl compiler that targets a 64-bit architecture.

Comment on lines +119 to +122
# TODO: there are probably adjustments to make to OpenStudio.csproj_dotnet.in
# The Release/Debug can be stripped probably
# Also probably don't need to use multiple `<TargetFrameworks>` which is the reason there's an extra netcoreapp3.0/ level
set(OPENSTUDIO_CSHARP_DLL "${CSHARP_LIBRARY_OUTPUT_DIRECTORY}/${CMAKE_BUILD_TYPE}/netcoreapp3.0/OpenStudio.dll")
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure what to do there.

install(TARGETS openstudio_csharp DESTINATION CSharp/openstudio/ CONFIGURATIONS RELEASE COMPONENT "CSharpAPI")
add_library(
openstudio_csharp
SHARED # Was "MODULE" on Windows before
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't remember why I had to change that to "SHARED" instead of "MODULE", not 100% sure the impact it'll have.

Comment on lines +94 to +96
// Ignore the ostream operator<<, for CSharp where it'll throw a multiple definition
%ignore openstudio::operator<<;
%ignore openstudio::model::operator<<;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for the CSharp_OpenStudio_LeftShift__SWIG_1 multiple definitions.

@jmarrec jmarrec self-assigned this Apr 28, 2020
@jmarrec jmarrec added component - C# Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge. labels Apr 28, 2020
@jmarrec
Copy link
Collaborator Author

jmarrec commented Apr 29, 2020

(py38)julien@OpenStudio.Tests (Dotnet_updated *=)$ dotnet test -v n
Build started 4/30/2020 1:53:32 AM.
[...]
         Build completed.


Test run for /home/julien/Software/Others/OpenStudio/csharp/examples/OpenStudio.Tests/bin/Debug/netcoreapp3.0/OpenStudio.Tests.dll(.NETCoreApp,Version=v3.0)
Microsoft (R) Test Execution Command Line Tool Version 16.3.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...

A total of 1 test files matched the specified pattern.

[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.0 (64-bit .NET Core 3.0.1)
[xUnit.net 00:00:00.43]   Discovering: OpenStudio.Tests
[xUnit.net 00:00:00.46]   Discovered:  OpenStudio.Tests
[xUnit.net 00:00:00.46]   Starting:    OpenStudio.Tests
[xUnit.net 00:00:00.56]   Finished:    OpenStudio.Tests

√ OpenStudio.Tests.BCLTest1.MeasureTypeTest [34ms]
√ OpenStudio.Tests.BasicTests.BasicModel [34ms]

Test Run Successful.
Total tests: 2
     Passed: 2
 Total time: 1.0495 Seconds
     1>Done Building Project "/home/julien/Software/Others/OpenStudio/csharp/examples/OpenStudio.Tests/OpenStudio.Tests.csproj" (VSTest target(s)).

Build succeeded.
    0 Warning(s)
    0 Error(s)


std::string m_componentTypeName;
std::string m_controlTypeName;
};

/** Simple class for ScheduleTypeRegistry key. \relates ModelObject */
class MODEL_API ScheduleTypeKey {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK I see you changed the type of ScheduleTypeKey from std::pair. But this is a breaking API change. I wouldn't complain except I also saw that the std::pair was even deliberately swigged. So we shouldn't take this change lightly. Is it the only way? If so then at least we should say something in release notes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not mandatory, but much cleaner, and it does fix a C# bindings issue with an improperly wrapped type. There are multiple occasions where std::pair<std::string, std::string> was defined to something that was clashing too if I recall correctly.

Like src/utilities/core/Containers.hpp:58:typedef std::pair<std::string,std::string> StringPair;>

Adding it to the release notes would make sense.

I doubt anyone uses ScheduleTypeKey much anyways, this stuff is meant to be used by the ScheduleRegistry internally, not messed with.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree on all of your points. Can you just add a comment in the release notes and then I'll just go ahead and merge? I think you will have to start a new file https://github.com/NREL/OpenStudio/tree/develop/developer/doc/ReleaseNotes for version 3.1.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VersionString::VersionString(const std::string& version)
: m_str(version)
{
bool VersionString::parseVersionString(const std::string& version) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these changes to VersionString all cosmetic formatting changes, or is there a functional change hidden in here?

@@ -114,6 +114,10 @@ class UTILITIES_API VersionString {
public:
explicit VersionString(const std::string& version);

// Default constructor, assumes the current OpenStudio::openStudioLongVersion is passed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I think here is the new functional thing. Makes sense.

@kbenne kbenne merged commit f339397 into develop Jun 2, 2020
@kbenne kbenne deleted the Dotnet_updated branch June 2, 2020 19:19
@MingboPeng
Copy link
Contributor

Hi @jmarrec, could you please share the C# sdk for Ubuntu? I am trying to refactor the Ironbug to make it dotnet core compatible, and run on Ubuntu. I cannot really figure out how to compile the OpenStudio C# SDK on Ubuntu. Could you please provide some insights?

Thanks,
Mingbo

@jmarrec
Copy link
Collaborator Author

jmarrec commented Aug 3, 2020

@MingboPeng You should only need to install dotnet-sdk on ubuntu, and enable BUILD_CSHARP_BINDINGS=ON in CMake. I can walk you through it via slack (On UnmetHours' slack for eg) if you want.

@MingboPeng
Copy link
Contributor

With @jmarrec 's help, I can confirm that C# bindings works on my Ubuntu as well. Nice work!

@jmarrec
Copy link
Collaborator Author

jmarrec commented Aug 4, 2020

Great news and Congrats on being the first person to try it out :D

@MingboPeng
Copy link
Contributor

Hi @jmarrec, I am starting to build a Github workflow (CI) to automatically build this CSharpSDK on Ubuntu. But I got a several issues:

  1. EnergyPlus9.4 HASH mismatch

https://github.com/MingboPeng/OpenStudio/runs/1278780180?check_suite_focus=true#step:5:613
image

  1. Issue with openstudio_ruby
    https://github.com/MingboPeng/OpenStudio/runs/1278780180?check_suite_focus=true#step:5:833
    image

Please let me know if I missed anything.
Thanks in advance.

@jmarrec
Copy link
Collaborator Author

jmarrec commented Oct 21, 2020

@MingboPeng Use ubuntu-18.04 image, and you will not get the hash mismatch. I started adding the block for 20.04 for E+ since they make such an installer, but it was more for future proofing. Latest updates to E+ package didn't update the hash for the ubuntu20.04 installer.

20.04 isn't officially supported, we officially support 18.04!

For 2., it's number 1. that's causing the error. Just because CMake says it didn't configure properly after a ruby message doesn't mean it's from ruby. the CMake Error due to file download hash mistmatch is likely the root cause instead.

@jmarrec
Copy link
Collaborator Author

jmarrec commented Oct 21, 2020

I've made some edits to your buildCsharp.yml github action file in a PR at MingboPeng#1

@MingboPeng
Copy link
Contributor

Thanks @jmarrec, on ubuntu, I think all works now.

I am also trying to compile it on Mac, but got following error that I can't resolve.

It failed to find the compiler while the c compiler exists.
https://github.com/MingboPeng/OpenStudio/runs/1290457540?check_suite_focus=true#step:7:449
image

https://github.com/MingboPeng/OpenStudio/runs/1290457540?check_suite_focus=true#step:7:17
image

Thanks again for your time.
Mingbo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component - C# Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants