Or-tools: netcoreapp2.0 - System.AccessViolationException

[darkengines]

Tryied x86, x64, debug and release builds.

Steps to reproduce

Create a new netcoreapp2.0 project

• Add reference to Google.OrTools
• Set target platform to x64
• Use the following Main function:

static void Main(string[] args) {
    var solver = new Solver("Test");
}

• Run

Expected behavior

The solver should be instanciated and the program should terminate without exception.

Actual behavior

The solver instanciation throws an exception:
System.AccessViolationException : 'Attempted to read or write protected memory. This is often an indication that other memory is corrupt.'

Environment data

dotnet --info output:

Outils en ligne de commande .NET (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

Notes

The library currently works on the net46 framework.

Csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <Platforms>AnyCPU;x64</Platforms>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Google.OrTools" Version="6.2.4388" />
  </ItemGroup>

</Project>

We want to move to netcoreapp2.0 and ortools is the last barrier (we ♥ ortools).

[lperron]

I would love to move to netcoreapp2.0. I do not know how it interacts with
swig.

I will give it a look, but help is welcomed :-)

Laurent Perron | Operations Research | [email protected] | (33) 1 42 68 53
00

2017-09-01 12:12 GMT+02:00 Florent Tollin de Rivarol <
[email protected]>:

Tryied x86, x64, debug and release builds.

class Program {
static void Main(string[] args) {
var solver = new Solver("Test");
}
}

Csproj:

Exe
netcoreapp2.0
AnyCPU;x64

true

We want to move to netcoreapp2.0 and ortools is the last barrier (we ♥
ortools).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/issues/463, or mute the thread
https://github.com/notifications/unsubscribe-auth/AKj17TtMfwflCNjcXvAKm1IpGFWmTkhGks5sd9h8gaJpZM4PJ9qC
.

[darkengines]

:) I'am building the project from scratch so I can have a chance to understand what's happening here.
As I understand, Swig just writes some wrapping code around the c++ api, maybe we just need to change the way it's built (using dotnet-cli?).

[darkengines]

I think that, indeed, it's more related to swig.
The exception is thrown by operations_research_constraint_solverPINVOKE.new_Solver__SWIG_0(modelname).

Interesting file: or-tools\makefiles\Makefile.csharp.mk (line 281)
Could it be related to the garbage collector ?

[jkotas]

The problem is that Google.OrTools.dll is C++/CLI assembly. C++/CLI is not supported by .NET Core.

[lperron]

I agree.
But I use swig to generate the wrapper and until swig change it, I cannot
do anything.

So I wait.

Laurent Perron | Operations Research | [email protected] | (33) 1 42 68 53
00

2017-09-27 4:01 GMT+02:00 Jan Kotas [e-mail]:

The problem is that Google.OrTools.dll is C++/CLI assembly. C++/CLI is not
supported by .NET Core.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/issues/463#issuecomment-332386981,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKj17d-cz3n97J7-N4TvX28lnTX7XFx2ks5smayVgaJpZM4PJ9qC
.

[darkengines]

OK, we will set ortools on a secondary server so we can keep moving to netcoreapp2.0.
Feel free to link any issue about C++/CLI support in netcoreapp2.0 here.
Thanks for the investigations.

[DevNamedZed]

swig uses p/invoke no cli/c++, the problem is the managed code is included in the same dll as the native code which .net core does not support. Small fix, just need to build two separate dlls like whats currently being done with mono.

Here are some small hacky my team used to get .net core working on a windows machine. more work to get .net standard library but this will not cause av

makefile.csharp.mk
https://gist.github.com/DevNamedZed/6d3accd3b7820b0e79a90235efe57b4d

[darkengines]

@DevNamedZed, Successfully instanciated the solver with your solution.
Do you plan to provide a suitable nuget package for this use case?

[Mizux]

Link to #308

[lperron]

We are delivering the next release on dotnet core 2.1, and we dropped mono.

I guess I can close this issue.

Thanks