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

Can't load or-tools 9.6 library on windows, .NET6 #3747

Open
paulohtobias opened this issue Apr 11, 2023 · 7 comments
Open

Can't load or-tools 9.6 library on windows, .NET6 #3747

paulohtobias opened this issue Apr 11, 2023 · 7 comments
Assignees
Labels
Bug Lang: .NET .Net wrapper issue OS: Windows Windows OS
Milestone

Comments

@paulohtobias
Copy link

Version: v9.6
Language: C#, .NET6
Solver: any solver
OS: Windows 11 21H2
CPU: Intel Core i7-1185G7

Downloaded example repo as zip from the installation page which still points to v9.5 and it worked fine. Updating it to v9.6 or creating a new project and installing or-tools 9.6 via nuget raises the following runtime exception:

Unhandled exception. System.TypeInitializationException: The type initializer for 'Google.OrTools.LinearSolver.operations_research_linear_solverPINVOKE' threw an exception.
 ---> System.TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
 ---> System.DllNotFoundException: Unable to load DLL 'google-ortools-native' or one of its dependencies: The specified module could not be found. (0x8007007E)

Downgrading or-tools to 9.5 via nuget fixes the problem

@Mizux Mizux self-assigned this Apr 11, 2023
@Mizux Mizux added Bug OS: Windows Windows OS Lang: .NET .Net wrapper issue labels Apr 11, 2023
@anders9ustafsson
Copy link

anders9ustafsson commented Sep 14, 2023

Experiencing the same issue with versions 9.6 and 9.7, .NET Framework 4.8, Windows 11 22H2. I notice that google-ortools-native.dll is not copied to the application directory. When I do this manually, computation runs as expected.

Is work ongoing to fix this issue?

@Mizux
Copy link
Collaborator

Mizux commented Oct 4, 2023

For release, on windows, we are generating nuget package using net462 and net6.0 TFM.

echo Build dotnet: ... | tee.exe -a build.log
cmake -S. -Btemp_dotnet -DBUILD_SAMPLES=OFF -DBUILD_EXAMPLES=OFF -DBUILD_DOTNET=ON -DUSE_DOTNET_462=ON
cmake --build temp_dotnet --config Release -j8 -v

or-tools/CMakeLists.txt

Lines 316 to 317 in 1d696f9

option(USE_DOTNET_6 "Use .Net 6.0 LTS support" ON)
message(STATUS ".Net: Use .Net 6.0 LTS support: ${USE_DOTNET_6}")

Dev Note:
Need to reuse https://github.com/Mizux/dotnet-native/actions/workflows/amd64_tfm.yml on https://github.com/or-tools/dotnet_or-tools to test the combinatory (net48, netstandard2.0, netstandard2.1, netcoreapp3.1, net5.0, net6.0, net7.0)...

@Mizux Mizux added this to the v9.9 milestone Nov 17, 2023
@nneitzke
Copy link

nneitzke commented Jan 2, 2024

I can confirm I am also having this issue with .NET Framework 4.8 on Windows 11 Pro 23H2 and or-tools version 9.7.2996/9.8.3296. google-ortools-native.dll does not get copied to the output directory on build.

@stuarthillary
Copy link
Contributor

stuarthillary commented Jan 12, 2024

TLDR;

The missing google-ortools-native.dll file issue can be resolved by explicitly setting the target runtime when building/running the example project. For example on Windows

To build
dotnet build -r win-x64 -c Release

To run
dotnet run -r win-x64 -c Release

The target runtime can be changed to linux-arm64, linux-x64, osx-arm64, osx-x64, or win-x64 as required.

Diagnosing the problem

The issue of the missing google-ortools-native.dll file in the build output directory when targeting .NET Framework 4.8 is due to using the dotnet build tool (created for .NET Core/.NET5+) to build a project/solution targeting the older .NET Framework versions.

To diagnose this I downloaded the example project from this URL https://developers.google.com/optimization/install/dotnet/pkg_windows

In the csproj file I changed the TargetFramework to net4.8 and used the PackageReference -> Google.OrTools version 9.8.*.

I used the dotnet SDK version 6.0.417. Using the current build instructions (with a more verbose logging setting)

dotnet build /verbosity:detailed -c Release

you can see that the RuntimeIdentifier (RID) that is resolved is win7-x86. This RID is used to try to restore native content from the transient dependency packages Google.OrTools.runtime.*, and there is no content for this particular RID in any of the packages (see https://learn.microsoft.com/en-us/dotnet/core/rid-catalog for more information on RIDs).

To fix this issue one needs to specify the RID explicitly when targeting an older .NET Framework version. For example, on Windows, one can use

dotnet build -r win-x64 -c Release

If one has the target framework of net6, and use the current build instructions

dotnet build -c Release

the build output directory contains a directory called runtimes that contains subdirectories for each runtime. In this case, the correct native library is located and loaded at runtime.

@Mizux
Copy link
Collaborator

Mizux commented Jan 12, 2024

@nneitzke
Copy link

I greatly appreciate the detailed write-up, it is very useful for anyone on .NET 48 that can use the dotnet tool. Unfortunately the dotnet tool does not work with .NET 48 asp.net mvc projects and I am unable to add the runtime identifier to them. I tried adding the xml tag to the csproj but it had no effect (which makes sense given it is not and can't be an SDK style project). I implemented a manual build step that copies the file but wanted to post this in case anyone else is in a similar situation.

@Mizux Mizux modified the milestones: v9.9, v10.0 Feb 14, 2024
@PashaSamb
Copy link

I encountered a similar problem in AspNetCore (v.8) and OrTools 9.9.3963, and none of the above solutions helped. The problem was resolved by installing the latest Visual C++ Redistributable package from https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Lang: .NET .Net wrapper issue OS: Windows Windows OS
6 participants