You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 18, 2024. It is now read-only.
I am facing NativeLibraries location problem after build project, Here are the details.
Build Configuration = "Debug|x64" or "Release|x64",
VS version = VS2019
Target .NET Framework = .NET Framework 4.7.2
iMobileDevice-Net Nuget Version: 1.3.6
After building project, win-x64 files are present in the root exe folder itself. In addition to this there are 2 directories win-x86 and win-x64 (which is expected). But I don't know why win-x64 files (idevice_id.exe, imobiledevice.dll,. ...)are present in the output folder along with win-x64 and win-x86 folders.
It is happening only for x64 configuration and not for x86. And also this is occurring only when we use PackageReference type instead of package.config method.
win-x86 and win-x64 folders are present as per targets. My issue is why the files(binary files which is inside win-x64) are present in the root output directory.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
I am facing NativeLibraries location problem after build project, Here are the details.
Build Configuration = "Debug|x64" or "Release|x64",
VS version = VS2019
Target .NET Framework = .NET Framework 4.7.2
iMobileDevice-Net Nuget Version: 1.3.6
After building project, win-x64 files are present in the root exe folder itself. In addition to this there are 2 directories win-x86 and win-x64 (which is expected). But I don't know why win-x64 files (idevice_id.exe, imobiledevice.dll,. ...)are present in the output folder along with win-x64 and win-x86 folders.
It is happening only for x64 configuration and not for x86. And also this is occurring only when we use PackageReference type instead of package.config method.
Migrate from packages.config to PackageReference
The text was updated successfully, but these errors were encountered: