This application or script uses TorchSharp but doesn't contain a reference to libtorch-cpu-11.3-win-x64, Version=1.11.0.1

[Oklyso]

Having some trouble using Torchsharp in a C# .Net 4.8 project. I'd show you some source code but this is as far as i've gotten:

TryInitializeDeviceType(TorchSharp.DeviceType.CPU);
Replacing this code with any other code from Torchsharp-library creates the same result and error.

I'm using the Torchsharp-cpu nuget package, and I've tried using Torchsharp with the libtorch-cpu-11.3-win-x64 package and its dependencies as well without any luck.

My packages.config includes these:
<package id="libtorch-cpu" version="1.13.0.1" targetFramework="net48" /> <package id="libtorch-cpu-linux-x64" version="1.13.0.1" targetFramework="net48" /> <package id="libtorch-cpu-osx-x64" version="1.13.0.1" targetFramework="net48" /> <package id="libtorch-cpu-win-x64" version="1.13.0.1" targetFramework="net48" />
And I've tried using the exact 1.11.0 version with no luck as well.

Not really sure how to proceed to make it work here.

[NiklasGustafsson]

Are you using Visual Studio for this work?

[Oklyso]

Are you using Visual Studio for this work?

Yep. Using the built-in Nuget Manager and trying to make it work with Autodesk Revit recently, which shouldn't be that different from a default .NET project.

[NiklasGustafsson]

Try clearing out any TorchSharp dependencies and re-importing the "TorchSharp-cpu" package. That really should be everything you need to do. Do a build clean, etc. Then, if it still fails, take a look in the output folder, looking for torch-related dlls.

[Oklyso]

A little update on this matter:

Works flawless when using a Console Application project for Visual Studio, however my workflow kind of requires that it be assembled as a Class Library dll.

Seemingly once built into a dll it loses the reference and throws the error in the issue-title.
Once again, I'm not sure if this is even supported and/or if there is a way to circumvent this.

Edit: I've looked at #640 and it seems we're trying to accomplish the same thing.

Edit2: Using the info from the other issue, I tried to natively load the DLLs at runtime.
Loading "Torch_cpu" returned "0x00007ffd326a0000" but didnt seem to make any difference. Error still thrown.
Loading "LibTorchSharp" which I suspect is the main culprit returned "0x0000000000000000" (or failed to load).

When making plugins for other softwares like Revit or Rhinoceros 3D, it requires the plugin to be loaded in as a .dll, hence the desperate attempts to make this work from a class library. I don't see why this wouldn't work, but it seems TorchSharp can only keep references of other dependencies as an executable (.exe) project.

[NiklasGustafsson]

There's nothing special about TorchSharp as far as dependencies go. It just needs all the depended-upon DLLs to be in the binary directory when the application is started.

Based on your description, it sounds like your build isn't copying the dependencies to the output directory in the case when you're using TorchSharp in a library project. Check the output directory of the project that you are ultimately running and look for torch* dlls there.

[mfagerlund]

I'm having similar issues. I'm using

Microsoft Visual Studio Professional 2022 (64-bit) - Current
Version 17.4.4

New Project

4.8.1

    internal class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(torch.tensor(5).str());
        }
    }

System.BadImageFormatException: 'Det går inte att läsa in filen eller sammansättningen TorchSharp, Version=0.99.2.0, Culture=neutral, PublicKeyToken=67b0e5e1da516a1c eller ett av dess beroenden. Ett försök att läsa in ett program med ogiltigt format gjordes.'

[mfagerlund]

When I instead use this version (which is deceptively similar, but not .NET Framework)

Same TorchSharp

internal class Program
 {
     static void Main(string[] args)
     {
         Console.WriteLine(torch.tensor(new float[] { 5, 5 }).str());
     }
 }

Runs perfectly fine.
[2], type = Float32, device = cpu
5 5

[Mattias-NCVIB]

When I again try the 4.8.1 route with a console app and change the platform target to x64 it at least loads the dll without failing

But it again fails (with a shorter message) because it can't find pytorch:

but I am using the correct nuget

This is what's in the Debug folder

If I add the files from the build that worked (is that .NET Core? .NET Standard? It's all so confusing)

I grabbed these:

and posted them here:

It works (yay!):

It seems to me that there are several issues:

1. The instructions should make it super explicit that you MUST use 64 bit builds if you're using 4.8.1
2. The correct DLLs aren't deployed as they should be, and copying them by hand is tricky.

[NiklasGustafsson]

I'll add a comment to the readme pointing out that libtorch is 64-bit only, that's a good idea.

@Mattias-NCVIB, I don't know how to explain why VS is not copying all the dependencies, but it does not seem like an issue with TorchSharp, itself. Are you using the "wrapper" package TorchSharp-cpu, or are you using TorchSharp + libtorch-cpu-win-x64?

[GeorgeS2019]

@NiklasGustafsson
We may need a FAQ and ask users here to contribute => we had this in discussion, not easy to track

[mfagerlund]

I'm using the wrapper. Sorry if I have two different accounts on github, it confuses me to :o . But it's all the same mattias. I'll give it another spin if you want, with screenshots throughout. Den tis 14 feb. 2023 kl 15:49 skrev Niklas Gustafsson < ***@***.***>:

…

I'll add a comment to the readme pointing out that libtorch is 64-bit only, that's a good idea. @Mattias-NCVIB <https://github.com/Mattias-NCVIB>, I don't know how to explain why VS is not copying all the dependencies, but it does not seem like an issue with TorchSharp, itself. Are you using the "wrapper" package TorchSharp-cpu, or are you using TorchSharp + libtorch-cpu-win64? — Reply to this email directly, view it on GitHub <#907 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADD556IC2H6ZVIV5BFW4HOTWXOLOBANCNFSM6AAAAAAUSS3AOE> . You are receiving this because you commented.Message ID: ***@***.***>

-- /Mattias Fagerlund

[NiklasGustafsson]

@mfagerlund -- sure, if you want to take the time. Clean up all the *torch* packages under the nuget cache in ~\.nuget\packages first, clean the obj and bin folders. Start afresh, in other words.

[mfagerlund]

Not sure where ~.nuget resides - but a fresh solution should work? Den tis 14 feb. 2023 kl 15:53 skrev Niklas Gustafsson < ***@***.***>:

…

@mfagerlund <https://github.com/mfagerlund> -- sure, if you want to take the time. Clean up all the *torch* packages under the nuget cache in ~.nuget\packages first, clean the obj and bin folders. Start afresh, in other words. — Reply to this email directly, view it on GitHub <#907 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADD556K2Y76SKZUURO3GVK3WXOMAHANCNFSM6AAAAAAUSS3AOE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- /Mattias Fagerlund

[NiklasGustafsson]

Sorry for using the Unix-style path. It is under c:\users\your name\.nuget

%HOMEDRIVE%%HOMEPATH%\.nuget

[NiklasGustafsson]

a fresh solution should work?

Just do a clean of the obj + bin folders. Remove the TorchSharp-cpu package dependency and add it back in. If there's some weird setting to not copy transitive dependencies (I don't think there is, I have never heard of one), make sure that it's not set.

[mfagerlund]

Using VS 2022

Removed entire .nuget directory from C:\Users\matti (why matti!? sounds finnish)

Dlls:

Copying the required ones - success:

[mfagerlund]

As mentioned earlier, the dlls are copied when I create a .net 5 project. Are those different configurations as far as TorchSharp goes, or is it all the same? You should be able to reproduce this - or does it actually work for you? That would be the weirdest part for me...

[NiklasGustafsson]

It has been working for me, but I haven't tried it with 0.99.2 on 4.8.1. I will do so later today.

@tarekgh -- you're the .NET FX expert. Any thoughts on why VS would treat .NET FX differently from .NET Core as far as copying dependencies goes?

[mfagerlund]

Once it works, if I run Clean solution all dlls are deleted except asmjit.dll . If I then do a rebuild, the required dlls aren't included and it fails.

[NiklasGustafsson]

Yeah, it's VS / dotnet that's not copying all the transitive dependencies (TorchSharp is there, but not all the libtorch DLLs), so if you do a clean, it's going to make the same mistake again.

[NiklasGustafsson]

What's mysterious (to me) is that it only fails for .NET FX. Tarek may have some thoughts. but it's still early morning here.

[mfagerlund]

I'll add a comment to the readme pointing out that libtorch is 64-bit only, that's a good idea.

@Mattias-NCVIB, I don't know how to explain why VS is not copying all the dependencies, but it does not seem like an issue with TorchSharp, itself. Are you using the "wrapper" package TorchSharp-cpu, or are you using TorchSharp + libtorch-cpu-win-x64?

Actually, would it be possible to instead create some kind of compiler error / more appropriate runtime error when someone's trying to use other than x64? Because not everyone reads the documentation all that carefully, and that error message is way cryptic...

/m

[tarekgh]

I'll try to look at that later. There are two msbuild systems. When using .NET Framework, the legacy msbuild will get used. When using .NET project, the new msbuild with the .NET SDK will get used. There could be some differences.

[tarekgh]

I can reproduce locally. I didn't have a chance to look deeper to know what is going on. But quick look, it seems to me when referencing the TorchSharp-cpu package in the project, will not get any entry added to csproj which will have the effect as didn't reference this package at all. But I did a quick trial to force using the new msbuild/SDK to build for the .NET Framework and this seems to work.

Just try to use csproj contents like the following and you can load this project in VS and compile/run there too.

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net481</TargetFramework>
    <RootNamespace>TorchSharpNetFX_New</RootNamespace>
    <LangVersion>latest</LangVersion>
    <PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Memory" Version="4.5.5" />
    <PackageReference Include="TorchSharp" Version="0.99.2" />
    <PackageReference Include="TorchSharp-cpu" Version="0.99.2" />
  </ItemGroup>

</Project>

Edit:
The packages are listed in the packages.config file which should be used to restore the bits and not listed in the csproj.

[tarekgh]

I just learned that publishing the native package bits (like libtorch packages) are not supported today in the old-style projects (which is the case here). There is a tracked ask to make this better here NuGet/Home#12388.

Meanwhile, I'll try to provide some workaround if users still want to use the old-style projects. But using the new style projects workaround I provided in the comment should be good to use too.

[tarekgh]

Here is how you can try to work around the issue with the old projects:

• Clean your project from old, referenced packages. I mean in the NuGet package manager, uninstall all referenced NuGet packages (like TorchSharp and TorchSharp-cpu).
• delete the file packages.config
• try to change the Default Package Management option in the Options UI to PackageReference
  
• Right click on your project in the solution explorer and choose clean
• manually go to NuGet manager in your project and start adding the dependencies on the packages TorchSharp and TorchSharp-cpu.
• Compile and run.

These steps I already tried but I love to hear if this worked for all you.

[mfagerlund]

For me, it's not that I want to use one or another type of project. It's that when I use VS to create a project, I would expect the TorchSharp nuget to work - but currently it doesn't. 99% of users will check out at that point.

The "torch is missing" error message could suggest the fix you're suggesting above, especially if it can be detected that that's the issue. But you'd still be loosing users due to the fact that the nuget doesn't work straight out of the box.

The reasony I use 4.8.1 is that I wanted to use the code I created in Unity.

[tarekgh]

@mfagerlund we understand there is a problem here. What I have provided is just a work around for anyone blocked by that.

• For package restoring problem, we have the issue Make PackageReference the default in Visual Studio NuGet/Home#12388 tracking the ask to help with this problem. Feel free to comment there to show user interests in fixing this problem.
• @NiklasGustafsson looking at adding some error message which may help when users compile with non-x64 when referencing torchsharp-cpu.

[NiklasGustafsson]

@mfagerlund -- understood. The challenge is that we have very little control over this within the TorchSharp umbrella. We're actively examining how we can issue error messages when building for 32 bit platforms.

[mfagerlund]

If I came off sounding harsh, that absolutely wasn't my intention, I appreciate all your good work!

[NiklasGustafsson]

For now, I'm going to add a runtime check that we're running in 64-bit mode before trying to load DLLs. That should at least help by generating a more directly understandable error message. Still won't address the core issue.

[NiklasGustafsson]

Something like this:

[mfagerlund]

Something like this:

For me, that 100% solves that particular issue!

[mfagerlund]

These steps I already tried but I love to hear if this worked for all you.

This worked in my test project!

[NiklasGustafsson]

@Oklyso -- are we good on this one? How much overlap is there between what you were seeing and what @mfagerlund has seen (and worked around)?

[Oklyso]

Seems like a culmination of things. Double checked the .csproj file, and eventually I figured out that in my particular case you actually need to place the Torchsharp / torch DLL files DIRECTLY in the root folder of 3rd party programs if you intend on using it as a plugin.

One specific issue was that "Torchsharp" is referenced in the csproj when using Torchsharp-cpu, but not the "Torchsharp-cpu" package itself (which means the LibTorch file wasn't being found).

Appreciate all the feedback, it has been quite helpful!