I have a script in Powershell ISE that I've added to my ISE profile (The only profile I have) through dot-sourcing. Whenever I open ISE, the version of the script that's loaded is 3.7.2. However, the current version of the script (which the path for the dot-sourcing points to) is 5.3. If I copy the dot source line in my profile and paste it and run it in ISE, the script will then correctly show as 5.3. I've even removed the line from my profile, and the command still shows up when ISE is loaded.
Now, it seems like the script is being cached somewhere. I've checked in my WindowsPowerShell\Modules folder, but I only have modules for ImportExcel and WASP. I never made it into a module in the first place, and I don't see it listed anywhere in Get-Module. Currently the line referencing adding my script is removed from my profile, and checking $profile.Contains("Create-Cert") returns False, which to me means that it's loading the correct file. Another thing I tried was to Dot-Source my $profile in ISE, which did seem to run successfully, but still didn't have the current version, whether or not the dot-sourcing inside $profile was there.
Is there somewhere else that Powershell could be storing this old version of this script? I've searched my computer for references to it, but I can't even find an old version that matches 3.7.2.
Edit: Another troubleshooting step that I've just attempted was to rename my profile and then open ISE. When I did this, the command no longer showed in my command list, and Get-Help Create-Cert came back with an error since it couldn't find it. I then changed the name of my profile back to Microsoft.PowerShellISE_profile.ps1, closed and opened ISE again, and the command loaded with version 3.7.2 again. It's almost like the command is embedded into the profile itself, which I don't even think should be possible.
One additional thing I want to note is that this script exists on a server, and not locally on the computer. I don't think that should matter, since the server is accessable the entire time, but perhaps there's something caching due to that fact.
Edit 2:
On recommendation of Tom Collins, I created a new profile and added just the line concerning my script to it, and this time it worked. When ISE loaded, it correctly loaded version 5.3. I then swapped the naming of my old and new profile, and suddenly it loaded the correct version again. I've tested closing and opening it a few times, and now it's loading 5.3 each time. I'm still at a complete loss for what actually fixed it, and if anyone is willing to offer a deeper explanation I'd be willing to know more.
Adding my triage in as an answer.
Next step I'd take is to rename the original profile, load ISE to confirm it isn't loading, and then manually rebuild a new ISE profile file with just the script (and minimal pre-reqs). Save that as the new profile file and re-run. If that works, then there's something in your original profile that is loading the old script.
Related
While learning Anaconda I had a problem with "cd" not working in Anaconda PowerShell, so I did what is recommended here, manually created a profile and set the path to a specific folder. It worked.
But today somehow I found "cd" is working for me again, so I was going to delete that ps1 file. But the folder together with the file in that was no loner there, completely gone. Now I am stuck with my temporary path on every PowerShell start-up.
According to Microsoft documentation, $profile should return my profile variables, which it did:
C:\Users\myname\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
But first, this is not the file name I gave it; second, this path is also non-existent, both folder and file.
I tried notepad $profile, then Notepad told me "The system cannot find the path specified." But it is exactly the path the system told me.
Some answer I saw here says that is because my profile is non-existent, I need to create one first. That is not the case here. I definitely overwrote my starting path, but I cannot find the actual profile file to edit that back.
I also tried doing it the same way again but changing "YOUR_FILE_PATH" into "%Home" hoping to "overwrite" it back, yet somehow this time it did not work and the file did not disappear as it did the first time.
I am really confused on this.
If you want to reset PowerShell to the original settings when PowerShell was installed.
Uninstall PowerShell from the Add or Remove Programs.
Restart your computer.
Reinstall PowerShell.
I'm struggling to find any method that works with current Unity.
This for a conventional Windows build (not a Windows Universal via VS).
So, there's the separate data, dll, etc files of a build: how to create a civilian-usable "single exe" for Windows, with current Unity??
As said afaik this was actually always the case.
See e.g. Windows standalone Player build binaries to see a list of resulting output of a build. It exists back until version 2017.2.
So the short answer is:
It is how it is. You will always get multiple files and the data folder as output.
What you can do however is using a pack tool which simply packs all your folder content into one single exe file.
One example is Appacker
=>
BUT unfortunately there is one known issue: Windows Defender recognizes it and every exe created with it as malware. The reason for that is actually mentioned by the author in the link
Spoiler: A self-extracting .exe file? Windows Defender hates that trick!
So either with this tool or any similar one there is no real way around that except you need to trust the tool and your users need to trust you ^^
(The icon is also only used for the process window, not for the exe file itself ^^)
The long and correct way would probably be to create an actual installer for your final app which is then allowed to extract all the files to a certain location.
So in the end the user anyway will again have an exe and according data and dll files e.g. in the Programs folder but get a registered shortcut to the Start Menu which is just how any other application on Windows usually works like.
Just to add to the answer.
In 2020 if it's a game you should just use Steam. Making auto-update way easier for your users.
https://partner.steamgames.com/doc/gettingstarted
PS 5.1 on Win10 1709.
It's a sad, unimportant story, but I managed to overwrite the newest source to a script PowerShell module I was modifying. But my open PS session has the newest version imported; I can see the added commands, etc. It just no longer agrees with the version of the source that's on disk, i.e. in c:\Program Files\WindowsPowershell\Modules\<modulename>.
My question is when a module is imported, does PowerShell store the session version of the loaded module somewhere? Is it just in memory (in which case I'm out-of-luck), or is in a tmp directory somewhere?
IOW, if c:\Program Files\WindowsPowerShell\Modules\testmod\1.0 contained the module source, and I do a import-module testmod, and then delete that testmod directory, the PS session can still use testmod, all of its commands, etc. Is the version it imported stored in some secret place temporarily, or is it just in memory?
The reason I even ask (I assumed it was gone and I'd just have to redo it) is that I opened another PS session and did a get-module -ListAvailable. Interestingly, to me anyway, that shows the new version of my module, i.e. shows the new commands. However, when I actually import the module in that session, it's the old version (as I would expect), with only the old commands available.
If the -ListAvailable only showed the old commands, I would assume it's gone and just start re-writing. But the fact that -ListAvailable is showing the new commands, and the fact that the other session still has all the new functionality available, made me decide to ask just on the off chance it copied the current version of the source to some hidden tmp location.
Update: #EBGreen indicated in a comment the majority of the answer; for exported commands/functions, .Definition works even if the original source is no longer available, e.g.
(Get-Module <modulename>).Definition.
But through some more digging around online I also found the means to see the source for unexported functions.
$module.invoke( { (get-item function:<fcnname>).definition } )
I am trying to edit my MATLAB path. I have permission, it does not give me an error when I try to edit via the GUI, but when I close and reopen matlab, the changes are gone.
I have edited ~/matlab/startup.m to include the paths I need the most, and this works, but why can't I edit the path via the GUI?
I assume it is saving my path (because there is no permission warning/error), but it may be that something is destroying those changes, or reverting upon each startup, I guess I'm just not entirely sure where to look.
EDIT: I should mention that I did not set this machine up, and it's a UNIX box that may have other configuration scripts that are messing with the path. (I checked bashrc but there's nothing there that would interfere)
Found a script that the previous admin put into the machine's global profile that automatically sets the path to include various toolboxes.
I have a problem using 'xcopy' command.
I'm building a C# project with msbuild. At the end of the build, a batch file is called to copy my assemblies from Debug/Release to some other folders.
Here is the problem, my build fail and the error log is 'xcopy is not recognized as an internal or external command, operable program or batch file'.
The path is correctly set, xcopy do works from a windows command line and from the visual studio command line (the one set with the project environment).
I tried to set the path in the batch file but it doesn't help.
Any suggestion?
I'm using windows 7
Cheers :)
I encountered the same problem.
It seems to be a problem with the path environment variable within Visual Studio.
When I added a "path" statement to the beginning of my build event, it produced the following output:
PATH=
This seems to indicate that the path is empty within the VS build environment.
When I specify the full path to xcopy like this, the problem went away:
%systemroot%\System32\xcopy ...
I'm not sure what caused Visual Studio to lose it's path.
Set Environment variable PATH = %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
This is not a problem with Windows 7 or 8. It's actually a problem with applications that update environment variables such as PATH.
The PATH is stored in the Registry as an "Expandable string value" (REG_EXPAND_SZ), but a lot of applications write it back to the Registry as a "String Value" (REG_SZ). If your path contains anything like %SYSTEMROOT%, this will not be expanded into C:\Windows (or whatever yours is) if the path is stored in a REG_SZ.
The fix is simply to edit your path manually from the control panel. You need to make a change (eg add a ; to the end of the path) and then apply it. This will fix up your path in the Registry to be a REG_EXPAND_SZ.
(Go to the System Control Panel and select Advanced System Settings. Edit the Path Environment variable in the lower box, and that should fix it.
You can tell whether your path is broken in this way by opening a command prompt and typing PATH. Your path will be listed. If you can see anything enclosed in % % then your path is not being expanded.
It happened to me after I updated one of my Visual Studio extensions, during which Visual Studio was closed and reopened by the updater. I could no longer properly build my project. I closed Visual Studio and reopened it and the problem went away.
I just experienced this for the first time with a batch file I use to copy an Access front-end app to the user's local machines. Their environment is a mix of Windows 7 & 8 and 32-64 bit machines. I noticed that the xcopy.exe was both in the System32 and the SysWOW64 folders and I wondered if there was some conflict. So -- I copied the xcopy.exe into the folder where the batch file resides and it now seems to be working. Just thought I'd share this.
Eileen
I also had a problem with xcopy (same error message) - with a very simple batch program that I use to backup files to a removable drive. Have been using that program for at least 5 years with never a problem. Then yesterday xcopy is unknown to Win7. The replacement of xcopy with %systemroot%\System32\xcopy at each instance solved the problem. Very strange.
Go to environment variable and correct PATh including ; in last.
It will work, this is not at all related to OS or Technology.
It's working for me, Not even need to restart OS, Just open new command prompt.
[Fixed for me]
After adding the correct paths to "Path" environmental variable it still doesn't work (for cmd and VisualStudio) (even after restarting the PC).
The problem was in broken register parameter:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
ParameterName=PATHEXT
I had the value .wlua;.|exe. Maybe was broken after installing something.
Everything works again after changing it to:
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
Hope this helps if nothing other works.