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

Possibility to use as nuget package #24

Open
HuskyNator opened this issue Jan 23, 2020 · 10 comments
Open

Possibility to use as nuget package #24

HuskyNator opened this issue Jan 23, 2020 · 10 comments

Comments

@HuskyNator
Copy link

Is it possible to make use the nuget package given by using add package glfw-net,
instead of using the source code directly, even as submodule?

Whenever I try, I receive a System.DllNotFoundException even when renaming the dll files from glfw3 to glfw. Neither does changing the location from a lib folder to the root seem to work. Though this method seems greatly more preferable to cloning the source.

@ForeverZer0
Copy link
Owner

I am very likely going to target .NET Core with the next release to take advantage of dynamically finding the library, which uses different naming conventions on different operating systems. .NET Standard is rather lacking in this regard, and all solutions to it are rather hacky, so I have been avoiding adding to the library. There is an open discussion about it in #21 that gives some more detail on the reasoning behind it.

The inconvenience renaming the library aside, a System.DllNotFoundException just indicates that the library is not where it expects it to be. Would you be able to give a quick breakdown of the directory structure of your project?

@HuskyNator
Copy link
Author

At the moment it's simply a structured as a single directory,
with at the root a .csproj file together with the .cs file it uses as its main.

I have included the library directly inside a lib folder, although I've also tried moving the 3 library files to the root itself, which did not work.

That aside, im not actually sure why it's 3, 2 of which are simply '.a' files, of which i have no clue what its purpose is.

All in all, currently, with (and im aware this is incorrect, not sure what is correct though) :

hoekjes/
    bin/
    obj/
    lib/
        glfw3.dll
        libglfw3.a
        libglfw3dll.a
    Program.cs
    hoekjes.csproj

@ForeverZer0
Copy link
Owner

The .a files are static libraries versions glfw, typically for embedding into a C application, you do not need those, only the shared (.dll) one. Assuming that you have those set to copy to the build directory, where you have your main application, and a lib sub-folder containing them, it should find them if the constant is set to lib/glfw3.

For example, if your final compiled product looks like this, where MyExecutable is the file that you pass to dotnet run:

application
    MyExecutable.dll
    resouces/
        picture.png
    native/
        x86/
            glfw3.dll
        x64/
            glfw3.dll

Here it should be lib/x86/glf3 or lib/x64/glfw3 depending on your target architecture. I don't have a Windows machine available at the moment to confirm for you, so let me know if that helps it.

I could probably supply a separate NuGet package that contained the native binaries for Windows users that would place them in a predictable location on the system, which could make it more convenient and eliminate the need for renaming manually.

@HuskyNator
Copy link
Author

HuskyNator commented Feb 3, 2020

I got it to work by using:

<Target Name="CopyCustomContent" AfterTargets="AfterBuild">
    <Copy SourceFiles="lib/glfw.dll" DestinationFolder="$(outDir)"/>
</Target>

Not very beautifyl, additionally I did rename glfw3.dll.
Might cause problems later on but this way I can, from what i've seen, use it with
<PackageReference Include="glfw-net" Version="3.3.1" />

Not sure how it would work using different targets, though AfterTargets="Publish" and DestinationFolder="$(PublishDir)" are useable too.

It should work pretty well now :), though of course, it does mean using possibly outdated versions. 😅 Thanks for your reaction, I totally forgot about copying the dll file over to the output. 🤦‍♀

@BjarkeCK
Copy link

BjarkeCK commented Mar 6, 2020

Do I place the dll in a lib folder in the GLFW.Net project root or the BasicExample root?
Not sure how to actually reference the dll and get it working.

@HuskyNator
Copy link
Author

You can place it in any place you like, if i am correct.
You can for example place it in a lib folder of your project's root, like I did.
Would require you to do the same stuff i did in my post, with your .csproj ^.
(Note I renamed it to glfw.dll in my project)

@HuskyNator
Copy link
Author

In the meantime, might it be possible to make a 3.3.2 release?
3.3.1 is problematic for me due to the delegates, though i'd prefer not cloning the repo.
(That's just personal preference though)

@ForeverZer0
Copy link
Owner

I think I can get an updated release pushed out within the next few days, I have admittedly been a little complacent with this project lately working on a small game-engine myself. Luckily, doing so has brought to my attention a few other minor issues that could be improved upon with this library, so I will use the opportunity to improve those aspects as well.

I will be dropping the .NET Standard targeting and just going full-on .NET Core to finally fix the library loading once and for all. There is very little reason not to be using .NET Core at this point on any desktop platform, and it is causing more problems than it fixes sticking with .NET Standard.

@sirgru
Copy link

sirgru commented Aug 16, 2020

I would also like to see this library as a nuget package, for .NET Core, with streamlined library loading. I did manage to get it to run with a little bit of hassle, but making the experience smoother would further increase the relevance of this library. I would also like to commend having SkiaSharp example out of the box.

@wegfawefgawefg
Copy link

i installed glfw-net and glfw 3.3.1 in nuget but im getting the same unable to load dll issue.

Im doing something wrong. If i installed through nuget i dont need to go download the actual dlls right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants