@adityapatwardhan 당신이 이것을 볼 수 있습니까?

procmon 유틸리티로 사용 된 경로를 찾은 다음 HintPath 로 수정을 시도 할 수 있습니다

나는 그것을 보여줄 것이지만 이것이 내가 직접로드하는 라이브러리가 아니라는 점을 감안할 때 (주 SkiaSharp.dll 자체에 의해로드 됨) 너무 많은 일을한다는 확신이 없습니다. 플랫폼에 따라로드 할 수있는 라이브러리 파일이 4 개라는 사실도 상황을 복잡하게 만듭니다.

그러나 어쨌든 이것은 의도적 인 변경처럼 보이지 않으므로 회귀 문제를 해결해야합니다.

MSFT 팀은 .Net Core 3.0에서 vNext p / invokes에 대해 열심히 일하며 아마도 2.1로 백 포팅했을 것입니다. PowerShell 관련 dll 로딩에서 아무것도 변경 한 것을 기억하지 못합니다.

6.2.0-preview2에서 # 8073 및 몇 가지 Internal 변경 사항이 있습니다. 나는 그 동안에 무엇이 바뀌 었는지 전혀 모른다. 😕

PR 변경은 먼저 모듈 폴더에서 모듈 dll을로드 한 다음 GAC에서로드하는 것입니다. 문제는 모듈 dll이 두 번째 dll을 참조하고 자동 dll로드 (PowerShell이 ​​아닌 Core)가 dll을 찾지 못한다는 것입니다. 내 제안은 프로젝트 파일의 dll에 힌트 경로를 명시 적으로 추가하는 것입니다.

@iSazonov 내 csproj에 일부 HintPath 참조를 추가했지만 dotnet publish 때 경고 만 표시됩니다. 일단로드 된 모듈의 동작에는 변화가 없습니다.

조금 더 읽어 보면 HintPath가 프로젝트 빌드 자체에 _ 포함되지 않은 _ 외부 어셈블리를 참조하는 데 사용되는 것 같습니다. SkiaSharp 어셈블리가 포함되어 있으므로 컴파일 / 빌드 용 HintPath를 추가해도 Skia DLL이나 런타임시 조회하는 경로에 영향을주지 않습니다.

참고로 이것은 내 csproj입니다.

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

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="PowerShellStandard.Library" Version="5.1.1" PrivateAssets="All" />
    <PackageReference Include="SkiaSharp" Version="1.68.0" />
    <PackageReference Include="SkiaSharp.NativeAssets.Linux" Version="1.68.0" />
  </ItemGroup>

</Project>

다음 줄을 아무 효과도없이 추가했습니다 (찾을 수 없다는 빌드 / 게시 시간 경고 외에는 게시가 완료 될 때까지 존재하지 않기 때문입니다).

  <ItemGroup>
    <Reference Include="libSkiaSharp">
        <HintPath>win-x86/libSkiaSharp.dll</HintPath>
        <HintPath>win-x64/libSkiaSharp.dll</HintPath>
        <HintPath>osx/libSkiaSharp.dylib</HintPath>
        <HintPath>linux-x64/libSkiaSharp.dylib</HintPath>
    </Reference>
</ItemGroup>

HintPath에서 읽은 내용에 따르면 DLL을로드 할 때 검색되는 경로 또는 해당 DLL이 p / invoke 목적으로 다른 DLL을로드하려고 시도하는 데 영향을 미치지 않는 것 같습니다.

_That_ HintPath는 컴파일 타임에만 해당됩니다.

당신이 말하는 방식이 내가 놓친 또 다른 것이있는 것처럼 들리는가?

@ vexx32 간단한 repo 코드가 있다면 CoreCLR 저장소에서 요청할 수 있습니다.

아직 Powershell 관련 변경 사항을 배제 할 수 있는지 잘 모르겠습니다. 콘솔 앱에 대한 작은 테스트를 함께하고 어떻게 진행되는지 확인해야 할 수도 있습니다.

@Jaykul 의 팁 덕분에 저는

Add-Type -TypeDefinition @"
    using System.Runtime.InteropServices;

    public class DllLoadPath
    {
        [DllImport("kernel32", CharSet=CharSet.Unicode)]
        public static extern int SetDllDirectory(string NewDirectory);
    }
"@

# ...

[DllLoadPath]::SetDllDirectory($NativeRuntimeFolder)

그러나이 작업을 수행하기 위해 추가 p / invoke를 _ 요구 _한다는 사실은 우스꽝 스럽습니다. 또한 여기에 설명 된대로 표준 검색 위치에서로드 된 SkiaSharp.dll의 자체 디렉토리 경로를 변경하고 제거하는 것에 대해 매우 혼란 스럽

@ vexx32 문제를 재현 할 수 없습니다. 재현에서 뭔가 놓친 게 있나요? PSWordCloud의 경우 특정 버전일까요?

PS> Install-Module PSWordCloud                                                               
Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its
InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from
'PSGallery'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): y

PS> New-WordCloud                                                                            
cmdlet New-WordCloud at command pipeline position 1
Supply values for the following parameters:
InputObject:
Path:

PS> $PSVersionTable                                                                          
Name                           Value
----                           -----
PSVersion                      6.2.0
PSEdition                      Core
GitCommitId                    6.2.0
OS                             Microsoft Windows 10.0.18885
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

죄송합니다. 언급했듯이 2.1.1에서 수정했습니다.

2.1.0을 특별히 설치하면 위의 p / invoke 해결 방법이 없기 때문에 오류가 표시됩니다.

좋아, 이제 재현 할 수 있습니다. 내가 살펴볼 게.

@ vexx32 우리가에 나열된 모든 파일을로드 할 것으로 보인다 FileList 의 psd1 . 그게 필요합니까? FileList 에서 모든 항목을 제거하면 더 이상 문제를 재현 할 수 없습니다.

그래요? 그것은 매우 이상합니다. 아니요, 특별히 필요하지는 않으며, 지속적으로 업데이트하고 싶지 않기 때문에 어쨌든 제거 할 것입니다. 그러나 그것은 몇 가지 버전에 적용되었습니다.

그래도 갑자기 DLL로드에 영향을 미칠 것이라는 점이 이상합니다.

psd1의 FileList에 나열된 모든 파일을로드 한 것 같습니다.

.psd1 파일에서 "if"를 지원하는 데 문제가 있습니다. 따라서 플랫폼 별 dll을로드 할 수 있습니다.

@iSazonov 그것은 # 5541 입니다. 곧 업데이트를 드리겠습니다.

그것은 가능성입니다. 내가 궁금해하는 것은 _now_ FileList의 네이티브 라이브러리 (모두)에 경로를 추가하는 것만으로도 충분하다면 ... p / invoke가 필요하지 않을 수도 있습니다. 테스트해볼 게요! 😊

편집 : 아니요, 효과가있는 것으로 보이지 않습니다. :(

관리되는 어셈블리 만로드하는 Assembly.Load() 를 호출합니다.

우리가 만든 변화 우리가 GAC에보고하기 전에 모듈 폴더에서로드 DLL을 시작한 경우 6.2.0-preview.2에 있습니다. 이 변경의 부작용은 FileList에 DLL도로드한다는 것입니다.

말이 되네요. 문서 문제가 열려 있습니까? 누군가가 그것을 발견하고 우리가 그것을 문서화하지 않은 경우 추적하기가 매우 어려울 것입니다. 이러한 이유로 파일 목록에 네이티브 어셈블리를 넣지 않으려는 것을 문서화해야합니다.

그것을 추적하는 데 도움을 주셔서 감사합니다! 지금은 내가 언급 한 P / invoke 솔루션이 가장 유연성을 제공하지만 모듈 로딩에서 이러한 것들을 처리하는 것이 합리적 일 수 있습니다.

예를 들어 PrivateData에서 키가 지원되는 플랫폼 이름 / 아키텍처와 일치하는 해시 테이블 인 RuntimeLibPaths라는 항목을 추가하고 값은 기본 라이브러리가 포함 된 폴더의 경로입니다. 가져 오기시 모듈 자체에서 추가 할 필요없이 PowerShell에서 내부적으로 가져올 때 적절한 폴더가 dll 검색 경로에 추가됩니다.

문서 문제가 열려 있습니까?

우리는하지 않았습니다.

@TylerLeonhardt에 @adityapatwardhan @ SteveL - MSFT의 감사 (실수로) 나는 철저하게하려면이 너무 Windows 이외의 것들에 대한 작업에 대해 가지는 저를 생각 나게 ... 나는 더 완벽한 솔루션이 필요합니다.

현재 네이티브 interop이 .NET Core 자체에서 처리되어야하는 방법에 대한 명확한 문서가없는 것 같습니다. 내가 찾을 수있는 모든는 이 MS의 문서에서 .NET 프레임 워크에 대한 페이지입니다.

Mono 등을 통해 처리됩니까? Mono를 통하는 경우이 페이지를 보면 실제로 Mac OS의 Mono_에서 라이브러리로드 경로가 적절하게 존중되는 것을 방지하는 _bug가 있습니다.

PowerShell ...이를 처리해야합니다. 모듈 자체의 모든 플랫폼에서이를 적절하게 처리하는 방법이 있는지 잘 모르겠습니다.

@ vexx32 는 세부 정보를 모릅니다. PowerShell을 포함하지 않는 C #에서 재현을 생성 할 수 있다면 CoreCLR repo에서 문제를 여는 것이 좋습니다.

@ steveL-msft가 문제라고 생각합니다. 여전히 몇 가지 경고가 있지만 다른 곳에서는 잘 작동하는 것 같습니다. 예를 들어 기본 lib를로드하는 것은 기본 SkiaSharp.dll과 동일한 폴더에있는 경우 작동하지만 @adityapatwardhan이 언급 한 변경으로 인해 작동하지 않는 PS의 경우에는 작동합니다. 이는 PowerShell로 작업하는 경우와 모듈을 처리하는 방법의 어려움을 배가시킬뿐입니다.

이러한 네이티브 라이브러리로 작업하는 대부분의 상황에서는 지원되는 각 플랫폼에 대해 패키지화 할 수 있기 때문에 추상화 할 수 있습니다. 불행히도 검색 가능성과 최종 사용자 경험에 정말 나쁜 3 개 이상의 완전히 분리 된 갤러리 모듈을 패키지화하고 유지 관리하지 않는 한, PS 모듈에 대한 사치가 없습니다.

PS가 크로스 플랫폼 도구라는 점을 감안할 때 모듈에서 네이티브 라이브러리를 처리 할 수있는 방법이 필요하거나 PackageManagement 모듈이 nupkg에서 플랫폼별로 추출 된 별도의 라이브러리가 필요함을 인식하도록하는 방법이 필요합니다.

나는 대체 솔루션에 열려 있지만 여기에있는 데크는 꽤 부족한 것 같습니다. : 혼란 :

@ vexx32 나는 당신이 이런 것을 원한다고 생각합니다 https://github.com/PowerShell/PowerShellGet/issues/273

CoreFX 3.0에서는 pinoke 네이티브 라이브러리를위한 몇 가지 새로운 API를 얻습니다. 그들은 길의 시작에 불과하지만 Mono보다 더 나은 것을 원합니다.

현재 내 솔루션 해결 방법은 다음과 같습니다.

1. Mac 및 Linux 용 네이티브 라이브러리는 모듈 루트에 있습니다. 모듈 루트가 내가 배치 할 수 있고 현재 안정적으로로드 할 수있는 유일한 장소 인 것 같습니다.
2. ScriptsToProcess 는 모듈 가져 오기에서 p / invoke를 처리하여 32 비트 또는 64 비트 버전의 Windows 네이티브 라이브러리를 추가합니다.이 라이브러리는 파일 이름이 동일하므로 하위 폴더에 저장되어야합니다.

이상적이지 않고 @TylerLeonhardt 가 오늘날 그의 스트림에서 증명할 수

@ vexx32 는 세부 정보를 모릅니다. PowerShell을 포함하지 않는 C #에서 재현을 생성 할 수 있다면 CoreCLR repo에서 문제를 여는 것이 좋습니다.

아니요 : C #에서는 문제가되지 않습니다.

C #에서는 다음 중 하나를 수행합니다.

1. 앱을 개발하고 플랫폼별로 _ 별도의 설치 프로그램 _을 릴리스하고 걱정할 _ 하나의 라이브러리 검색 경로 _ 만 있으면됩니다.
2. 라이브러리를 개발하고 _NuGet 패키지 _를 릴리스하면 nuget이 라이브러리를 배치 할 위치를 알려주는 경로 패턴을 제공하면 studio / msbuild가 모든 것을 처리합니다.

@ vexx32 이 PowerShell / PowerShellGet # 273 과 같은 것을 원한다고 생각합니다.

아니요 : 이것은 크로스 플랫폼 문제가 아닙니다.

이것이이 버그가 제출 된 이유입니다. PowerShell 6.2 이후 @ vexx32 는 올바른 라이브러리 검색 경로를 사용하도록 PowerShell 을 얻는 방법을 알 수 없기 때문에 _just Windows_에서 작동하는 버전도 얻을 수 없습니다.

Windows에는 적어도 ap / invoke를 사용할 수 있습니다. 그것은 _ 해결 방법 _이지만 실제로 더 나은 수정이 필요합니다.

그러나 Unix 시스템에서는 _ 사용할 수있는 p / invoke_가 없습니다. 내가 찾을 수 있었던 것과 어떤 이유로 든 PowerShell은 일반적으로 DllImport를 시도 할 때 검색 할 경로를 나타내는 환경 변수를 쿼리하지 않습니다. PS에 의해로드 된 어셈블리.

그래서 기본적으로 모든 플랫폼에서 이것은 ... 무엇이든하기에는 매우 비우호적입니다. 😅

현재로서는 모듈 루트 폴더에 직접 모든 Unix 네이티브 어셈블리를 포함하는 것 외에 다른 옵션이없는 것 같습니다 (이는 이름 충돌이 발생할 수 있으므로 지원할 수있는 플랫폼을 제한 함). p / invoke를 사용하여 Windows의 검색 경로에 추가하는 폴더 (x86 Windows 지원에 관심이있는 경우- @TylerLeonhardt 는 이상한 이유로 Azure Functions가 x86에서 실행 주므로 작업하려는 경우 필요합니다. 그.)

이것은 플랫폼에 적합한 네이티브 바이너리를 미리로드하기 위해 psm1 파일에서 사용하는 것입니다. 참고 : Linux 및 Windows에서만 이것을 대상으로 / 테스트했습니다.

# Module PSM1 File
$binPath = Join-Path $PSScriptRoot bin $(if ($IsWindows) {"Windows"} else {"Linux"})
Add-Type -Path $binPath\Acme.Api.dll

그리고 이것은 Acme.Api.dll에 들어가는 C # 코드입니다.

[Flags]
public enum DLOpenFlags
{
    RTLD_LAZY = 1,
    RTLD_NOW = 2,
    RTLD_LOCAL = 4,
    RTLD_GLOBAL = 8,
}

public static class LinuxNativeMethods
{
    [DllImport("libdl.so", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
    public static extern IntPtr dlopen(
        string dlToOpen, 
        DLOpenFlags flags);
}

public static class Win32NativeMethods
{
    [DllImport("kernel32.dll", EntryPoint="LoadLibraryW")]
    public static extern IntPtr LoadLibrary(
        [InAttribute, MarshalAs(UnmanagedType.LPWStr)] string dllToLoad);
}

public static class FooNativeMethods
{
    // On Linux/macOS the shared lib must be named Foo.so and not libFoo.so
    public const string LibName = "Foo";

    static FooNativeMethods()
    {
        string assemblyDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);

        if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) 
        {
            string nativeDllPath = Path.Combine(assemblyDir, "Windows", $"{LibName}.dll");
            LibHandle = Win32NativeMethods.LoadLibrary(nativeDllPath);
        }
        else
        {
            string nativeSOPath = Path.Combine(assemblyDir, "Linux", $"{LibName}.so");
            LibHandle = LinuxNativeMethods.dlopen(nativeSOPath, DLOpenFlags.RTLD_LAZY);
        }
    }

    public static IntPtr LibHandle { get; private set; }

    [DllImport(LibName, CallingConvention = CallingConvention.Cdecl)]
    public static extern int getLastError(
        StringBuilder buffer,
        ref int bufferLength);

    ...
}

@ vexx32 CoreCLR 저장소에서 컨설팅 문제를 열 ​​수 있습니다. 나는 그들이 할 말이 있다고 생각합니다.

@rkeithhill 이것은 .NET 바이너리에서만 작동합니다. 네이티브 어셈블리를로드하기 위해 P / invoke를 사용해야하는 .NET 바이너리를로드해야합니다. 그것이 실패하고 완전히 무너지는 곳입니다. 이 라이브러리를 제어 할 수 없으며 타사 라이브러리 (이 경우 SkiaSharp)입니다. 이 라이브러리는 내 모듈에서 코드가로드되는 동시에로드되어야하므로이 라이브러리를 내 바이너리 모듈에로드 할 수 없습니다. 내 모듈은 SkiaSharp가로드 된 상태에서만 존재하고 작동하는 유형에만 의존하기 때문입니다.

@isazonov 는 지금이 문제에서 몇 번 다루었 .net Core에서는 문제가되지 않습니다 .

PowerShell은이 작업을 수행 할 수있는 가능한 방법이 없으며 라이브러리 검색 경로에서 일부 표준 경로를 우연히 제거 하여 일부 컨텍스트에서 네이티브 어셈블리로 작업하는 것이 문자 그대로 불가능하게 만들며 매우 취약하고 특히 작업.

뿡뿡

네이티브 어셈블리를로드하기 위해 P / invoke를 사용해야하는 .NET 바이너리를로드해야합니다. 그것이 실패하고 완전히 무너지는 곳입니다.

어, 그게이 코드는 바로 이러한 것입니다. 한동안 Windows와 Linux 모두에서 6.2에서 성공적으로 사용했습니다.

수정, 죄송합니다. 명확하지 않았습니다. 내 바이너리에서는이 작업을 수행 할 수 없습니다. 내 모듈이로드 될 때 유형이 있어야합니다. 명령 인스턴스화 중에 가져올 수 없습니다 .... 그럴 필요도 없습니다.

바이너리를로드 할 때 PowerShell은 .net 코어 보다 기능 이 떨어지면 안됩니다.

즉, 몇 가지 사항을 적용하고 해결 방법을 개선 할 수 있는지 살펴 보겠습니다. 예를 감사하십시오!

하지만 정말 ...이 문제를 해결하기 위해 왜 그렇게 시간을 투자해야하는지 모르겠습니다. 작동해야하고 PowerShell이 ​​개입 될 때까지 ... 작동합니다.

후프가 고통이라는 데 동의했습니다. Windows 및 Linux에서 p / invoke를 통해 네이티브 lib로드를 수행하는 방법을 보여 주려고했습니다. :-)

@ vexx32 토론에서 분할이 보입니다. 이것이 문제라는 점을 명확히 해주실 수 있습니까? 네이티브 라이브러리가있는 모듈이 있고 특정 플랫폼에 대한 종속성이있는 올바른 라이브러리를로드해야합니까?

일종의. 이것은 현재 작동하는 레이아웃이지만 모든 것이 지저분합니다. p / invoke를 통해 경로를 정의 할 수없는 것은 모듈 루트에 있어야합니다 (일부 플랫폼에서 이름 충돌 문제가 발생 함).

PSWordCloud/
|- PSWordCloudCmdlet.dll
|- SkiaSharp.dll
|- libSkiaSharp.so
|- libSkiaSharp.dylib
|- win-x86/
  |- libSkiaSharp.dll
|- win-x64/
  |- libSkiaSharp.dll

SkiaSharp.dll 은 .NET이며 내 주 cmdlet dll에 대한 참조 어셈블리입니다. 4 개의 libSkiaSharp 파일은 기본 플랫폼 별 DLL입니다. SkiaSharp.dll의 코드를 제어하지 않기 때문에 DLL이 p / invokes 전에 경로를 업데이트하도록 강제 할 수 없습니다.

그래서 ... .NET 종속성을 가진 모듈이 있습니다. 이 종속성은 DllImport로로드하는 기본 라이브러리에 따라 다릅니다. 정확한 파일은 플랫폼 / 아키텍처에 따라 다릅니다 (그러나 일부 파일에는 이름 충돌이 있으므로 실제로 지원할 수있는 플랫폼을 제한합니다).

@rkeithhill 의 코드를 사용하면 Linux 네이티브 라이브러리도 하위 폴더로 이동할 수 있다고 생각합니다. MacOS에 대해 확실하지 않지만 비슷한 것이있을 수 있지만 아직 방법에 대한 문서를 찾지 못했습니다.

_ 이상적으로 _, 이러한 모든 파일은 /PSWordCloud/runtime/<platform>/ 와 같은 하위 폴더에 최악의 상태 여야합니다. 모듈의 폴더는 DllImport를 통해로드 할 수 있습니다. 다른 위치는 작동 할 수 있지만 (최소한 Mac / Linux에서는) 기본 런타임로드 경로를 정의해야하는 플랫폼의 모든 환경 변수가 PowerShell에서 완전히 무시됩니다.

나는 $env:Path 여전히 작동한다고 생각하지만 (유닉스 플랫폼에서 사용해서는 안되며 6.2 릴리스 이후로 테스트하지 않았으므로 문제가 발생할 수 있음) 솔직히 나는 그렇지 않습니다. 해당 변수에 많은 경로를 추가하는 것이 좋은 생각이라고 생각합니다. 사용자가 해당 환경 변수를 사용해야하는 경우 정말 끔찍한 사용자 경험을 제공합니다. 모듈을로드하고 갑자기 경로 변수에있을 수없는 예상치 못한 추가 데이터가 있지만 올바르게 작동하려면 _has_ 있어야합니다.

나는 이것이 문제가되지 않을 것이라고 생각한다. .NET Core의 미리 정의 된 메서드를 재정의 할 경우 PowerShell에는 네이티브 라이브러리로드 경로를 처리하는보다 강력한 방법이 있어야합니다. 모듈 매니페스트에 네이티브 라이브러리로드 경로를 지정하거나 해당 라인을 따라 무언가를 지정하는 방법, 일부 네이티브 코드를 p / 호출해야 할 때 플랫폼별로 찾을 위치를 정의하는 방법을 제안합니다.

동일한 문제가 있으며 @ vexx32 의 보고서에는 체인의 모든 요소가 포함되어 있습니다.
PowerShell이 ​​네이티브 라이브러리를 처리하는 더 강력한 방법을 가져야한다는 데 동의합니다.

나는 그 변수에 많은 경로를 추가하는 것이 전혀 좋지 않다고 생각합니다.

동의하고 마찬가지로 저는 SetDllDirectory 를 사용하는 데 열중하지 않습니다. 왜냐하면 (pwsh) 프로세스 전체이기 때문입니다. 모듈 매니페스트는 모듈 작성자가 os-arch 콤보별로 네이티브 dll 목록을 제공 할 수 있도록 업데이트 할 수 있으며, 그러면 pwsh는 어셈블리를 미리로드하기 전에 해당 네이티브 dll을 미리로드합니다. 누군가가 조립 정말 그 자신의 네이티브 DLL을 미리로드한다, 다른 언어에서 어셈블리를 사용하려고하는 경우 즉, 말했다. 어셈블리 사용자는 IMO를 수행 할 필요가 없습니다.

@ vexx32 I "생각" dlopen 는 macOS에서도 작동합니다.

할 수있을 때 시도해 보겠습니다 (mac VM은 약간 ... 이상합니다).하지만 메모리에서 Mac은 .so 파일을 사용하지 않으므로 시도해 보겠습니다. -Mac에서 참조하는 대부분의 네이티브 라이브러리는 .dylib 것 같습니다.

어셈블리는 여기에서 자체 사전로드를 수행합니다 (적어도 확실합니다 ...). 어셈블리가 PS가 경로를 처리하는 방법을 볼 수있는 위치를 모르기 때문에 모든 것을 특수 케이스로 처리해야합니다. : /

macOS는 .dylib 하므로 다음과 같이 정의 된 다른 매크로로 해당 어셈블리를 세 번 컴파일해야합니다.

public static class FooNativeMethods
{
    // This unfortunately requires that you compile this assembly twice - once with WIN32 defined and again with
    // it not defined.
#if WIN32        
    public const string LibName = "Foo";
#elif MACOS
    public const string LibName = "libFoo.dylib";
#else
    public const string LibName = "libFoo.so";
#endif      

이것은 netstandard2 어셈블리이기 때문에 각 플랫폼에 대해 이것을 다시 컴파일 할 필요가 없었 으면합니다. 그러나 AFAICT는 DllImport 속성에 제공된 lib 이름 값이 컴파일 시간 상수 여야합니다. :-(

네. 이것은 PowerShell 모듈이기 때문에 실제로 수행 할 작업은 플랫폼 검사를 사용하여 Add-Type -TypeDefinition $srcString 사용하여 가져 오기시 동적 컴파일을 수행 한 다음 올바른 디렉터리를 가리키는 것입니다. 고맙게도 모듈 매니페스트에서 ScriptsToProcess 를 사용할 수 있습니다.

또한 libdl.so 는 MacOS에서이 작업을 수행 할 수있는 유효하고 사용 가능한 라이브러리입니까?

하지만 더 나은 솔루션이 필요합니다. 😄

@ vexx32 모노 MapDll 보셨나요? 이 기능을 사용하면 조건 (아치, 플랫폼 등)에 따라 적절한 네이티브 라이브러리에 자동 매핑 할 수 있습니다. 나는 당신이 필요하다고 생각합니다. SkiaSharp.dll을 다시 컴파일해야하지만 외부 구성 파일에서 구성 할 수 있습니다. 유사한 것이 Core에서 구현됩니다.

올바르게 기억하면 .NET Core는 Windows에서 실행할 때 Mono를 사용하지 않으므로 다시 부분적인 솔루션 일뿐입니다.

여기에 제공되는 모든 옵션에 감사 드리며 현재 옵션이 무엇인지 철저히 조사 할 것입니다.하지만 결국에는 PowerShell이이 목적을 위해 사용할 크로스 플랫폼 모듈을위한 무언가를 마련해야합니다. . 🙂

올바르게 기억하면 .NET Core는 Windows에서 실행할 때 Mono를 사용하지 않으므로 다시 부분적인 솔루션 일뿐입니다.

나는 새로운 기능에 대해 말합니다. 보다
Dllmap 디자인 문서 https://github.com/dotnet/coreclr/blob/c3e1bd5ccc482c9a7670762676bda95ebd34707d/Documentation/design-docs/dllmap.md
및 이전 버전의 문서
https://github.com/dotnet/coreclr/blob/6a48f05c77e80b604d71a9b84cc6b014306e849e/Documentation/design-docs/dllmap.md#

업데이트 : CurrentContextualReflectionContext
https://github.com/dotnet/designs/blob/master/accepted/runtime-binding.md#rollforward

뿡뿡

이것은 netstandard2 어셈블리이기 때문에 각 플랫폼에 대해 이것을 다시 컴파일 할 필요가 없었 으면합니다. 그러나 AFAICT DllImport 속성에 제공된 lib 이름 값은 컴파일 시간 상수 여야합니다. :-(

FWIW DllImport 대한 확장자를 생략 할 수 있습니다. PSES의 비 Windows 기본 종속성에 대해 그렇게합니다. 기본 이름이 동일하지 않으면 도움이되지 않습니다.

별도의 인터페이스 구현에 저장하여 LoadLibrary / dlopen 호출에 대한 컴파일러 지시문을 건너 뛸 수도 있습니다. 메소드가 JIT가 아닌 한 런타임에 던져서는 안됩니다.

이 문제에 대한 가능한 해결책을 찾았습니다. 나는 그것을 시도해야 할 것입니다. 현재 일부 릴리스 작업에 바쁘기 때문에 다음 주 초에이 작업을 수행 할 가능성이 높습니다. 이 문제를 발견 한 내용으로 업데이트하겠습니다.

https://docs.microsoft.com/en-us/dotnet/api/system.runtime.loader.assemblyloadcontext.loadunmanageddll?view=netcore-2.2#System_Runtime_Loader_AssemblyLoadContext_LoadUnmanagedDll_System_String_

@adityapatwardhan LoadLibrary / dlopen을 둘러싼 크로스 플랫폼 래퍼처럼 보입니다. 좋은 발견!

@adityapatwardhan LoadUnmanagedDll 에서이 문제를 발견했습니다. 우리의 경우에는 별 의미가 없을 수도 있습니다.

사람들이 관리되지 않는 라이브러리에 대한 사용자 지정 해결 정책을 제공 할 수 있도록 콜백을 추가하는 것을 고려해야합니다. AssemblyLoadContext.LoadUnmanagedDll을 사용하여이를 수행하려고했습니다. 결국 기본로드 컨텍스트에서 작동하지 않기 때문에 문제의 일부만 해결했습니다. 원래 AssemblyLoadContext.LoadUnmanagedDll을 도입했을 때 기본로드 컨텍스트도 재정의 할 수 있었지만이 기능을 제거하고 모든 시나리오에 미치는 영향을 고려하지 않았습니다.

출처 : .so 파일이 응용 프로그램 출력 디렉토리가 아닌 다른 경로에 있으면 Linux에서 LoadUnmanagedDllFromPath / LoadUnmanagedDll이 작동하지 않습니다.

위의 NativeLibrary API 링크가 크로스 플랫폼 솔루션을 제공한다고 생각합니다 (.Net Core 3.0으로 이동 한 후).

CurrentContextualReflectionContext https://github.com/dotnet/coreclr/blob/master/Documentation/design-docs/AssemblyLoadContext.ContextualReflection.md

플러그인 모델 용입니다. 이렇게하면 # 6724, # 6426 등의 문제가 해결 될 수 있습니다.
/ cc @ daxian-dbw

@adityapatwardhan 지난달 이후의 업데이트가 있습니까? 이에 대한 올바른 문서 지침을 게시하고 싶습니다.

이것에 집중할 수 없었고, 현재 다른 높은 우선 순위 항목으로 바쁘다. 다음 주에 업데이트하겠습니다.

@adamdriscoll 은 아마도 UniversalDashboard 및 AvaloniaUI + PowerShell에서 창의적인 작업을 수행해야했기 때문에 조언을 해줄 수있을 것입니다.

FWIW 위에서 제시 dlopen pinvoke를 조정하고 Mac에서 공유 lib의 이름을 변경하는 것 외에는 작동합니다. 이것은 .NET Core 2.2에 있습니다.

UD는 @rkeithhill 의 솔루션과 수행 합니다. 이것은 Linux 및 Windows뿐만 아니라 MacOSX에서도 작동합니다. https://github.com/ironmansoftware/universal-dashboard/blob/master/src/UniversalDashboard/Server/CustomAssemblyLoadContext.cs

문제는 다양한 바이너리를로드하기 위해 폴더 경로에 더 많은 변형이있을 수 있으므로 약간의 kluge입니다. 새 이진 유형이 새 종속성을 기반으로 출력되는 경우 새 폴더가 팝업되고 UD가 어셈블리를로드하지 않습니다.

@rkeithhill 모든 WindowsLinux 바이너리를 단일 폴더로 병합하고 있습니까? (편집 : 사실, 알겠습니다. 대상 네이티브 어셈블리 만로드하는 래퍼 DLL 어셈블리가 있습니다. 모든 네이티브 어셈블리에 대해이 작업을 수행합니까?)

UD는 게시 런타임 폴더를 dotnet publish로 생성했을 때와 동일하게 유지 한 다음 참조 된 클래스가 올바른 플랫폼 아키텍처를 기반으로 모든 네이티브 바이너리를로드하려고합니다.

작동하지만 PS가 런타임 폴더를보고 올바른 바이너리를로드 할 수 있기를 바랍니다. dotnet이 시작될 때 그렇게 해야하는 것처럼 보이므로 거기에 코드가있을 수 있습니다.

결과 RuntimeInformation.IsOSPlatform(OSPlatform.Windows) 에 따라 네이티브 어셈블리를 찾는 위치를 변경합니다. true가 반환되면 C # 어셈블리가있는 디렉터리의 Windows 폴더에서로드합니다. 그렇지 않으면 Linux 폴더에서로드합니다.

모든 네이티브 어셈블리에 대해이 작업을 수행합니까?)

예,하지만 우리는 하나만 가지고 있으며 시스템 라이브러리 (msvcrt 등) 이외의 다른 것에 의존하지 않습니다.

표준 파일 구조를 가질 수 있습니까 (런타임 이름을 기반으로 할 수 있음)? 이것은 우리가 네이티브 dll 리졸버를 향상시킬 수 있도록합니다.

UD는 게시 런타임 폴더를 dotnet publish로 생성했을 때와 동일하게 유지 한 다음 참조 된 클래스가 올바른 플랫폼 아키텍처를 기반으로 모든 네이티브 바이너리를로드하려고합니다.

따라서 내가 올바르게 이해하고 있다면 RID 별 네이티브 바이너리에 의존하는 관리 바이너리를로드 할 때 .NET이 내부 바이너리를로드하도록함으로써 PowerShell을 사용하여 네이티브 바이너리를로드하는 것을 피하는 것입니까?

작동하지만 PS가 런타임 폴더를보고 올바른 바이너리를로드 할 수 있기를 바랍니다. dotnet이 시작될 때 그렇게 해야하는 것처럼 보이므로 거기에 코드가있을 수 있습니다.

예, .NET 런타임 자체에서 발생하는 RID 인식이 있다고 생각합니다. 나는 우리가 그 길로 가야하는 것을 피하려고 노력해 왔지만, 언젠가는 그럴 필요가있을 것 같다.

헉헉

따라서 내가 올바르게 이해하고 있다면 RID 별 네이티브 바이너리에 의존하는 관리 바이너리를로드 할 때 .NET이 내부 바이너리를로드하도록함으로써 PowerShell을 사용하여 네이티브 바이너리를로드하는 것을 피하는 것입니까?

예 바로 그 거예요. UD는 대상 RID에 대한 모든 것을로드합니다. 따라서 실제 종속성이 무엇인지에 대해서는 실제로 현명하지 않습니다. 그것을 감지하는 좋은 방법이 있는지 확실하지 않습니다.

@ vexx32 PSWordCloud를 설치했습니다. 폴더 구조가 일반적인가요? 그렇다면 리졸버를 더 똑똑하게 만들 수 있습니다. 제가 물어보고 싶은 경우에-단순화 된 PSWordCloud를 기반으로 새로운 Pester 테스트를 준비해 주시겠습니까 ( "Hello World"와 같은 네이티브 라이브러리에서 간단한 것을 얻을 수있는 것으로 충분합니다)? 이를 보류 중으로 병합하면 리졸버에서 작업 할 수있는 방법이 열립니다. 감사!

현재 PSWordCloud의 폴더 구조는 일반적이지 않습니다. 물론 변경할 수 있습니다.

네, 간단한 시험대를 만들 수 있습니다. Pester는 내가 생각하는 출력의 특성에 따라 약간 까다 롭지 만 실패하면 잡을 수있는 예외를 생성하지만 올바르게 기억하면 해당 예외가 유형 이니셜 라이저에서 throw됩니다.

테스트 자체가 dotnet을 통해 Skia DLL을 가져 오는 것이 적절할까요, 아니면 리포지토리에 패키징하는 것이 더 좋을까요? 더 이상 보류 중이 아니라면 기능 테스트로 표시되면 그렇게 큰 문제가 아닌 것 같습니다. :생각:

Skia dll과 간접적 인 의존성을 가진 테스트 결절을 구현할 수 있다면 좋을 것입니다. 그리고 예, Nuget에서 Skia를 설치할 수 있습니다. 테스트 모듈과 함께 dll을 ~ our test module folder ~ assert 폴더에 직접 넣으면 테스트가 더 신뢰할 수 있습니다.
Nuget의 모범 사례는 RID라는 이름의 폴더에 네이티브 dll을 넣는 것 같습니다. 예?

네, 할 수 있습니다! 내일 살펴 보겠습니다. :붉히다:

내 의견을 업데이트했습니다. 테스트 모듈을 테스트 어설 션 폴더에 넣으십시오.

@rjmholt PSWordCloud에서 작동하도록 제공 한 코드를 사용하려고 시도했지만 여전히 전혀 작동하지 않습니다. 로드 작업은 성공적으로 완료되지만 관리되지 않는 라이브러리가 Unix 플랫폼에서로드 된 DLL을 사용하는 데 여전히 실패한 후 관리되는 SkiaSharp.dll을로드합니다. 그러나 어떻게 든 Windows에서 작동합니다.

https://github.com/vexx32/PSWordCloud/tree/FixPInvokes-$ build.ps1 를 실행하여 모듈을 빌드하고 모든 파일을 올바른 위치에 배치하십시오. 모듈도 가져옵니다. 빌드를 실행 한 후 New-WordCloud 호출은 Windows에서 작동하지만 Mac OS에서는 완전히 실패합니다.

@SeeminglyScience 당신은 내가 거기에서 잘못한 것을

GitHub

vexx32 / PSWordCloud

PowerShell로 예쁜 단어 구름을 만드세요! GitHub에서 계정을 만들어 vexx32 / PSWordCloud 개발에 기여하세요.

@ SteveL-MSFT 현재 네이티브 라이브러리를 처리하기위한 계획은 무엇입니까? 😕

: tada :이 문제는 # 11032에서 해결되었으며 현재 v7.0.0-rc.1 . : tada :

편리한 링크 :

• 릴리즈 노트