When I do $PSModulePath I get C:\Program Files\WindowsPowerShell\Modules returned as one of the paths. This is on an air gapped environment so I need to manually copy the module to the server for multiple users to use rather than them each maintain their own version etc.
However, when I do Get-Module -ListAvailable it only returns the list of modules in C:\Windows\System32\WindowsPowerShell\v1.0\Modules.
My initial thought was that this was a Windows PowerShell 4 issue as compared to another system with Windows PowerShell 5.1 which worked that was all I could see different. However, on another system with v4 it behaves as I would expect.
Anyone seen this or know how to fix please? The module I am trying to use is VMware.PowerCLI.
Related
Yes, I know vb6 ancient and all that. It's still an interesting question. and the issue might not even be with vb6....
Background: We have a server running a vb6 application for our users who access this via Citrix. This installed application accesses its DLLs (also written in vb6) from a "shared folders" location.
What I want to do is have the previous version of this same app on the same server, accessing it's own set of (previous versions) DLLs. I am half way successful. the renamed app in another directory runs. But it crashes immediately upon using any feature that draws from the DLL's code.
Apparently the registered DLLs of the current version are being called upon. I dont want that. I want the DLLs found in the same directory as the renamed older app to be called upon.
Can that happen in a windows server? is this an installer's settings issue? Have you ever had this situation before? were you successful?
thanks in advance.
Harry
Post Script:
The bosses decided that experimenting with the DLLs and system settings was a waste of my time and not worth the risk. So they're throwing money at it and another server will come online for the sole reason of providing the previous version to the citrix users who want it. Thank you to all of you who pitched in with great tips and leads to other posts. (yeah I'm sort of disappointed too. Kind of wanted to know what the solution was to this.....)
The OS should be looking for the dll’s in the following places and order
The directories listed in the App Path registry key (HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp
Paths) if any
The directory where the executable module for the current process is located
The current directory
The Windows system directory
The Windows directory
The directories listed in the PATH environment variable
Given that you are using a shared folder for your dll’s, I would suppose that the app is setting the current directory to your shared folder OR is using the PATH environmental variable to specify where to look. I don’t think it is using the app path registry key path because that is version specific and you said you are using a different version.
I would suggest your try setting the path via HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths
I'm trying to avoid having to restore my PC and get it back to where I was. I was recently going to delete a folder using Shift+Del, but without paying too close attention I hit Shift+Del on the modules folder in C:\ProgramFiles\WindowsPowerShell\Modules.
I had re-imported PowerShellGet, PackageManagement, as well as Pester.
I thought I was in the clear but I keep running into issues, I have to always Re-Import PowershellGet. Then I get another error.
Get-PSRepository : The term 'PackageManagement\Get-PackageSource' is not recognized as the name of a cmdlet, function, script file.
Even after doing Import-PackageManagement I still get that error.
If I do (Get-Module -List Available -Name PackageManagement).Exportedcmdlets it shows that Get-PackageSource is there.
I'm really not sure what I need to do to fix this.
I have uninstalled and reintalled WMF 5.1, but the issue persists.
I am running Windows 8.1
PowerShell is an open source project. You can download the modules from github. That link also describes how to get from PowerShell Gallery, which may work for you.
Main PowerShell repo
PackageManagement (aka Oneget)
The issue seems to be with PackageManagement, 1.1.4.0. I deleted that reimported PackageManagement based on what i read here. https://github.com/OneGet/oneget/issues/195
It seems to be working now.
I have a 32-bit legacy application that allows users to specify the install path as part of the setup (pretty normal stuff...). I also have a custom action defined that runs a silent background install of another required bit of software after the initial installation is complete.
All is well when users install to the 32-bit Program Files (x86) directory.
Where I am running into problems is when users specify the 64-bit installation directory, Windows automagically changes the install path in the background to use the (x86) Program Files folder, which is fine, except that my custom actions that use the same INSTALLDIR property after the initial install is finished still think that it should be the 64-bit "Program Files" path - so the install fails when the custom action can't find the EXE file it's looking for.
My program is essentially exactly the same as the one described here by another developer but never resolved in that forum: http://community.flexerasoftware.com/archive/index.php?t-216268.html
Does anyone have a clue what a valid workaround for this is? It seems pretty basic that an installer should not fail just because users think they should install to "C:\Program Files\Appname" instead of "C:\Program Files (x86)\AppName".
I did peruse the similar questions on here but I don't see anyone else with this issue using custom actions.
In my experience you need to change to a 64 bit template to install to program files. General information in the tree > Template summary > change to x64;1033. At least one file needs to be marked as 64 bit in each directory. It is a check box on the component property. Be sure to check your custom actions still obey run conditions on major upgrades. I am having issues with that currently. Major upgrades on mine is set to remove all and it runs all custom actions no matter the conditions on the removal portion of the script.
I just discovered why Maven doesn't work properly on my machine. For some reason it reads the user configuration from the completely wrong location. And I don't understand why. When I run maven with the -X switch I get the following output in the beginning:
[DEBUG] Reading global settings from D:\dev\maven\active\conf\settings.xml
[DEBUG] Reading user settings from D:\.m2\settings.xml
[DEBUG] Using local repository at D:\dev\maven_repo
Why is it reading user settings from D:\.m2 and not my actual user directory like it normally should? It worked fine on my old computer. Does it have something to do with me having installed maven on a different drive this time? On my old computer it was installed on the C drive.
Where does it get this D:\.m2 from? How can I make it read the user settings file from the actual default location, %userprofile%\.m2?
Finally figured it out. Found the solution in this blog post. To find the home directory in Java you do this:
System.getProperty("user.home");
Problem is, for some dumb reason, Java isn't using Windows environment variables or anything like that to find this path. It actually uses the parent directory of the Desktop directory. Since I like to keep certain main folders in my user directory on a separate drive (documents, downloads, music, desktop, etc) I had moved the desktop directory to D:\Desktop. Java then takes that directory, goes one level up and makes Maven and other java applications think D:\ is my home directory.
Gotta say the more I use Java the more i hate it... anyways, hopefully this might help save some hours of head scratching for someone else too.
Update
The original blog post is gone, but found on the WaybackMachine (the URL has been updated), but here's the gist from that post in case that goes too...
The issue: So how does Java play into all of this? Well, Java
developers sometimes want to store settings for their applications in
a folder within the user’s profile directory. It’s the Linux way, and
Java tends to do things the Linux way. (As mentioned earlier, Windows’
“AppData” folder servers the same purpose, with some extra separation
for data dependent on whether or not it should roam with the user’s
profile.) For some reason, Java does not use the Windows environment
variable to determine the location of the user’s profile, but instead
access a registry key that references the user’s desktop folder. It
then takes the parent directory of the desktop and assumes that is the
user’s profile folder (assuming the user makes use of the default
setup Windows chooses).
Essentially, when a programmer calls the Java command:
System.getProperty("user.home");
Java uses the following idea to determine where my user profile folder
is:
PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"
This breaks down when the desktop folder has been modified.
So, with my setup, instead of saving settings at:
c:\users\tim\
Java apps tend to save data to:
t:\tim\
In reality, Java apps should save settings to:
c:\users\tim\AppData\Roaming\
or something like that.
To add insult to injury, the Java apps continue to follow the Linux
way and use a period at the beginning of the folder name in an attempt
to “hide” the folder (as is done on Linux). For Windows users, this
simply ensures these folders are listed first in directory listings.
(Hiding a folder on Windows is achieved through setting the hidden
attribute for the file.)
It looks like NetBeans has addressed the issue for their application,
but the root issue remains an unresolved, low priority bug. Somehow
I’d bet it would get fixed a lot faster if the mechanism for
determining the user’s home path on Linux was wrong.
I got Team Explorer Everywhere so we can use TFS on the Mac Mini we got to test Iphone apps. Since we're using XCode for phonegap, we need to use the commandline program and it is giving me a lot of grief.
What I've done so far (Listing out for anyone who stumbles on this so they can use it):
-Downloaded the trial (free)
-Set the path using PATH=$PATH\:/FOLDERLOCATION
-Accepted EULA and got trial product key... for command line program (tf eula/tf productkey -trial)
-Set up workspace:
tf workspace -new WORKSPACENAME -server:http://SERVERNAME:PORT/FILEPATH -comment:"WORKSPACENAME" && prompted for username -> domain -> password
-Trying to setup the folder path (Fixed):
tf workfold -map SERVERFOLDERPATH LOCALFOLDERPATH -collection:http://SERVERNAME:PORT/FILEPATH -workspace:WORKSPACENAME && prompted for username -> domain -> password
-Make sure I can check out/check in (On hold):...
The error I'm getting right now is "An argument error occurred: First free argument must be a server path." This is what I've been following ever since I got the path set, but I think the versions are different because mine doesn't seem to be set up the same. Any help at all would be appreciated, and I'll keep up with the post as I figure parts out because there doesn't seem to be much online that I can find on TFS on macs.
Update: As normal, I'm an idiot. Have to put the options at the end of the command and have to have the serverfolder path as the first thing after -map. Now I just need to figure out how to use the damn thing. I'll post any other questions I have and try to get all the correct commands up for the selfish reason of having them somewhere in case I forget them later.
Update 2: The mapping hasn't worked out as well as I'd hoped, it seems a combination of my unfamiliarity with Unix/Mac file systems and some settings being missing is keeping me from using 'tf get' to load all of the test data I was trying to get. I'm planning on trying again after I get the location of where my boss wants the data saved and after I can look into something that would save the workspace so it won't say that it can't find the map path every time...
It looks like you're setting up your workspace and some working folder mappings just fine, after the edit. If you're having problems doing a tf get after this, then there are some common problems that might be occurring. TFS workspaces can be a little bit opaque and having a better understanding of them can sometimes help you understand where the problem is:
Team Foundation Server requires a workspace to be configured before you can get files out of source control, edit them or check them back in. A workspace basically simply contains working folder mappings that map your local path(s) to server path(s).
Workspaces are stored on the server and are uniquely identified by your computer's hostname, your username and the workspace's name. A cache of this information for the local host is saved on the client. This implies:
If you remove a workspace on the server, your workstation will be unable to connect.
If you remove the cache, your local computer will not be able to identify the workspace based on working folder mappings until the cache is rebuilt (which happens every time you connect to the server.)
If you change your username or local workstation's name, you cannot access those workspaces.
(Note that very early versions of the Teamprise command line client had certain issues on Mac OS that made identifying the local workstation name difficult. This is fixed, however, in Team Explorer Everywhere.)
Because you can have multiple workspaces for a single server on a single workstation, you can't always simply provide server paths to tf commands, since server paths are ambiguous. ($/ exists in every workspace, for example.) So the command line client resolves paths based on the current working directory and/or the arguments provided. Meaning that you can run tf get foo.txt if you're in a working folder, or you can run tf get /tmp/foo.txt if /tmp is mapped.
One more point - the configuration data for Team Explorer Everywhere is shared between the TFS plug-in for Eclipse and the command line client. So if you're more comfortable using a GUI to set up your workspace(s), you can do that and then use the CLC as you see fit. You don't need to be a Java programmer to use Eclipse - simply download Eclipse and install the TFS plug-in for Eclipse into it, and select Window > Open Perspective > Team Foundation Server Exploring. After that, you'll have the full GUI Team Explorer experience and this perspective will be restored when you open Eclipse, so you won't even need to worry about the Java IDE bits if you don't want to.