Windows Build failed when using tarball in releases

[PetrBodnar]

Describe the bug Windows build failed with Required file "C:/projects/Myproject/Assets\Plugins/Windows/x64\DynamicLibraryLoaderHelper-x64.dll" which is output from project file "C:/projects/Myproject/Assets../lib/NativeCode\DynamicLibraryLoaderHelper/DynamicLibraryLoaderHelper.sln" is missing.

To Reproduce Steps to reproduce the behavior:

1. Create new Unity project on Windows, select Windows platform
2. Download tarball 3.1.2 from releases page
3. Go to package manager and add tarball with "Add package from tarball"
4. Package is successfully imported
5. Configure the EOS plugin through "Tools"->"EOS Plugin"->"EOS Configuration" with any values to create EOS config file
6. Build the project
7. Build fails with Required file "C:/projects/Myproject/Assets\Plugins/Windows/x64\DynamicLibraryLoaderHelper-x64.dll" which is output from project file

Expected behavior Build should run successfully

Desktop (please complete the following information):

• OS: Windows x64
• Unity Editor
• Unity 2021.3.14f1
• EOS plugin for Unity 3.1.2

Additional context We found that there no "lib" or "lib/NativeCode" inside tarball

[BestStream]

We received the same error when we tried to implement the plugin "manually". When we implemented through git - no error

[paulhazen]

@BestStream, @PetrBodnar Can you give me a few more pieces of information? I am having a difficulty reproducing the issue you both experienced.

What is interesting is that the dll file that is being logged as missing does in-fact exist. Although it exists within Packages/Epic Online Services Plugin for Unity/Runtime/Windows/x64/, which should be mapped properly in the section of code that checks for it's presence:

So it is revealing that the path that is being checked is Assets/Plugins/Windows/x64/... instead of the path to the existing dll in the corresponding Runtime directory of the plugin directory in Packages. Any thoughts?

Can you please share the contents of the log output in greater detail so that we can see where exactly this error is being thrown from? Also if you have any unique build settings - atypical settings - that would be useful to know as well.

[BestStream]

@paulhazen My case: I fail to import plugin via git. Later I realized how to do this - I had to install git-lfs before (I think it would be useful to add this advice to the docs). The tarball method worked, but I didn’t know how to sync it through git. So I tried to move all the files to the Assets/Plugins/EOS/ - after that I received the same error as @PetrBodnar (mac works, windows not). Later I realized that in order to import the plugin and sync via git correctly, I need to put the files in Packages/com.playeveryware.eos@0465461da5d5/

[PetrBodnar]

in the section of code that checks for it's presence

Can you please point where this code is located? I will try to set a breakpoint in debugger

[paulhazen]

in the section of code that checks for it's presence

Can you please point where this code is located? I will try to set a breakpoint in debugger

Sure! The error is logged on line 232 within PlatformSpecificBuilder.cs. You should be able to easily find that file by searching in the asset explorer like so:

Just make sure to search within "Packages" as indicated in the above image.

[paulhazen]

I think it would be useful to add this advice to the docs.

I will make sure that we make that advice more prominent, this is good feedback for us to have. Would it be correct to say that this is no longer an issue that you are experiencing?

[BestStream]

@paulhazen This is not a problem for me, I just advised PetrBodnar how to solve the problem

[PetrBodnar]

I see in code that only MacOSBuilder checks for the libraries in Packages/com.playeveryware.eos/Runtime/... , but WindowsBuilder doesnt check this directory for dlls (WindowsBuilder doesn't in any way check for or make use of dlls located in Packages/com.playeveryware.eos/Runtime/Windows/x64.)

[PetrBodnar]

Build log: Editor.log

[paulhazen]

I see in code that only MacOSBuilder checks for the libraries in Packages/com.playeveryware.eos/Runtime/Windows/x64... , but WindowsBuilder doesnt check this directory for dlls (WindowsBuilder doesn't in any way check for or make use of dlls located in Packages/com.playeveryware.eos/Runtime/Windows/x64.)

It's odd that MacOSBuilder checks that directory. I'll have to look into that. It should be WindowsBuilder64 that defines which files are checked for. I believe that builder class is defined in the same file as WindowsBuilder.cs

[paulhazen]

@PetrBodnar I believe I know what the source of the problem is - and it's related to how we determine if the project is running as a UPM. Can you please try using the 3.1.3 release? I believe that the issue was resolved in our latest hotfix which is included in that release.

[PetrBodnar]

We will try, thank you.

[PetrBodnar]

I checked - it works (with 3.1.3). Thank you a lot!