I installed the ImportExcel module as described here:
https://www.powershellgallery.com/packages/ImportExcel/5.0.1
Then I wrote a simple ps1 file that loops though certain folder and converts each xlsx file in that folder to csv format (using ConvertFrom-ExcelSheet method from the above module).
Finally, I wrapped that ps1 script into a .bat file.
That batch script works fine when executed manually via windows command line.
However, when the same batch file is executed from an SSIS package (on the same computer, under my credentials, using the standard Execute Process Task ), when the powershell script reaches the line calling ConvertFrom-ExcelSheet method, I am getting the following error:
The term 'ConvertFrom-ExcelSheet' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
The PC was restarted after module installation.
The module was installed with the AllUsers scope.
Elevated shell during module installation.
Any hints what I can do to get this module working in SSIS? Or at least, where to start looking?
Environment:
PowerShell 5.0.10586.117
Windows 7 Enterprise x64
Visual Studio 2012
Problem solved by moving the installed module to user's module folder i.e. %USERPROFILE%\Documents\WindowsPowerShell\Modules
There is still no clear explanation why the module was not working from shared modules folder but at least the issue is now gone.
Related
I would like to run a script that requires to use commands from the GroupPolicy module. However, this module is not guaranteed to be installed on every machine and some machines might be stand alone. Can I have have the module copied over with my scripts and run commands from it, without installing the module?
Can I have have the module copied over with my scripts and run commands from it, without installing the module?
Yes. Installing a module in PowerShell simply means placing it one of the directories listed in the $env:PSModulePath environment variable, which allows PowerShell to discover it and import (load) it on demand, as part of the module auto-loading feature
However, you're free to copy modules elsewhere, as long as the code that relies on them knows their path and loads them with an explicit Import-Module call.
For instance, if you bundle your script with a GroupPolicy subdirectory containing that module, the script could import it as follows:
# $PSScriptRoot contains the calling script's directory.
Import-Module $PSScriptRoot\GroupPolicy
I use PowerGUI to convert my PowerShell scripts to executables, and it is working fine.
I'd like to prevent my compiled script from being extracted or decompiled by users I distribute the generated executable to.
Is it possible to view my PowerShell script inside the generated executable? If so, how do I prevent this?
Unfortunately with PowerGUI it's not possible to prevent users of your executable from viewing your script, even if you use the "Protect script source code with a password" option.
The executable that PowerGUI generates is a self extracting ZIP file so it's possible to use 7-zip or WinRAR to open this file and view the original PowerShell script.
If you set a password using the "Protect script source code with a password" option all this does is password protect the files inside the ZIP container. However when launching the generated executable you'll be prompted for said password which can then be used to access the original script.
If you want to somewhat obfuscate the code, look at PS2EXE:
http://ps2exe.codeplex.com/
which points to:
https://gallery.technet.microsoft.com/PS2EXE-Convert-PowerShell-9e4e07f1
download the ps2exe
http://ps2exe.codeplex.com/
run power shell
cd the folder of ps2exe
run:
.\yourfile.ps1 -inputFile C:\Users\franc\Desktop\temp\ps2exe\Install.ps1 C:\Users\franc\Desktop\temp\ps2exe\Install.exe
check the folder, the exe will be there
i want to run netgen in a command line in EIDORS Matlab but every time i come across this problem that matlab ask me for the path of the netgen. i receive this message every time.
'ng' is not recognized as an internal or external command,
operable program or batch file.
Netgen call failed. Is netgen installed and on the search path?
If you are running under windows, I can attempt to create
a batch file to access netgen.
Please enter the directory in which to find netgen.
If you don't have a copy, download it fromhttp://www.hpfem.jku.at/netgen/
Note that you MUST use names without spaces. Thus
instead of C:/Program Files/ write C:/Progra~1/
netgen_path?
yet i define new system variable in windows advanced system configuration and over there i gave the path of the tcl library but it didn't work.
May any body help me ?
Install netgen first. Go here to download:
http://sourceforge.net/projects/netgen-mesher/
Go "Files" entry to download more variant version of netgen. Take note that EIDORS 3.6 is only compatible up to the latest version of netgen-5.0.
I am using Windows 7, 64-bit Operating System. Installation of netgen with x64 and Win32 are worked fine for me. But because as you said, EIDORS requires netgen path to be no space, so when installation, I choose a path other than default "Program Files" (or similar), which has no space.
When EIDORS asks for the netgen path, give the path name until "\bin". These procedures are worked in my computer.
You can place the netgen.exe path " ...\bin " within the matlab toolbox:
How to Set Path in Matlab
thereby not needing to paste the path into EIDORS each time you run it in MATLAB.
Also downloading EIDORS 3.8 with Netgen 5.3 as a zip file avoids having to install netgen separately.
We have a TFS build process using a custom template. The build works fine with the crm solution files successfully being created. We are then attempting to run a powershell script on the post build. This script imports a module. But the commands in the module are not being exposed. Whenever we attempt to invoke a command, we get an error. Along the lines of
The term 'Get-XrmSolution' is not recognized as the name of a cmdlet,
function, script file, or operable program.
It doesn't matter which command we use in that module, we get the same kind of error.
To troubleshoot, we have logged onto the build server under the identity of the build account and can successfully run the script we are attempting to run.
Putting some more output into the script to troubleshoot...
Get-Module lists Xrm.Framework.CI.PowerShell. - Good.
Get-Command -Module "Xrm.Framework.CI.PowerShell" returns nothing. From the console, a number of commands are listed.
Is there something we need to do with the running of powershell post build scripts to enable the contents of an imported module to be seen?
Watch out for the bitness of PowerShell invoked by MSBuild and likewise, the bitness of MSBuild launched by Visual Studio. Certain modules only run in either 32-bit or 64-bit PowerShell and not both. You want to make sure the correct version of PowerShell is getting launched.
IIRC you have to explicitly import the module with no assumption of being loaded on user profile, nor on the script path.
Suppose Module1.psm1 is in the same folder as your script, use something like
Import-Module (Join-Path (Split-Path -Parent $MyInvocation.MyCommand.Definition) 'Module1.psm1')
I had the same problem.
The module was loaded in the 'C:\Program Files\WindowsPowerShell\Modules' folder (64 bits).
It all seemed fine when I logged on as the user, but it failed during TFS build.
Solution: I had to uninstall the module in PowerShell 64 bit and re-install in PowerShell 32 bit.
The module was then installed in 'C:\Program Files (x86)\WindowsPowerShell\Modules' folder.
Wow do we include a batch file in a msi installer which should run every time the msi is installed?
I'm not sure but it might work if you create a custom action to execute cmd.exe and have the path and name of the batch file as a parameter.
Otherwise you can create a custom action that contains a vbscript file that executes the .bat file (or possibly you can use a vbscript instead of a bat file).
Just be aware that I've heard that some antivirus programs can get a bit nervous if you include scripts in your msi and might make the install fail.