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!
Related
I have a windows batch script that, depending on the user menu selection, opens a powershell.exe and passing a variable to run a .ps1 script. I then use Bat To Exe Converted (v3.0.10) to convert it to an exe. A few hours ago I made changes to the PS script and copied it to the Win'2019 server and it accepted it. Now, I just changed two letters in a write-host message command and it keeps quarantining the file. Since this will be passed to customers I can't be telling them to ignore it or white list it.
I'm guessing the .bat and .ps1 files are throwing Windows Defender off. Funny how it was fine just a few hrs ago. Even if I undo the 2 letters I added it still deleting the exe.
The .bat is quite big and it'd be very difficult for me to convert and add inside the .ps1 script in hope of not setting off the trojan. What other options do I have to fix this? Is there a process or url to notify MS about this to get them to fix this false positive?
NOTE: No other Windows version or 3rd party antivirus that I've tried is detecting the exe infected. Only Win'2019's Defender is.
It looks like MS has fixed the false-positive with my code. I came in to work this morning and tried to copy the exe again and this time it worked. I didn't even contact MS (we don't have a support contract anyway).
Btw the exe consisted of a bat and ps1 script that just downloads some public install files (such as 7zip) from an https address, saves them and when running the exe the user would just get a menu of which of the downloaded programs they want to install.
The issue can be reproduced creating a simple new console application (Language : C++) with Visual Studio 2019 (Community Edition) and then just run program: Ctrl + F5. The solution that worked for me, to run the program, was to add the folder as an exclusion in Windows Defender Antivirus. I couldn't find any solution on other threads
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
I’m using the Powershell extension for Visual Studio Code. I updated the profile:
C:\Users\xxxxxxxx\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1
To include some functions and variables that I want to make available to other scripts. When I reference a variable from the profile within another script, it does not appear that the profile has been loaded. I suspect this because the variable value is blank when I query it from the VS Code console. If I run the same test from the standard Powershell console with an associated profile, the variable value is resolved.
Can anyone tell me what, if anything, I need to do to use a Powershell profile in VS Code while debugging?
There are several profiles. The starting point is the four locations that you can find by reading the following properties of PowerShell's built-in $profile variable.
$profile.CurrentUserAllHosts
$profile.CurrentUserCurrentHost
$profile.AllUsersCurrentHost
$profile.AllUsersAllHosts
As noted in this article by The Scripting Guy, because Windows has both Powershell and the Powershell ISE, you have at least two possible values of Current Host, so at least 6 profiles.
I've tested this in the Visual Studio Code terminal window, and it seems that the "CurrentHost" profiles are the same as you get by simply running a powershell instance. I'd assume then that Code isn't seen as a distinct host, and just runs a normal powershell.
Once you've got that far, there's another possible complication, which is that the AllUsers profiles are down in C:\Windows\System32 and hence on a 64 bit system, also mirrored in C:\Windows\SysWOW64\. So depending on whether you are using a 32 or 64 bit editor, and whether the Powershell is hosted in a 32 or 64 bit process, it is quite possible that the file you are editing has no influence on the Powershell.
Inside your debug session run: $profile. This will return the path to currently used profile file, so you can make your changes there.
Alternatively you could change the system wide profile in C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
With the just released version 0.10.0 of the VS Code PowerShell extension debugging with a previously loaded profile.ps1 being available is now implemented. Note that the interactive console and the debugger share the same PS session.
If you type $profile in the "PowerShell Integrated Console" of VSCode, you will see the path to the profile used:
C:\Users\xxx\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1
Now if you type $profile in a normal terminal, you will see your "normal" profile: C:\Users\xxx\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
Now the easiest solution that did the trick for me is to create a hard link between the two files (the VSCode_profile.ps1 file didn't exist in my case):
mklink /H Microsoft.VSCode_profile.ps1 Microsoft.PowerShell_profile.ps1
Reload VSCode and you are all set!
I'm evaluating install4j in our company.
We build a win32 installer and we are trying to set up a continuous integration environment to test it.
The CI server is able to upload the installer to the windows target machine (which is a virtualized environment) using FTP, and run batch script that looks like
cd c:\tmp\upload\
my_installer.exe -q -varfile response.varfile -console
Currently we're using the trial version of install4j 5.
When the installer is ran from the command line (cmd.exe over remote desktop) I get a popup window that warns about the trial version.
Installation is frozen until I click ok.
When the installer is ran from telnet the command just hangs and never returns. I believe the reason is that popup window.
To fully evaluate install4j we need to be able see how it fits our CI process.
Is there any workaround for this?
This is a restriction of the evaluation version, with a permanent license key the evaluation dialog will not be shown and the problem will go away.
I'm writing a Kernel mode usb-driver primary for Windows Vista 32bit but hopefully it will also be able to be builded for Win XP, Win Vista, Win 7 32 and 64 bit.
Anyway, I'm debugging from an Windows 7 32bit laptop to a Windows Vista 32bit laptop (the target). The laptops are connected via Firewire and the connection seams to be ok since I can set some breakpoints and step trough parts of my code. All information is in assembly though and WinDbg says "Your debugger is not using the correct symbols..." when I hover over an function in my driver.
Symbol file path is:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;C:\Me\MyDriver\objchk_wlh_x86\i386
Source file path is:
C:\Me\MyDriver
Everything is newly compiled but WinDgb still won't accept my symbol files. Why?
If you can set breakpoints and step through your code it sounds like your symbols are fine. You can try:
!itoldyouso mydriver
If you want the debugger to convince you that your symbols are OK.
I never use the hover feature in the GUI, but it's entirely possible that it just doesn't work properly in some cases.
-scott