I have a powershell script that references dll files and i would like to distribute this script to customers. How can i do this such that the customers don't have to worry installing/referencing correct dll files?
I reference the dll files from within the script in the following way:
Add-Type -Path <local path to dll>
I am looking for a way to either bundle these dll's along with the script , or some way for powershell to install the dll when it runs. The dll's i am interested in are available as following nuget packages:
Sharepoint Client
Active Directory library
You could try copying the dll files to the directory the script is in and then use "$PSScriptRoot\Name.Of.File.dll". Zip the directory and distribute the Zip file.
Related
I have a powershell script the downloads a zip file with a folder with files within it to the %TEMP% folder and I'm trying to understand how it can be unziped and acessed an exe file within it?
I have made searches both here and on google but I didn't found anything and have no clue how can that be done or evn where to start.
Try Extract-ZipFile cmdlet. Then access the exe where you have extracted the zip file.
Try expand-archive to unzip files. Power shell v5 has it
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 will succeed
Tried
Added the dll to the module's Required Assemblies in the manifest
Added this to start of the script
Using moduleName
Using namespace Microsoft.WindowsAPICodePack
Same error
I have a Dell PC with Win7 64 using what I believe is the latest version of AutoHotKey.
I wrote an Installer App with AutoHotKey to create two directories with a number of sub directories then install an exe program and a number of data files into those directories. The App installs into the existing C:\Program Files and C:\Program Data directories.
The Installer App creates the sub directory C:\Program Files\DSOSort then installs the file DSOSort.exe. The installer App then creates the sub directory C:\Program Data\DSOSort and installs a number of additional sub directories with all the associated text data files.
I used the FileCreateDir and FileInstall instructions in the Installation App to create the directories and install the files.
Everything in the Installer App and in the exe program works as it should except that the exe will not make any changes to the text data files in the newly created C:\Program Data\DSOSort directory. I have to open the directory with Properties and allow Users to Write. Once that is done the exe will change data in the text data files correctly and all is well.
If I change the Installer App to create a directory C:\DSOSort then install all the sub directories and data files in there instead of into C:\Program Data\DSOSort the exe can write to the text file. I do not have to change any permissions with Properties.
I tried using the various copies of the C:\Program Data\DSOSort directory I found in C:\Documents and Settings and also in C:\Users. The exe can read them but no Write.
I only have this problem with newly installed directories and again as I said earlier it can be corrected with Properties.
The exe program was written for people with enough knowledge to run the Installation App but do not understand Properties or making changes to the directories.
I could just leave the data files in a C:\DSOSort directory but would prefer to put them in a C:\Program Data\DSOSort directory.
Is there a way for AutoHotKey to check the user permissions and changing them if necessary before installing the data files?
Is my PC behaving properly? Is it supposed to create directories without allowing Write to the files?
Some of these directories, like "Program Files", require admin privileges to modify. I believe that is why you're experiencing that. Have your app run as an admin and it should be fine. The setting for you EXE can be found in the properties.
The A_IsAdmin built-in variable returns whether the current user has admin rights.
In order to make install scripts and understanding existing ones, I would like to know what happens behind the scenes of the typical:
choco install notepadplusplus
I found the following here:
Installation
Chocolatey uses Nuget.Core to retrieve the package from the source.
Choco determines if it self-contained or has automation scripts - PowerShell scripts (*.ps1 files), and soon to be open to Scriptcs files in the 0.9.10.x timeframe (I know, right?!).
Choco takes a registry snapshot for later comparison.
If there are automation scripts, choco will run those. They can contain whatever you need to do, if they are PowerShell you have the full power of Posh (PowerShell), but you should try to ensure they are compatible with Posh v2+.
Choco compares the snapshot and determines uninstaller information and saves that to a .registry file.
Choco snapshots the folder based on all files that are currently in the package directory.
Choco looks for executable files in the package folder and generates shims into the $env:ChocolateyInstall\bin folder so those items are available on the path. Those could have been embedded into the package or brought down from somewhere (internet, ftp, file folder share, etc) and placed there.
That given,
How can I get the .nupkg package URL? In general it seems like this:
https://chocolatey.org/api/v2/package/package-name
Which is the .nupkg package download directory?
Where is the content of the .nupkg package extracted by default? This is important since chocolateyInstall.ps1 sometime uses Split-Path -Parent $MyInvocation.MyCommand.Definition.
"Scriptcs files in the 0.9.10.x timeframe" is rather cryptic. Can you give some references?
Is Posh v2+ simply short for Powershell or is a specific technology?
There are several executable files in $env:ChocolateyInstall\lib without a link in $env:ChocolateyInstall\bin. For example, the mpv.exe of the mpv player is not linked.
Yes, that download URL seems correct. The download directory is always into the Chocolatey installation folder, then lib\packageName, and this is where contents are extracted to.
Right now, installation scripts are only written in PowerShell. This comment is referring to the ability to write in installation scripts in C#, using the ScriptCS run time. Currently, this isn't yet supported.
Yes, this is just a short way of referring to PowerShell.
In the case of the mpv package, you will notice that there is an mpv.exe.ignore file. The presence of this file in the package prevents a shim being created.
When I do this -
PS C:\> $env:psmodulePath.split(";")
I get two folders - i.e. User Module Folder and System Module Folder.
User Module Folder
C:\Users\winUser1\Documents\WindowsPowerShell\Modules
System Module Folder
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
Now, when I am copying my psm1 files under system module folder, and trying to do import-module from ISE x86, the scripts are not getting loaded, but vice-versa is true - i.e. working from user module folder.
But, in a production environment, I want any user to be able to execute the scripts. Any idea how to achieve the same ?
NOTE: I am using Windows 2008 R2 and Windows 7 - All 64-Bit Versions, but scripts should run as 32-bit version
Try to copy them under the SysWOW64 folder. The SysWOW64 folder contains the 32-bit system files and the System32 contains the 64-bit system files
C:\windows\SysWOW64\WindowsPowerShell\v1.0\Modules