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
Related
I need to install PSReadline module in an offline computer
with
Windows 7 SP1
and powershell 5.1
I have another computer that is connected to the internet.
Could you please explain how to download the relevant files
and how to install them on the offline computer?
If you download it to an online computer the module will be in one of your module paths - type:
$env:PSModulePath
...this will list all the possible paths, just search for the correct folder and copy it to the offline computer in one of its module paths. If there are any dependencies these will need to be copied also.
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.
Why does Test-Path -Path $folder -PathType Container return true, but folder does not exist?
The Path is:
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\MyCompany\Modules
Same code in ISE x86 and ISE, but different results
The answer is here
Excerpt:
The 'System32' folder is for 64-bit files and the 'SysWOW64' folder is for 32-bit files
This can be somewhat confusing, but the System32 folder is intended
for 64-bit files and the SysWOW64 folder is intended for 32-bit files.
This may seem a bit illogical if you look at the folder names, but
there is an explanation to this. It has to do with compatibility. Many
developers have hard coded the path to the system folder in their
applications source code. They have included "System32" in the folder
path. And to preserve compatibility, if the application is converted
to 64-bit code, the 64-bit system folder is still named System32.
But what about 32-bit applications that have the system path hard
coded and is running in a 64-bit Windows? How can they find the new
SysWOW64 folder without changes in the program code, you might think.
The answer is that the emulator redirects calls to System32 folder to
the SysWOW64 folder transparently so even if the folder is hard coded
to the System32 folder (like C:\Windows\System32), the emulator will
make sure that the SysWOW64 folder is used instead. So same source
code, that contains a path with the System32 folder included, can be
compiled to both 32-bit and 64-bit program code without any changes.
So remember: • the SysWOW64 folder is intended for 32-bit files only
• the System32 folder is intended for 64-bit files only It is very
important that a binary file compiled to a specific bitness (32 or 64)
is installed to the correct system folder. Otherwise the program that
needs the file will not be able to load the file and will probably not
work as expected.
That's why ISE x86 output is in SysWow64 folder and the call to:
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\MyCompany\Modules
is redirected to the SysWow64 folder.
The ISE console is running as x64 and therefore will look in System 32 and will not find this folder, but the folder was created in ISE x86 console, which saves the folder under SysWOW64.
I downloaded the MongoDB for Windows 64-bit from http://www.mongodb.org/downloads.
File name: mongodb-src-r3.0.3.zip
However, the zip folder doesn't have a bin folder & no .exe files to use for installation (as given in the installation steps).
The below commands say that I use Windows 7 64-bit architecture.
wmic os get caption
wmic os get osarchitecture
Even tried using the .msi (Installation Package) given in the same downloads page. It doesn't give any error. But still the bin folder is not created to test MongoDB (mongod.exe).
Am I missing something?
I also faced the same problem as #ArcherGilly told to install again and select the custom options and by doing this finally I found the bin folder with other txt file like license
C:\Program Files\MongoDB\Server\4.0 -> Previously there were only two folders
data
log
and Now along with the above two folders, there is bin folder along with 4 more files
LICENSE-Community.txt
MPL-2
README
THIRD-PARTY-NOTICES
THIRD-PARTY-NOTICES.gotools
I had the same problem, but once I used the .msi installer and selected 'custom', instead of 'complete', it installed the /bin folder.
I had the same issue.
It could be because you changed the installation directory to another drive where the windows folder isn't.
So if this your case, simply find the bin folder in the C: drive.
After the installation, I used the installer and chose the make changes option without making really any changes. After the process was finished I found the bin folder.
After downloading the msi and installation process. I found the bin folder but there is no mongo.exe file in that folder.
But when I run the path enclosed in " \mongo.exe" in command prompt, the mongo db is running.
while using .msi installer please select 'custom', instead of 'complete', it will create the bin folder at \Installation_Dir\MongoDB\Server\4.2\bin\
Thanks
This is with respect to this question which I had asked earlier - Powershell: Installing Modules on Target System
What is the default module load path ?
Now after so many days, it has started giving this error (from my C# code)
Cannot find path 'C:\Users\angshuman\Documents\WindowsPowerShell\Modules\MyPSModules\MyPsModules.psd1' because it does not exist.
All the while it was nicely loading from the SysWow64 folder path
Why it is suddenly searching in user folder rather than Windows folder?
I am executing the same code via C# on a Windows 7 64-bit OS
_ps = PowerShell.Create();
_ps.AddScript("Import-Module MyPSModules -PassThru");
Collection<PSObject> psObjects = _ps.Invoke();
And if you want to have them to have a better readability you can use this:
$env:PSModulePath.split(';')
$env:psmodulePath is the automatic variable which holds the path used to discover modules. If it's not set, PowerShell looks in c:\windows\system32\WindowsPowerShell\v1.0\modules and MyDocuments\WindowsPowerShell\modules.
So it should by default always be looking in both places.
I haven't done much 32-on-64 coding, but I could see it using SysWow64 (instead of System32) if you were running a 32-bit app on a 64-bit OS.