We have a custom PowerShell script that calls into the BizTalk PowerShell Extensions, that needs to be invoked by a TFS Agent (from Release Management).
The thing is, the BizTalk PowerShell Extensions requires x86 mode, whereas TFS PowerShell on Target Machines task seems to be executing the PowerShell on Target Machines in x64.
Is it possible to solve this by using any of the below approaches?
By using some undocumented argument to the PowerShell on Target Machines task?
Have a x64 script invoke the 'real' scripts in x86 mode. I'm not really familiar with PowerShell, and it might be trivial to do, but I would need to figure out how pass my arguments to the x86 script.
Run the TFS agent service in x86 (e.g. via CorFlags)? I'm not even sure this would even work, and it feels dirty too....
SysWow64 technology allows you to execute 32-bit apps in a 64-bit environment.
On your target machine, please execute PowerShell scripts using the below the app
%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe
This would be the 32-bit version of PowerShell.exe and will let you execute your files.
In your batch file, you can make this configuration
Related
What is the difference between [pwsh] and [Powershell Integreted Console] on VS Code?
I usualy use pwsh.
Today, when I installed the powershell extension and then tried to update the powershell, the Powershell Integreted Console started up and found out. What is this?
pwsh[.exe] is the executable file name of PowerShell [Core] (v6+), the cross-platform edition of PowerShell built on .NET Core / .NET 5+; by contrast, powershell.exe is the executable name of the legacy Windows PowerShell edition (v5.1-), built on the Windows-only .NET Framework (v4.8-)
Windows PowerShell comes with Windows itself, whereas PowerShell [Core] must be installed on demand (on all supported platforms).[+]
VSCode (Visual Studio Code) has an integrated terminal (console) that can run any shell, such as cmd.exe, bash, or pwsh or powershell.
Shells that run in the integrated terminal by default have no special integration with the files being edited. They show by their executable file name in the dropdown list in the integrated terminal's toolbar; e.g.:
By contrast, the PowerShell Integrated Console is a special shell that comes with the PowerShell extension and offers integration with PowerShell code being edited, notably to provide linting and debugging support, among other features.
The PowerShell Integrated Console starts on demand when you first open/activate an editor with PowerShell code in a session, and it shows as follows in the integrated terminal's toolbar:
You can use the PowerShell extension's configuration to choose the specific PowerShell executable to use, which on Windows allows you to choose between running PowerShell [Core] (pwsh.exe) and Windows PowerShell (powershell.exe) in the PowerShell Integrated Console.
If a PowerShell [Core] version is installed and it is installed in a well-known location[*], it will be used by default; the fallback on
Windows is Windows PowerShell. Since PowerShell [Core] versions can be installed side by side, you can switch between different versions, if installed.
If a PowerShell [Core] version in installed in a nonstandard location and is therefore not discovered automatically, you can tell the PowerShell extension where to find it, either via the Settings GUI or via settings.json, as shown in the linked topic and the bottom section of this answer.
Whenever the active tab is a PowerShell source-code file, the status bar in the bottom-right corner shows the PowerShell version that is being used if you however over or click on the {} icon; versions >= 6 imply PowerShell [Core].
If configured, there's a separate icon that directly invokes the PowerShell session menu when clicked and which reflects the active version number - again, see the bottom section of this answer; e.g.:
[+] as of v7.0; time will tell if PowerShell [Core] will ship with future versions of Windows, and perhaps even other platforms.
[*] From the linked docs: "This feature looks at a few well-known paths on different operating systems to discover install locations of PowerShell. If you installed PowerShell to a non-typical location, it might not show up initially in the Session Menu. You can extend the session menu by adding your own custom paths." If you use one of the official installers, the PowerShell extension should find your installation.
We have configured a windows virtual machine and deployed an agent there to build our code and run scripts.
In our VM we two different flavors of PowerShell command prompt:
Windows PowerShell
Developer PowerShell for VS 2019.
How can we start "Developer PowerShell for VS 2019" from our pipeline YAML script and execute our checked out .ps1 file there?
There are several flavors of PowerShell tasks that can be initiated from the pipeline though and not sure which one of them will serve the purpose. They are the following:
Azure PowerShell
PowerShell
PowerShell on Target Machine
Service Fabric PowerShell.
Which of the above represent "Developer PowerShell for VS 2019"?
The reason behind this specific flavor of PowerShell is:
Need to have some of the .NET Framework Tools (CorFlags.exe) which are only accessible in the "Developer PowerShell for VS 2019" and not in the other one.
The Developer PowerShell for VS 2019 is a regular PowerShell with a module imported, you can see exactly what in this way:
Go the Start menu and search for Developer PowerShell for VS 2019.
Right-click on it and Open file location - you will get this:
Now right-click again on the Developer PowerShell for VS 2019 shortcut and Properties.
You will see in the location that is run the regular PowerShell with some command:
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -noe -c "&{Import-Module """C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\Microsoft.VisualStudio.DevShell.dll"""; Enter-VsDevShell bc97b47b}"
Now, if you open a PowerShell and run the script there:
&{Import-Module "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\Microsoft.VisualStudio.DevShell.dll"; Enter-VsDevShell bc97b47b}
You will get the Developer PowerShell for VS 2019 and CoreFlags.exe will work:
So, you need to use the regular PowerShell task (your option 2) and run the above command at the begging of the script.
Note: you should copy exactly the command you see in the Properties, in each machine it could be different.
Newer versions of the PowerShell ISE (and third-party PowerShell scripting environments like PowerGUI) offer pretty good IntelliSense support.
However, I often write scripts that I want to run on servers which only have older versions of PowerShell installed (in particular, PowerShell 2.0 on Windows Server 2008 R2). I can't upgrade the PowerShell installation on the server and the PowerShell 2.0 ISE doesn't have IntelliSense.
Is there any way to configure the PowerShell 3.0 or 4.0 ISE, or PowerGUI (or any other free PowerShell script editor!) to provide IntelliSense which is restricted to PowerShell 2.0 compatible code only?
I have confirmed Jason's theory that Intellisense does work in PSRemoting against the installed version of Powershell, but it looks a bit different. I tested using Powershell preview build 5.0.10018.0 remoting to Server 2008R2 with PS v2.0. I ran:
$Procs = Get-Process
$Procs <Ctrl + Space>
This resulted in an Intellisense tooltip with options like:
$Procs.count
$Procs.Clear(
Where v3.0 and up would only include the property or method names, not the variable itself.
I also tested for the .Where() and .Foreach() magic methods which did not show up in Intellisense. This seems to confirm that it's working against the installed version.
I know that this is possible in principle, but the tools may not exist to do it:
Rather than booting up XP-Mode or some other VM to use Leydesforff's tools (http://www.leydesdorff.net/indicators/index.htm), I'd like a very thin command-line vm that I can use to just run a single 16-bit .exe file and pass input back and forth, i.e.:
vm.exe "oldthing.exe" -options ...
Or, any other way that I can write scripts (.bat, python, something like that) using these 16-bit .exe files that I can run on my Win7 x64 machine...
If they are DOS programs you can run them in DOSBox. It is a DOS/16bit x86 emulator writing primarily for games, but it should run any DOS application.
You can start it with a command line option indicating which application you want to run in DOSBox:
C:\Program Files\DOSBox-0.72\dosbox.exe" -conf "C:\Program Files\DOSBox-0.72\dosbox.conf" "C:\Games\Settlers 2\S2.exe"
I was wondering if anyone has successfully ran Nant on Windows Vista 64 bit version. It keeps failing with
set-props:
[sysinfo] Setting system information properties under sys.*
BUILD FAILED
Property name 'sys.env.CommonProgramFiles(x86)' is invalid.
Yes, it works. NAnt is by default built for 32-bit. Therefore, one has to remember to run this in a 32-bit command prompt or PowerShell. I run NAnt scripts out of PowerShell (x86) mode on a Vista 64 machine, but an SDK prompt (32-bit) would works as well.
It also has worked well for me. I do run as Scott said in a 32bit command prompt.
It could also be just a specific thing you are trying to capture that nAnt is not expecting.
I've been using NAnt on my Windows 7 64 bit environment, and have found that in order to do so (without needing to use a 32bit command environment) is to simply remove the reference in your NAnt scripts to sysinfo.
I have been through our build scripts over and over and cannot see any downside to removing this setting, as I cannot prove that I'm using the result of it anyway, other than to dump lots of data to the screen which is invaluable during debugging!!
Hope this helps!