none
How to load dll from PS module path RRS feed

  • Question


  • I have a PS module - all working fine. For a new script which is part of this module I need to load a dll from the Microsoft WindowsAPICodePack

    I've added the dll to an "Assemblies" folder within the module, which is installed in the default location (C:\Program Files\WindowsPowershell\Modules\ModuleName).

    The script which uses the dll works fine in test, when the dll is in a temp folder e.g. 'c:\temp', however when I run the script from the module, using the path to the dll copy in the module (C:\Program Files\WindowsPowershell\Modules\ModuleName\Assemblies\mydllname.dll) it fails to load the dll with "file not found".

    I'm local administrator for the machine so I have access to the path and it also fails if I elevate Powershell before running it.

    I need to load the dll from this location without amending permissions for the folder as the module is for distribution to many users via our in-house repository. Any ideas how this can be achieved?

    Is there a way to load the dll into the user environment as the module loads instead? This might not work either though as it seems to be a permissions issue on executing/loading dll from the modules path.

    I suppose I could run a Set-Acl command against the dll in the .psm1 but this seems a bit clunky and no idea if the install-module process would have required rights?

    Example code:

    Try {
        Add-Type -AssemblyName System.Windows.Forms
        Add-Type -Path $DllPath
    }
    Catch {
        $_
        Pause
        Break
    }

    If

    $DllPath = "C:\Program Files\WindowsPowerShell\Modules\module\dllname.dll"

    Then it will fail

    If

    $DllPath = "C:\temp\dllname.dll"
    Then it works fine.
    • Edited by Scepticyn Friday, January 17, 2020 2:47 PM
    • Moved by jrv Sunday, January 19, 2020 2:54 PM Off Topic
    Friday, January 17, 2020 2:47 PM

All replies

  • Test-Path $dllpath

    If this fails then the module doesn't exist at that location.


    \_(ツ)_/

    Friday, January 17, 2020 7:17 PM
  • The module exists.

    It seems that the dll won't load because of its location - as soon as I move it to a non-system path it works fine.


    • Edited by Scepticyn Friday, January 17, 2020 10:42 PM
    Friday, January 17, 2020 10:41 PM
  • To access some parts of Windows you must run elevated.  Other protected areas will be inaccessible.  This is not a scripting issue but an issue of basic Windows understanding.  Without permission you cannot access something.

    Ask the vendor of the module for help.  It is an issue of design and may be the intended condition.


    \_(ツ)_/

    Friday, January 17, 2020 10:45 PM
  • There is no "vendor" this is a module I've written for internal use.

    I can access the path fine and looking at other modules, the authors seem to be able to load dll from this location, so I'm pretty sure it's possible in some way to get these classes working.


    • Edited by Scepticyn Saturday, January 18, 2020 6:43 AM
    Saturday, January 18, 2020 6:42 AM
  • You have written the  DLL yourself?  Is it signed correctly?  There is no scripting reason for this behavior so something you have done is causing this.

    Did you run the Test-Path as I suggested?


    \_(ツ)_/


    • Edited by jrv Saturday, January 18, 2020 9:50 AM
    Saturday, January 18, 2020 9:49 AM
  • Please read my OP; this is a MICROSOFT dll - part of the downloadable Microsoft WindowsAPICodePack

    Test-Path 'C:\Program Files\WindowsPowerShell\Modules\NSSutils\2.5.3\_Assemblies\Microsoft.WindowsAPICodePack.Shell.dll'

    True


    It loads fine if not part of a system folder such as Program Files, Windows etc. Basically, if the security tab for the folder/file has the shield on it then the dll will not load.
    • Edited by Scepticyn Saturday, January 18, 2020 10:08 AM
    Saturday, January 18, 2020 9:59 AM
  • If it is a downloaded file then it is likely blocked.  Unblock it.

    Your original post calls it "mydllname.dll".  Look at you post.


    \_(ツ)_/

    Saturday, January 18, 2020 10:20 AM
  • Thsi is the SAME dll in both locations. It is not blocked, it was the first thing I checked..

    The very first line of my OP:

    I have a PS module - all working fine. For a new script which is part of this module I need to load a dll from the Microsoft WindowsAPICodePack



    • Edited by Scepticyn Saturday, January 18, 2020 10:35 AM
    Saturday, January 18, 2020 10:34 AM
  • How do you know it is not blocked?  Have you checked the DLL and the folders it is in?


    \_(ツ)_/

    • Marked as answer by Scepticyn Saturday, January 18, 2020 11:53 AM
    • Unmarked as answer by Scepticyn Saturday, January 18, 2020 11:53 AM
    Saturday, January 18, 2020 10:59 AM
  • The dll is not blocked. I have checked both with gui and using streams. At this point you're patronising not assisting.
    Saturday, January 18, 2020 1:18 PM
  • I am trying to get you to check the normal things.  How did you check with the GUI?  

    You have aleady proven that PowerShell has nothing to do with this since the file loads correctly in a different location on the disk.  We cannot see your system so what do yoiu expect us to do.  The issue is with your system and you will have to determine what is an issue with that folder/file.  Perhaps the AV or a GPO are blocking that location or file type.

    Solving this is up to you.  If you don't know how to troubleshoot this kind of problem you can open an incident with MS Support.


    \_(ツ)_/

    Saturday, January 18, 2020 1:57 PM
  • With the GUI as usual, right click and check the unblock box if it's there. Which it isn't. Because it's not there on the other location where I copeid it from either.

    I'm here to ask for assistance because I've done the troubleshooting - it seems that Windows protection of system folders is stopping the dll from loading in a Powershell script. So I posted in a Powershell forum hoping that someone with the requisite experience could tell me how to rectify this.

    I know it's possible, because other Powershell modules, from both 3rd party and Microsoft's own manage to do it. It just requires the correct PS scripting/configuration knowledge, so I'll wait to see if anyone with that knowledge responds. Thank you




    • Edited by Scepticyn Saturday, January 18, 2020 3:39 PM
    Saturday, January 18, 2020 3:35 PM
  • Are you running the 32 bit version of Powershell? If so, WOW will redirect "c:\program files" to "c:\program files (x86)" and your dll is not there.

    There may be other dll's that your dll references that are missing from your system. Download and run Process Monitor and trace Powershell. Search for the dll name and see what file I/O occurs from there.

    https://docs.microsoft.com/en-us/sysinternals/downloads/procmon


    • Edited by MotoX80 Saturday, January 18, 2020 4:38 PM
    Saturday, January 18, 2020 4:17 PM
  • The DLL in question is not designed to work directly with PowerShell.  It is a code container that needs to be compiled into a program to provide the dependencies.

    This is also not a Microsoft package and you need to post issues in teh NuGet site to learn how to use it or report bugs

    .


    \_(ツ)_/

    Saturday, January 18, 2020 5:19 PM
  • The DLL in question is not designed to work directly with PowerShell.  It is a code container that needs to be compiled into a program to provide the dependencies.

    This is also not a Microsoft package and you need to post issues in teh NuGet site to learn how to use it or report bugs

    .


    \_(ツ)_/

    Please. You are wrong on BOTH counts. It is a dll originally supplied by MS precisely so that code can interface with variuous elements of the UI from Win7 onwards.
    Adding it as a type into a PS session allows me to control elements such as the taskbar icon overlay and progress bar and I have WORKING code which does this. My only issue is that the code will not work from a PS module because of the dll location.
    Please refrain from commenting unless you have something accurate to add.
    Saturday, January 18, 2020 5:59 PM
  • Are you running the 32 bit version of Powershell? If so, WOW will redirect "c:\program files" to "c:\program files (x86)" and your dll is not there.

    There may be other dll's that your dll references that are missing from your system. Download and run Process Monitor and trace Powershell. Search for the dll name and see what file I/O occurs from there.

    https://docs.microsoft.com/en-us/sysinternals/downloads/procmon


    Many thanks - good shout about 32bit redirect. I'm pretty sure I'm using 64bit Powershell, but will check on Monday when I'm back at work.

    Pretty sure it's not dependencies  - as mentioned if I simply change the dll location to "anywhere buit a system folder" it loads just fine.
    Saturday, January 18, 2020 6:01 PM
  •  I'm pretty sure I'm using 64bit Powershell, 

    You still might want to trace it with procmon and see if there is an "access denied" or something else that's unusual.
    Saturday, January 18, 2020 6:23 PM
  • The DLL in question is not designed to work directly with PowerShell.  It is a code container that needs to be compiled into a program to provide the dependencies.

    This is also not a Microsoft package and you need to post issues in teh NuGet site to learn how to use it or report bugs

    .


    \_(ツ)_/

    Please. You are wrong on BOTH counts. It is a dll originally supplied by MS precisely so that code can interface with variuous elements of the UI from Win7 onwards.
    Adding it as a type into a PS session allows me to control elements such as the taskbar icon overlay and progress bar and I have WORKING code which does this. My only issue is that the code will not work from a PS module because of the dll location.
    Please refrain from commenting unless you have something accurate to add.

    The product was originally written by MS but has been transferred to open source.

    I have loaded the module and it does not load directly into PowerShell from any location.    I have it running under Visual Studio as a part of a WPF project.  To use it in PowerShell you need to wrap in in a module that loads it correctly from its module location.  The required support files are generated into teh structure of the module location and should be dynamically called when referenced.

    It is unclear how you obtained a copy that you say can load directly . That is information you are missing and the exact error you are getting.

    It doesn't matter which version of PS is running if the code is 32 bit then it may fail at 64 but that would be obvious in the error message.


    \_(ツ)_/

    Saturday, January 18, 2020 8:04 PM
  • Please, jrv. You;re really not helping.

    I downloaded the 5 dlls direct from MS when they were released. The "module" you're looking at is a 3rd party PS module. The dlls do NOT need to be in that module to be used. They were provided simply as 5 dll files that were zipped.

    See below for WORKING example code - simply place the correct dll in the path as below

    #
    # Load dll
    Try {
       Add-Type -Path 'C:\temp\_Assemblies\Microsoft.WindowsAPICodePack.Shell.dll'
    }
    Catch [System.Reflection.ReflectionTypeLoadException] {
        Write-Host "Message: $($_.Exception.Message)"
        Write-Host "StackTrace: $($_.Exception.StackTrace)"
        Write-Host "LoaderExceptions: $($_.Exception.LoaderExceptions)"
    }
    
    
    
    # Create and configure the TaskDialog
    $td = New-Object Microsoft.WindowsAPICodePack.Dialogs.TaskDialog
    $td.Caption = "Updating Templates"
    $td.Text = "There are currently one or more Microsoft Office applications running.`n`nYou must close down all open Office applications before the template update can continue."
    $td.StandardButtons = "Retry,Cancel"
    $td.Icon = "Warning"
    
    # Show the dialog and capture the resulting choice
    $result = $td.Show()  # will return either "Retry" or "Cancel" 

    See this article also for details:

    https://www.codeproject.com/Articles/49268/Windows-7-New-Features-Explained-Using-NET

    Now please, leave this thread alone unless you have something to contribute.
    • Edited by Scepticyn Saturday, January 18, 2020 9:47 PM
    Saturday, January 18, 2020 9:46 PM
  • Where in MS did you download them.  They do not appear to be available anymore since MS turned them over to GitHub.

    You are giving out bits and pieces of information without ever telling us the complete information.  That is not helpful.


    \_(ツ)_/


    • Edited by jrv Saturday, January 18, 2020 9:51 PM
    Saturday, January 18, 2020 9:50 PM
  • Where in MS did you download them.  They do not appear to be available anymore since MS turned them over to GitHub


    \_(ツ)_/

    I downloaded them BEFORE the direct MS link was removed. They are however still available at various places if you look for them.

    There is zero point in using them under WPF - most of the classes have direct equivalents already under that framework

    • Edited by Scepticyn Saturday, January 18, 2020 9:53 PM
    Saturday, January 18, 2020 9:51 PM
  • jrv

    I'm creating a small PS-based utility for internal use in Windows Forms, not WPF. Componments? Windows, Powershell and a domain-joined PC. That's it.

    You've been patronising, arrogant and unhelpful throughout and turned my thread into a pile of c**p. At this point I'm at a loss to explain your rating on this forum and can only assume that you harvest points by advising people how to add shortcuts to the all users folder or similar.

    I shall not return to this forum again so you needn't reply.

    Saturday, January 18, 2020 11:31 PM
  • I don't know why you are making this personal.  If you can't proviode clear an d detaied information then it is not possible to help you.  Thhrowing a fit won't help.

    You say you are building something that requires PS and forms.  What is it that this DLL will help.

    My issue is that you are new to PowerSHell and Windows systems technologyy.  I have 40_ years of experience and have been programming Windows at a systems level since the first version of WIndows.  My questions are advised by years of experience.  Yu need to provide the correct information and ask a question that is about PowerShell.

    Without access to the old assembly it is not possible for anyone working with current versions of Windows to help you.

    You say that the assembly loads but not from where you want it to load yest you have not provided any code that shows how you are using the DLL in the module.

    As I noted above - the DLL is likely restricted by policy when stored in ProgramFiles.  There is nothing we can do without a copy of the assembly.

    How is that "patronising"  It is just a simple statement and question.


    \_(ツ)_/

    Saturday, January 18, 2020 11:49 PM