@adityapatwardhan क्या आप इस पर एक नज़र

आप procmon उपयोगिता के साथ उपयोग किए गए पथ देख सकते हैं और फिर HintPath के साथ ठीक करने का प्रयास कर

मैं इसे एक लुक दूंगा, लेकिन यह दी गई लाइब्रेरी नहीं है जिसे मैं सीधे लोड कर रहा हूं (यह मुख्य SkiaSharp.dll द्वारा ही लोड किया गया है) मैं बहुत अधिक ऐसा करने में आश्वस्त नहीं हूं। तथ्य यह है कि प्लेटफॉर्म के आधार पर लोड करने के लिए चार संभावित पुस्तकालय फाइलें भी हैं जो चीजों को जटिल बनाती हैं।

लेकिन परवाह किए बिना, यह एक जानबूझकर परिवर्तन की तरह प्रतीत नहीं होता है इसलिए प्रतिगमन को संभवतः संबोधित किया जाना चाहिए।

MSFT टीम .नेट कोर 3.0 में vNext p / invokes पर कड़ी मेहनत करती है और शायद उन्होंने 2.1 में कुछ वापस पोर्ट किया है। मुझे याद नहीं है कि हमने PowerShell से संबंधित dll लोडिंग में कुछ भी बदला है।

6.2.0-प्रीव्यू 2 में # 8073 और कई Internal -मार्क परिवर्तन हुए। मुझे नहीं पता कि उन लोगों के दौरान और क्या बदल सकता है। 😕

पीआर परिवर्तन मॉड्यूल फ़ोल्डर से मॉड्यूल डीएल को लोड करने के लिए पहले जीएसी से है। आपकी समस्या यह है कि मॉड्यूल dll संदर्भ दूसरा dll और ऑटो dll लोड हो रहा है (यह कोर नहीं PowerShell करता है) dll नहीं मिला। मेरा सुझाव स्पष्ट रूप से प्रोजेक्ट फ़ाइल में hllpath को 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 / इनवॉइस प्रयोजनों के लिए अन्य DLL लोड करने का प्रयास करता है।

_That_ HintPath केवल संकलन-समय है।

जिस तरह से आप कहते हैं कि यह आवाज़ करता है जैसे कि एक और मैं याद किया है?

@ vexx32 यदि आपके पास सरल रेपो कोड है तो आप CoreCLR रिपॉजिटरी में पूछ सकते हैं।

अगर मैं अभी तक एक पॉवर्सशेल-विशिष्ट परिवर्तन को नियंत्रित कर सकता हूं, तो मैं अनिश्चित हूं। मुझे कंसोल ऐप के लिए एक साथ एक छोटी सी परीक्षा देनी होगी और देखना होगा कि वह कैसे जाती है।

@ जेकुल से एक टिप के लिए धन्यवाद, मैं एक स्टॉप-गैप समाधान को एक साथ रखने में कामयाब रहा। Cmdlet और मुख्य Skia DLL को आयात करने से पहले PSM1 से इसे निष्पादित करना समस्या को हल करने के लिए लगता है।

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)

हालाँकि, यह तथ्य कि यह काम करने के लिए _requires_ अतिरिक्त 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 स्थापित करते हैं, तो विशेष रूप से आपको विफलता दिखाई देगी, क्योंकि इसमें उपरोक्त पी / इनवोक वर्कअराउंड की कमी है।

ठीक है, मैं अब फटकार लगा सकता हूं। में देख लूंगा।

@ vexx32 ऐसा लगता है कि हम FileList psd1 में सूचीबद्ध सभी फ़ाइल लोड करते हैं। क्या आपको ऐसा करने की आवश्यकता है? जब मैंने FileList से सभी प्रविष्टियाँ निकाल दीं, तो मैं इस मुद्दे को और नहीं हटा सकता।

ऐसा क्या? यह बहुत अजीब है। नहीं, मुझे विशेष रूप से इसकी आवश्यकता नहीं है और शायद इसे वैसे भी हटा दूंगा क्योंकि मैं वास्तव में इसे लगातार अपडेट नहीं करना चाहता, लेकिन यह कुछ संस्करणों के लिए रहा है।

अजीब लगता है कि यह DLL लोडिंग को अचानक प्रभावित करेगा, हालाँकि।

ऐसा लगता है कि हम psd1 के फ़ाइललिस्ट में सूचीबद्ध सभी फ़ाइल लोड करते हैं।

हमारे पास .psd1 फ़ाइलों में "if" का समर्थन करने के लिए एक समस्या है। इसलिए हम प्लेटफ़ॉर्म विशिष्ट dll को लोड कर सकते हैं।

@iSazonov यह # 5541 है । मैं जल्द ही आपको अपडेट दूंगा।

यह एक संभावना है। मैं क्या सोच रहा हूं _now_ अगर फाइललिस्ट में केवल मूल पुस्तकालयों (उन सभी) के लिए मार्ग जोड़ना है, तो यहां पर्याप्त है ... मुझे पी / इनवोक की आवश्यकता भी नहीं हो सकती है। मैं कुछ परीक्षण करूँगा! 😊

संपादित करें: नहींं, मैं नहीं देख रहा हूँ कि कोई प्रभाव है। :(

हम Assembly.Load() कॉल करते हैं जो केवल प्रबंधित असेंबलियों को लोड करता है।

हमने 6.2.0-प्रीव्यू 2 में एक बदलाव किया, जहां हमने GAC में देखने से पहले मॉड्यूल फ़ोल्डर से DLL लोड करना शुरू कर दिया। उस परिवर्तन का साइड इफ़ेक्ट यह है कि हम फाइललिस्ट में DLL भी लोड करते हैं।

यह समझ आता है। क्या हमारे पास इसके लिए कोई डॉक इश्यू खुला है? ऐसा लगता है कि इस प्रकार का परिवर्तन जो किसी में चलता है, तो उसे ट्रैक करना बहुत कठिन होगा और हमने इसे प्रलेखित नहीं किया है। हमें शायद इस बात का दस्तावेज़ देना चाहिए कि आप मूल असेंबलियों को उस कारण के लिए फाइललिस्ट में नहीं रखना चाहते हैं।

इसे ट्रैक करने में मदद की सराहना करें! अभी के लिए पी / इनवोक सॉल्यूशन का मैंने उल्लेख किया है जो मुझे सबसे अधिक लचीलापन देता है, लेकिन मॉड्यूल लोडिंग में ऐसी चीजों के लिए हैंडलिंग को जोड़ना समझदार हो सकता है।

उदाहरण के लिए, मान लें कि PrivateData में हम RuntimeLibPaths नामक एक प्रविष्टि जोड़ते हैं, जो एक हैशटेबल है जहाँ कुंजियाँ समर्थित प्लेटफ़ॉर्म नामों / आर्किटेक्चर से मेल खाती हैं, और मान मूल लाइब्रेरी वाले फ़ोल्डर के लिए पथ हैं। उपयुक्त फ़ोल्डर (ओं) को आयात पर मॉड्यूल द्वारा खुद को जोड़ने के बजाय आंतरिक रूप से PowerShell द्वारा आयात पर dll खोज पथ में जोड़ा जाता है।

क्या हमारे पास इसके लिए कोई डॉक इश्यू खुला है?

हमने नहीं किया।

@adityapatwardhan @ SteveL-MSFT @TylerLeonhardt (अनजाने में) मुझे यह याद दिलाने के लिए कि यह गैर-विंडोज चीजों पर भी काम करना है, अगर मैं पूरी तरह से बनना चाहता हूं ... तो मुझे और अधिक संपूर्ण समाधान चाहिए।

वर्तमान में कोई स्पष्ट दस्तावेज नहीं दिखता है कि नेट कोर ही में देशी इंटरॉप को कैसे संभाला जाना चाहिए। सभी मैं पा सकता हूँ यह पृष्ठ MS डॉक्स में .NET फ्रेमवर्क के लिए है।

क्या यह मोनो या कुछ के माध्यम से नियंत्रित किया जाता है? यदि यह मोनो के माध्यम से है, तो इस पृष्ठ को देखते हुए वास्तव में मैक ओएस पर मोनो में _bug है जो लाइब्रेरी लोड पथों को उचित रूप से सम्मानित करने से रोकता है ...

PowerShell ... को इसे संभालने की आवश्यकता है। मुझे यकीन नहीं है कि _is_ इस तरह से मॉड्यूल से सभी प्लेटफार्मों से उचित तरीके से निपटने का एक तरीका है।

@ vexx32 को विवरण नहीं पता है, यदि आप C # में एक

@ steveL-msft यह मुद्दा है, मुझे लगता है। यह कहीं और ठीक काम करने के लिए लगता है, अभी भी कुछ चेतावनी के साथ। उदाहरण के लिए, यदि यह एक ही फ़ोल्डर में मुख्य SkiaSharp.dll के रूप में है, लेकिन मूल lib को लोड करना काम करता है, लेकिन PS के लिए जो @adityapatwardhan में परिवर्तन के कारण काम नहीं करता है। यह सिर्फ PowerShell के साथ काम करने के मामले में कठिनाई को गुणा करता है और यह मॉड्यूल को कैसे संभालता है।

ऐसी मूल पुस्तकालयों के साथ काम करने की अधिकांश स्थितियों में इसे दूर किया जा सकता है, क्योंकि आप इसे प्रत्येक समर्थित प्लेटफॉर्म के लिए वैसे भी पैकेज कर सकते हैं। जब तक मैं पीएस मॉड्यूल्स के लिए लक्जरी नहीं है, जब तक कि मैं पैकेज या तीन या अधिक पूरी तरह से अलग गैलरी मॉड्यूल को बनाए रखना नहीं चाहता, जो दुर्भाग्य से खोज और अंतिम उपयोगकर्ता अनुभव के लिए वास्तव में खराब है।

यह देखते हुए कि PS एक क्रॉस प्लेटफ़ॉर्म टूल है, हमें मॉड्यूल में देशी पुस्तकालयों को संभालने के लिए किसी तरह की आवश्यकता है, या हमें पैकेजमैनेजमेंट मॉड्यूल को पहचानने के लिए किसी तरह की आवश्यकता है कि वहाँ अलग-अलग पुस्तकालयों को nupkg से प्रति-प्लेटफ़ॉर्म के आधार पर निकालने की आवश्यकता है।

मैं वैकल्पिक समाधान के लिए खुला हूँ, लेकिन ऐसा लगता है कि यहाँ डेक बहुत दुर्लभ है। : भ्रमित:

@ vexx32 मुझे लगता है कि आप कुछ इस तरह चाहते हैं https://github.com/PowerShell/PowerShellGet/issive/3/3

CoreFX 3.0 में हम देशी पुस्तकालयों को पिनोक करने के लिए कुछ नए एपीआई प्राप्त करते हैं। वे केवल सड़क की शुरुआत में हैं, लेकिन वे मोनो से भी बेहतर कुछ करना चाहते हैं।

वर्तमान में मेरा समाधान समाधान इस तरह दिख रहा है:

1. मैक और लिनक्स के लिए मूल पुस्तकालय मॉड्यूल रूट में हैं, क्योंकि ऐसा लगता है कि केवल एक ही जगह है जो मैं उन्हें डाल सकता हूं और फिलहाल उन्हें मज़बूती से लोड कर सकता हूं।
2. विंडोज देशी पुस्तकालय के 32 या 64-बिट संस्करण को जोड़ने के लिए मॉड्यूल आयात पर एक ScriptsToProcess पी / इनवोक है, जो कि फ़ाइल नाम के रूप में सबफ़ोल्डर में संग्रहीत किया जाना चाहिए, दुर्भाग्य से, समान है।

आदर्श नहीं है, और जैसा कि @TylerLeonhardt आज अपनी स्ट्रीम से

@ vexx32 को विवरण नहीं पता है, यदि आप C # में एक

नहींं: C # में यह कोई समस्या नहीं है

C # में आप या तो:

1. एक एप्लिकेशन विकसित करें, और प्रति प्लेटफ़ॉर्म _separate इंस्टॉल करें। और इसके बारे में चिंता करने के लिए केवल _one लाइब्रेरी खोज पथ_ है।
2. एक पुस्तकालय विकसित करें, और _NuGet package_ को रिलीज़ करें, और nuget आपको एक पथ प्रतिरूप देता है जिसमें आपको बताया जाता है कि आपको अपनी लाइब्रेरी कहाँ रखनी है, और फिर स्टूडियो / msbuild आपके लिए हर चीज़ का ध्यान रखता है।

@ vexx32 मुझे लगता है कि आप कुछ इस तरह चाहते हैं PowerShell / PowerShellGet # 273

नहींं: यह एक क्रॉस-प्लेटफॉर्म समस्या नहीं है

इसलिए यह बग दायर किया गया था। जब से PowerShell 6.2 @ vexx32 को भी ऐसा संस्करण नहीं मिल सकता है, जो _just Windows_ में काम करता है, क्योंकि वह सही लाइब्रेरी खोज पथ का उपयोग करने के लिए PowerShell प्राप्त करने के तरीके का पता नहीं लगा सकता है।

विंडोज में कम से कम एपी / इनवोक उपलब्ध है जो मुझे इसके साथ गड़बड़ करने देता है। यह एक _workaround_ है, लेकिन वास्तव में हमें एक बेहतर समाधान की आवश्यकता है।

यूनिक्स प्रणालियों पर, हालांकि, _इस तरह का कोई p / invoke_ उपलब्ध नहीं है, जो मुझे मिल रहा है, और जो भी कारण से PowerShell ने पर्यावरण चर को क्वेरी नहीं की है, जो सामान्य रूप से इंगित करता है कि जब आप DllIport से प्रयास करते हैं तो खोज करने के लिए कौन से रास्ते हैं पीएस द्वारा भरी गई एक सभा।

तो मूल रूप से सभी प्लेटफार्मों पर यह है ... बेहद के साथ कुछ भी करने के लिए अमित्र। 😅

जैसा कि वर्तमान में यह खड़ा है कि मॉड्यूल रूट फ़ोल्डर में किसी भी और सभी यूनिक्स देशी विधानसभाओं को शामिल करने के अलावा कोई अन्य विकल्प नहीं है (जो आपके द्वारा समर्थित प्लेटफॉर्म को सीमित कर सकता है, जैसा कि अक्सर नाम टकराव हो सकता है), और फिर जिसके बारे में सावधान रहना फ़ोल्डर जिसे आप पी / इनवॉइस के साथ विंडोज पर खोज पथों में जोड़ते हैं (यदि आप x86 विंडोज का समर्थन करने के बारे में परवाह करते हैं - और एज़्योर फ़ंक्शंस x86 पर कुछ अजीब कारण से चलता है, इसलिए यह आवश्यक है कि आप के साथ काम करना चाहते हैं उन।)

यह वह है जो मैं अपने psm1 फ़ाइल में प्लेटफ़ॉर्म के लिए उपयुक्त देशी बाइनरी को पूर्व-लोड करने के लिए उपयोग करता हूं। नोट: मैंने इसे केवल लिनक्स और विंडोज पर लक्षित / परीक्षण किया है:

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

और यह C # कोड है जो Acme.Api.dll में जाता है

[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 बायनेरिज़ के लिए काम करता है। मुझे एक .NET बाइनरी लोड करने की आवश्यकता है जो खुद को एक देशी असेंबली को लोड करने के लिए P / invoke का उपयोग करने की आवश्यकता है। यह वह जगह है जहाँ यह विफल हो जाता है और पूरी तरह से अलग हो जाता है। इस लाइब्रेरी पर मेरा कोई नियंत्रण नहीं है, यह एक तीसरी पार्टी लाइब्रेरी है (इस उदाहरण में SkiaSharp)। मैं अपने बाइनरी मॉड्यूल में इस लाइब्रेरी को लोड करने में असमर्थ हूं क्योंकि इसे उसी समय लोड करने की आवश्यकता होती है जब कोड मेरे मॉड्यूल से लोड किया जाता है, क्योंकि मेरा मॉड्यूल केवल मौजूद प्रकारों पर निर्भर है और स्काईआर्श लोड के साथ कार्यात्मक है।

@isazonov जैसा कि इस मुद्दे में अब कुछ समय के लिए कवर किया गया है, यह .net कोर में एक मुद्दा नहीं है क्योंकि आप बस अधिकांश अनुप्रयोगों के लिए प्रति प्लेटफ़ॉर्म अलग पैकेज उत्पन्न कर सकते हैं।

PowerShell के पास ऐसा करने का कोई संभावित तरीका नहीं है, और यह संयोगवश पुस्तकालय के खोज पथों से कुछ मानक रास्तों को हटा देता है, जिससे कुछ संदर्भों में देशी असेंबली के साथ काम करना असंभव हो जाता है, और ऐसा होने वाले लोगों में बहुत ही नाजुक और विशेष रूप से होता है। काम।

@ vexx32

मुझे एक .NET बाइनरी लोड करने की आवश्यकता है जो खुद को एक देशी असेंबली को लोड करने के लिए P / invoke का उपयोग करने की आवश्यकता है। यही वह जगह है जहां असफलता और पूरी तरह से अलग हो जाती है।

उह, ठीक यही कोड करता है। कुछ समय के लिए विंडोज और लिनक्स दोनों पर 6.2 पर सफलतापूर्वक इसका उपयोग किया गया।

संशोधित, क्षमा करें, मैं स्पष्ट नहीं था। मैं अपने स्वयं के द्विआधारी में ऐसा नहीं कर सकता, मेरे स्वयं के मॉड्यूल लोड होने के प्रकारों को प्रस्तुत करने की आवश्यकता है; मैं इसे कमांड इंस्टेंटेशन के दौरान आयात नहीं कर सकता .... और मुझे नहीं करना चाहिए।

जब यह बायनेरिज़ लोड करने की बात आती है, तो PowerShell को .net कोर से कम कार्यात्मक नहीं होना चाहिए।

उस ने कहा, मैं देखूंगा कि क्या मैं कुछ चीजों को अपना सकता हूं और अपने काम करने के तरीके में सुधार कर सकता हूं। उदाहरणों की सराहना करें!

लेकिन वास्तव में ... मुझे नहीं लगता कि मुझे इस काम के लिए इतनी लंबाई में जाना चाहिए। यह सिर्फ काम करना चाहिए, और जब तक पावरशेल शामिल नहीं हो जाता ... यह करता है।

दर्द होने पर खुश हो जाना। बस यह दिखाने की कोशिश कर रहा था कि विंडोज और लिनक्स पर पी / इनवॉइस के माध्यम से मूल निवासी लोडिंग कैसे की जा सकती है। :-)

@ vexx32 मुझे चर्चा में विभाजन दिखाई

की तरह। यह वह लेआउट है जो मेरे पास वर्तमान में काम करता है, लेकिन सभी बिल्ली के रूप में गड़बड़ है। जो कुछ भी मैं पी / इनवोक के माध्यम से एक पथ को परिभाषित नहीं कर सकता हूं वह मॉड्यूल रूट (जो कुछ प्लेटफार्मों पर नाम टकराव की समस्याओं में चलता है) में होना चाहिए।

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

SkiaSharp.dll .NET है, और मेरे मुख्य cmdlet dll के लिए एक संदर्भित असेंबली है। चार libSkiaSharp फाइलें मूल प्रति-प्लेटफ़ॉर्म DLL हैं। मैं SkiaSharp.dll में कोड को नियंत्रित नहीं करता, इसलिए मैं उस DLL को पी / इनवॉइस से पहले पथ को अपडेट करने के लिए बाध्य नहीं कर सकता।

इसलिए ... मेरे पास .NET निर्भरता वाला एक मॉड्यूल है। यह निर्भरता एक देशी पुस्तकालय पर निर्भर करती है कि यह DllImport के साथ लोड हो रहा है; सटीक फ़ाइल प्रति प्लेटफ़ॉर्म / आर्किटेक्चर से भिन्न होती है (लेकिन कई फ़ाइलों में नाम टकराव होते हैं, इसलिए उन प्लेटफार्मों को प्रतिबंधित करता है जिन्हें मैं वास्तव में समर्थन कर सकता हूं)।

@Rkeithhill के कोड का उपयोग करते

_Ideally_, इन फ़ाइलों में से सभी सबफ़ोल्डर में सबसे खराब होनी चाहिए, /PSWordCloud/runtime/<platform>/ जैसे कुछ - दुर्भाग्य से, PowerShell ने मानक सेटिंग्स से पथ लोडिंग विनिर्देशों को कैसे बदला है, केवल रूट में फ़ाइलें। मॉड्यूल के फ़ोल्डर को DllImport के माध्यम से लोड किया जा सकता है। अन्य स्थान काम कर सकते हैं, लेकिन (कम से कम मैक / लिनक्स पर) उन प्लेटफार्मों पर पर्यावरण चर का _all_ जो देशी रनटाइम लोड पथों को परिभाषित करने वाले हैं, उन्हें पूरी तरह से PowerShell द्वारा अनदेखा किया जाता है।

मेरा मानना ​​है कि $env:Path अभी भी काम करता है (हालांकि इसका उपयोग यूनिक्स प्लेटफार्मों पर नहीं किया जाना चाहिए, और मैंने परीक्षण नहीं किया है कि 6.2 रिलीज के बाद से, ताकि यह भी टूट जाए), लेकिन स्पष्ट रूप से मैं नहीं करता हूं लगता है कि उस चर का एक टन जोड़ने के लिए यह एक अच्छा विचार है, यह वास्तव में भयानक उपयोगकर्ता अनुभव के लिए बनाता है यदि उपयोगकर्ता को उस पर्यावरण चर का उपयोग करने की आवश्यकता है। आप एक मॉड्यूल को लोड करते हैं, और अचानक आपके पथ चर में अतिरिक्त अनपेक्षित डेटा होता है जो शायद नहीं होना चाहिए, लेकिन चीजों को सही ढंग से काम करने के लिए _has_ होना चाहिए।

मुझे लगता है कि यह एक गैर-मुद्दा होना चाहिए; PowerShell के पास मूल लाइब्रेरी लोड पथों को संभालने का अधिक मजबूत तरीका होना चाहिए, अगर यह .NET कोर के पूर्वनिर्धारित तरीकों को ओवरराइड करने वाला हो। मैं मॉड्यूल मेनिफेस्ट में मूल लाइब्रेरी लोड पथ या उन पंक्तियों के साथ कुछ निर्दिष्ट करने का कोई तरीका सुझाऊंगा, यह परिभाषित करने का कोई तरीका जहां यह प्रति प्लेटफ़ॉर्म की तलाश में होना चाहिए जब कुछ को कुछ मूल कोड को पी / इनवॉइस करना होगा।

मेरे पास एक ही मुद्दा है और @ vexx32 की रिपोर्ट में श्रृंखला के सभी तत्व शामिल हैं।
मैं सहमत हूं कि पॉवरशेल में देशी लाइब्रेरी को संभालने का अधिक मजबूत तरीका होना चाहिए।

मुझे नहीं लगता कि उस चर का एक टन पथ जोड़ने के लिए यह एक अच्छा विचार है

सहमत और इसी तरह, मैं SetDllDirectory का उपयोग करने के लिए उत्सुक नहीं हूं क्योंकि वह भी (pwsh) प्रक्रिया विस्तृत है। मॉड्यूल प्रकट करने के लिए मॉड्यूल लेखकों को प्रति ओएस-कॉम्बो प्रति देशी डीएलएस की सूची प्रदान करने की अनुमति देने के लिए अपडेट किया जा सकता है और फिर किसी भी असेंबली को लोड करने से पहले उन देशी डीएलएस को प्री-लोड करना होगा। उस व्यक्ति ने कहा, अगर कोई आपकी विधानसभा का दूसरी भाषा से उपयोग करने जा रहा है, तो विधानसभा को वास्तव में अपने स्वयं के मूल dll को लोड करना चाहिए। विधानसभा के उपयोगकर्ता को उस IMO को नहीं करना चाहिए।

@ vexx32 मुझे लगता है कि " dlopen macOS पर भी काम करता है।

जब मैं कर सकता हूँ मैं इसे एक बार दे दूँगा (मैक VMs थोड़ा ... अजीब हे), लेकिन स्मृति से, मैक .so फ़ाइलों का उपयोग नहीं करता है, इसलिए मुझे निश्चित रूप से इसे आज़माना होगा - - अधिकांश मूल देयताएं जिन्हें मैं मैक पर संदर्भ देखता हूं, वे .dylib लगते हैं।

असेंबली यहां अपना प्रीलोडिंग करती है (कम से कम, मुझे पूरा यकीन है कि यह करता है ...), मुझे अभी सब कुछ विशेष-मामला करना है क्योंकि असेंबली को यह नहीं पता है कि पीएस कैसे पथ संभालता है। : /

मुझे लगता है कि 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      

मैं वास्तव में चाहता हूं कि मुझे प्रत्येक प्लेटफ़ॉर्म के लिए इसे recompile नहीं करना पड़ा क्योंकि यह netstandard2 विधानसभा है। लेकिन AFAICT DllImport विशेषता को प्रदान किया गया आवश्यक नाम मान लगातार संकलन समय होना चाहिए। :-(

हाँ। चूंकि यह एक पॉवरशेल मॉड्यूल है, जो मैं वास्तव में समाप्त कर रहा हूं वह एक मंच पर चेक के साथ Add-Type -TypeDefinition $srcString साथ एक गतिशील ऑन-इंपोर्ट संकलन है और फिर इसे सही निर्देशिका में इंगित करें। आप इसके लिए मॉड्यूल मेनिफ़ेस्ट में ScriptsToProcess का उपयोग कर सकते हैं, शुक्र है।

इसके अलावा, MacOS पर ऐसा करने के लिए libdl.so एक वैध और प्रयोग करने योग्य पुस्तकालय है?

लेकिन हाँ, हमें एक बेहतर समाधान की आवश्यकता है। 😄

@ vexx32 क्या आपने मोनो मेपल को देखा? सुविधा शर्तों (आर्च, प्लेटफ़ॉर्म और आदि) के आधार पर उपयुक्त देशी पुस्तकालय के लिए स्वचालित मानचित्रण की अनुमति देती है। मुझे उम्मीद है कि यह है कि आप की जरूरत है। शायद SkiaSharp.dll को फिर से शुरू किया जाना चाहिए लेकिन इसे बाहरी कॉन्फ़िगरेशन फ़ाइल में कॉन्फ़िगर किया जा सकता है। कुछ इसी तरह कोर में लागू किया जाएगा।

अगर मुझे सही तरीके से याद है, तो .NET कोर विंडोज पर रन करते समय मोनो का उपयोग नहीं करता है, इसलिए यह फिर से एक आंशिक समाधान होगा।

मैं यहां दिए जा रहे सभी विकल्पों की बहुत सराहना करता हूं, और मैं पूरी तरह से जांच करूंगा कि मेरे वर्तमान विकल्प क्या हैं - लेकिन दिन के अंत में, PowerShell को इस उद्देश्य के लिए क्रॉस-प्लेटफॉर्म मॉड्यूल के लिए कुछ करने की आवश्यकता है। । 🙂

अगर मुझे सही तरीके से याद है, तो .NET कोर विंडोज पर रन करते समय मोनो का उपयोग नहीं करता है, इसलिए यह फिर से एक आंशिक समाधान होगा।

मैं नई सुविधाओं के बारे में कहता हूं। देख
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

@rkeithhill

मैं वास्तव में चाहता हूं कि मुझे प्रत्येक प्लेटफ़ॉर्म के लिए इसे recompile नहीं करना पड़ा क्योंकि यह netstandard2 विधानसभा है। लेकिन AFIICT DllImport विशेषता को प्रदान किया गया आवश्यक नाम मान एक स्थिर समय स्थिर होना चाहिए। :-(

FWIW आप DllImport लिए एक्सटेंशन को छोड़ सकते हैं। हम पीएसईएस के गैर-विंडोज देशी निर्भरता के लिए ऐसा करते हैं । यदि आधार नाम समान नहीं हैं तो भी मदद नहीं करता है।

आप शायद अलग-अलग इंटरफ़ेस कार्यान्वयन में संग्रहीत करके LoadLibrary / dlopen लिए संकलक निर्देशों को भी छोड़ सकते हैं। जब तक विधि JIT'd नहीं है तब तक इसे रनटाइम पर नहीं फेंकना चाहिए।

मुझे इस समस्या का एक संभावित समाधान मिला। हालांकि मुझे इसे आज़माना होगा। मैं वर्तमान में कुछ रिलीज पर काम करने में व्यस्त हूं, इसलिए सबसे अधिक संभावना है कि यह अगले सप्ताह की शुरुआत में होगी। मैं अपने निष्कर्षों के साथ इस मुद्दे को अपडेट करूंगा।

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 के आसपास मिला। शायद हमारे मामले में बेमतलब है।

हमें एक कॉलबैक जोड़ने पर विचार करना चाहिए जो लोगों को अप्रबंधित पुस्तकालयों के लिए कस्टम रिज़ॉल्यूशन पॉलिसी की आपूर्ति करने की अनुमति देता है। हमने असेंबली BWadContext.LoadUnmanagedDll के साथ करने का इरादा किया है। अंत में, यह केवल उन्हें समस्या का एक छोटा सा हिस्सा संबोधित किया क्योंकि यह डिफ़ॉल्ट लोड संदर्भ के लिए काम नहीं करता है। जब हमने मूल रूप से असेंबलीलॉड कॉन्टेक्स्ट.लॉड यूमनडेडडल शुरू किया है, तो हमने डिफ़ॉल्ट लोड संदर्भ को भी ओवरराइड करने की अनुमति दी थी, लेकिन फिर इस क्षमता को हटा दिया और सभी परिदृश्यों पर प्रभाव के माध्यम से नहीं सोचा।

स्रोत: LoadUnmanagedDllFromPath / LoadUnmanagedDll लाइन पर काम नहीं कर रहा है यदि .so फ़ाइल अनुप्रयोग आउटपुट निर्देशिका के अलावा किसी अन्य पथ में मौजूद है।

मुझे लगता है कि 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 और मैक पर साझा lib के नाम को बदलने के अलावा, यह काम करना चाहिए। यह .NET Core 2.2 पर है।

यूडी @rkeithhill समाधान के रूप में बहुत ज्यादा एक ही काम कर रहा है। यह MacOSX के साथ-साथ लिनक्स और विंडोज पर भी काम करता है। https://github.com/ironmansoftware/universal-dashboard/blob/master/src/UniversalDashboard/Server/CustomAssemblyLoadContext.cs

मुद्दा यह है कि विभिन्न बायनेरिज़ को लोड करने के लिए फ़ोल्डर पथ के कई और अधिक भिन्नताएं हो सकती हैं, इसलिए यह एक kluge का एक सा है। यदि एक नया बाइनरी प्रकार एक नई निर्भरता के आधार पर आउटपुट है, तो एक नया फ़ोल्डर पॉप अप हो सकता है और यूडी असेंबली लोड नहीं करेगा।

@rkeithhill क्या आप सभी WindowsLinux बायनेरिज़ को एक फ़ोल्डर में विलय कर रहे हैं? (संपादित करें: वास्तव में, मैं इसे प्राप्त करता हूं। आपके पास एक आवरण डीएलएल असेंबली है जो सिर्फ लक्ष्य देशी असेंबली को लोड करता है। क्या आप अपने सभी मूल असेंबली के लिए ऐसा करते हैं?)

यूडी केवल प्रकाशित रनटाइम फ़ोल्डर को उसी तरह रखता है जब इसे डॉटनेट प्रकाशन के साथ निर्मित किया गया था और फिर संदर्भित वर्ग सभी मूल बायनेरिज़ को सही प्लेटफ़ॉर्मरटेक्चर के आधार पर लोड करने का प्रयास करता है।

यह काम करता है, लेकिन मेरी इच्छा है कि PS केवल एक रनटाइम फ़ोल्डर को देख सके और सही बायनेरिज़ को लोड कर सके। डॉटनेट जैसा लगता है कि जब यह शुरू होता है तो ऐसा लगता है कि शायद वहाँ कुछ कोड है।

मैं बदलता हूं जहां मैं परिणाम RuntimeInformation.IsOSPlatform(OSPlatform.Windows) आधार पर मूल विधानसभाओं की तलाश करता हूं। अगर यह सच है, तो मैं Windows फ़ोल्डर से लोड करता हूं, जो C # असेंबली में स्थित है। अन्यथा, मैं Linux फ़ोल्डर से लोड करता हूं।

क्या आप अपनी सभी देशी विधानसभाओं के लिए ऐसा करते हैं?)

हां, लेकिन हमें केवल एक ही मिला है और यह सिस्टम लिबास (msvcrt, आदि) के अलावा किसी और चीज पर निर्भर नहीं करता है।

क्या हमारे पास कुछ मानक फ़ाइल संरचना हो सकती है (शायद रनटाइम नामों पर आधारित)? यह हमें देशी dll रिज़ॉल्वर को बढ़ाने की अनुमति देगा।

यूडी केवल प्रकाशित रनटाइम फ़ोल्डर को उसी तरह रखता है जब इसे डॉटनेट प्रकाशन के साथ निर्मित किया गया था और फिर संदर्भित वर्ग सभी मूल बायनेरिज़ को सही प्लेटफ़ॉर्मरटेक्चर के आधार पर लोड करने का प्रयास करता है।

इसलिए अगर मैं सही तरीके से समझ रहा हूँ, तो आप PowerShell का उपयोग करने से बच रहे हैं। देशी बायनेरिज़ को लोड करने के लिए। उन्हें हूड के नीचे लोड करें जब आप एक प्रबंधित बाइनरी लोड करते हैं जो RID- विशिष्ट देशी बायनेरिज़ पर निर्भर करता है?

यह काम करता है, लेकिन मेरी इच्छा है कि PS केवल एक रनटाइम फ़ोल्डर को देख सके और सही बायनेरिज़ को लोड कर सके। डॉटनेट जैसा लगता है कि जब यह शुरू होता है तो ऐसा लगता है कि शायद वहाँ कुछ कोड है।

हाँ, मुझे संदेह है कि .NET रनटाइम के भीतर ही कुछ RID जागरूकता हो रही है। मैं उस रास्ते से नीचे जाने से बचने की कोशिश कर रहा हूं, लेकिन लगता है कि हमें कुछ बिंदु पर जरूरत पड़ सकती है।

@joeyaiello

इसलिए अगर मैं सही तरीके से समझ रहा हूँ, तो आप PowerShell का उपयोग करने से बच रहे हैं। देशी बायनेरिज़ को लोड करने के लिए। उन्हें हूड के नीचे लोड करें जब आप एक प्रबंधित बाइनरी लोड करते हैं जो RID- विशिष्ट देशी बायनेरिज़ पर निर्भर करता है?

हां, ठीक यही। UD बस लक्ष्य RID के लिए सब कुछ लोड करता है। तो यह वास्तव में स्मार्ट नहीं है कि वास्तविक निर्भरताएं क्या हैं। यकीन नहीं होता है कि पता लगाने के लिए एक अच्छा तरीका है।

@ vexx32 मैंने

वर्तमान में PSWordCloud की फ़ोल्डर संरचना सामान्य नहीं है, नहीं। इसे बदला जा सकता है।

हाँ, मैं बिल्कुल एक साथ एक साधारण परीक्षण बिस्तर लगा सकता हूँ। Pester करने के लिए थोड़ा मुश्किल है, बस मेरे द्वारा उत्पादित आउटपुट की प्रकृति के आधार पर, लेकिन I _think_ जब यह विफल हो जाता है तो यह एक अपवाद पैदा करता है जिसे आप पकड़ सकते हैं, हालांकि अगर मैं सही ढंग से याद करता हूं तो वह अपवाद टाइप इनिलाइज़र से फेंक दिया जाता है।

क्या यह उचित होगा कि परीक्षण स्वयं स्केट डीएलएल को डॉटनेट के माध्यम से खींचे, या रेपो में उन्हें पैकेज करना बेहतर होगा? मुझे लगता है कि अगर हम उन्हें हर बार खींचते हैं तो यह बहुत बड़ी बात नहीं है यदि इसे एक सुविधा परीक्षण के रूप में चिह्नित किया जाता है, क्योंकि यह अब लंबित नहीं है? :विचारधारा:

यदि आप Skia dlls के साथ अप्रत्यक्ष निर्भरता के साथ एक परीक्षण नोड्यूल लागू कर सकते हैं तो यह अच्छा होगा। और हाँ हम नगेट से Skia स्थापित कर सकते हैं। हालांकि परीक्षण अधिक विश्वसनीय होगा अगर हम सीधे टेस्ट मॉड्यूल के साथ डीएलएस ~ हमारे टेस्ट मॉड्यूल फ़ोल्डर ~ एक एसेलर फ़ोल्डर में डालते हैं।
ऐसा लगता है कि Nuget सबसे अच्छा अभ्यास RID नामित फ़ोल्डरों में देशी dlls रखना है। हाँ?

हां, मैं ऐसा कर सकता हूं! मैं इसे करने के लिए एक नज़र रखना होगा। :शरमाना:

मैंने अपनी टिप्पणी को अपडेट कर दिया - कृपया परीक्षण मॉड्यूल को एक परीक्षण assert फ़ोल्डर में डालें।

@rjmholt मैंने

मेरी WIP शाखा यहाँ देखें https://github.com/vexx32/PSWordCloud/tree/FixPInvokes - मॉड्यूल बनाने के लिए build.ps1 चलाएँ और सभी फ़ाइलों को सही स्थानों पर रखें। यह आपके लिए मॉड्यूल भी आयात करेगा। विंडोज पर निर्माण कार्य चलाने के बाद New-WordCloud कॉल करना, लेकिन मैक ओएस पर पूरी तरह से विफल रहता है।

@ अगर आप कुछ भी देखते हैं तो मैंने गलत किया है? : /

GitHub

vexx32 / PSWordCloud

PowerShell के साथ सुंदर शब्द बादल बनाएं! GitHub पर एक खाता बनाकर vexx32 / PSWordCloud विकास में योगदान करें।

@ स्टीवएल-एमएसएफटी वर्तमान में मूल देयताओं को संभालने के लिए क्या योजना है? 😕

: टाडा: इस मुद्दे को # 11032 में संबोधित किया गया था, जिसे अब v7.0.0-rc.1 रूप में सफलतापूर्वक जारी किया गया है।

काम लिंक:

• रिलीज नोट्स