msiexec - How do I specify a blank TARGETVDIR? - command-line

We recently upgraded one of our applications from .net 2.0 to .net 3.5 and we have run into an issue with the installer. Essentially the msi auto populates the Virtual Directory field when we want it to be blank. This wouldn't be such an issue except that I cannot figure out how to set the virtual directory blank from the command line.
Currently I have
msiexec /i $(InstallerPath)\AppInstaller.msi /qn TARGETVDIR=
And I get the error
The folder path 'CURRENTDIRECTORY="C:' contains an invalid character.
. produces The folder path '.' contains an invalid character
Quotes do not work at all.
What can I do to specify a blank Virtual Directory?
EDIT
Using How do I change the default Virtual Directory name during a web service install?
I tried to manually set it blank in the installer project. However, it is already blank!

Stuck into the same question... I've used space to achieve it and it worked.
Example:
> WebSetup1.msi TARGETAPPPOOL="Test" TARGETSITE="/LM/W3SVC/2" TARGETVDIR=" "

Related

Command "docker" not recognized in windows powershell

I am using Windows Powershell (on windows 10). I am also using the latest version 2.3.0.5 of docker desktop. When I type "docker version" in powershell the command is not recognized. The error message reads "Der angegebenen Datei ist keine Anwendung zugeordnet." (English: No application is assigned to the specified file). When I instead include the file extension and type "docker.exe version" the command can be executed. The interesting thing is that "docker version" works in a cmd window, but for some reason not in powershell. The extension ".exe" is contained in the windows environment variable PATHEXT.
What could be the reason that it doesn't work in powershell?
PS: I had an old version of docker installed before. There everything worked fine. Then I updated to the newest version. After that I couldn't use my existing docker containers anymore. So I uninstalled the old version and installed version 2.3.0.5. Since then I have this issue.
tl;dr:
Run Get-Command -All docker | ForEach-Object Path
Among the file paths returned, remove those that do not end in *.exe (use Remove-Item).
The likeliest explanation is that, in one of the directories in your system's path ($env:PATH) that comes before the one in which docker.exe is located, contains another file whose base name is docker:
Either: It is an extension-less file literally and fully named docker [This is what it the problem turned out to be] .
PowerShell unexpectedly tries to execute this extension-less file, because it considers it executable, despite - by definition - not having an extension designated as executable via the PATHEXT environment variable ($env:PATHEXT).[1]
This would explain cmd.exe's different behavior, because it sensibly never considers an extension-less file executable.
Presumably, the uninstallation of the old Docker version removed the original docker.exe, but left an extension-less docker file in the same directory behind (possibly a Unix shell script).
Or: It does have an extension (other than *.exe), which:
refers to a file that isn't directly executable and needs an interpreter - a separate executable - in order to be executed
and that extension is listed in the PATHEXT environment variable
and the association between the filename extension (e.g., .py) and the (information about the) associated interpreter is (now) missing, possibly as a result of having uninstalled the older Docker version.
[1] In fact, PowerShell unexpectedly considers any filename extension executable - see GitHub issue #12632.
However, for those extensions not listed in PATHEXT, execution via the path only works if you include the filename extension in a file-name-only call (e.g., executing file.txt opens a file by that name located in the first folder in the path that has such a file in the associated editor). With an extension-less file, there is obviously no extension to include, which is why confusion with an *.exe file of the same base name is possible (unless you invoke with .exe); if both such files reside in the same directory in the path, the *.exe file takes precedence, but if the extension-less file is in a different directory listed earlier in the path, it takes precedence.

vmoptions classpath with non-ascii characters

I'm adding the following line -classpath/p ${installer:sys.userHome}/.comput/updates/latest.jar to the vmoption file. (Tried both options: via installer 'Add VM option' action and via launcher config).
Works pretty fine with ASCII user name (with spaces as well), but fails with non-ascii user names (I'm testing with Russian). The vmoption file looks fine to me: the path is correct and has the right encoding: CP 1251 for my case:
However the path passed to JVM seems to have incorrectly decoded characters: On the attached screen you may see the actual path passed to JVM (checked via YourKit) from Install4J launcher:
and you may also compare it with the screen when the non-ascii path is passed via command prompt:
The only workaround I have found is to substitute the path with 8.3 Windows path, but converting to it on pure Java seems very error prone to me.
Appeciate your help very much!

How to copy folder (Via Command prompt) which is contain a space in the name?

if i copy without space (Name Folder),
example:
xcopy /E C:\Test\SQL G:\SQL
this copy all content of my folder, Fine!
i dont know how to copy folder if name contain a space, With "xcopy" command.
i found many reviews about space in command prompt and show me solutions like
c:\>xcopy /E "c:\Documents\SQL Server Management\" "G:\SQL\"
but doesn't work for me.
if I copy a folder where the name contains spaces, the result is: Invalid number of parameters...
Any can help me ?
Tnhks
You should report the error message you are receiving, what happened when you executed he command (if anything) and what you expected to happen.
Your problem is that copy requires a filemask to know which files you require to be copied.
c:>xcopy /E "c:\Documents\SQL Server Management*.*" "G:\SQL\"
specifies that all files with all extensions be copied. The quotes are required to specify "paths\containing spaces" as xcopy (or any other command has no way of reading your mind and can't be certain of what c:\Documents\SQL Server Management\ G:\SQL\ means - is it 'copy c:\Documents\SQL to "Server Management\ G:\SQL\"' or 'copy "c:\Documents\SQL Server" to "Management\ G:\SQL\"' or are sume of what appear to be arguments strays data or what?

Passing parameter from TFS Build Process Template to Powershell Script, with two consecutive spaces

So I have created a build process template in TFS 2012 that has to pass a path name to a Powershell Script, which in turn concatenates files in the specified directory.
Some of these path names might have two consecutive spaces, which has turned out to be a problem.
When I invoke the powershell script, I enclose the path name in single quotes, and the command that is executed looks something like this.
powershell C:\psScript.ps1 'C:\tmp\two spaces\myFolder'.
However, when I try and open the directory in Powershell, I get the following error:
Get-Item : Cannot find path 'C:\tmp\two spaces\myFolder'
because it does not exist.
The two spaces seem to have become one, and the path can't be found.
Does anyone know what might be causing this?

'findstr' is not recognized as an internal or external command,

I got the following error while starting JBoss from a command line prompt today:
'findstr' is not recognized as an internal or external command
Please google it, you can find a lot of answers. But do as below to fix it. Add the following value to Right Click My Compuer -> Advanced -> Environment Variables -> System Variables -> Select Path variable -> append the below value.
C:\WINDOWS\system32
It should work with that change.
As others pointed, issue is in wrong settings of PATH variable in Windows.
According to article this is most probably because some stupid installer wrongly modified PATH variable in Windows registry. Registry has 2 different string value types - REG_SZ and REG_EXPAND_SZ. Only the second one allows for expansion of %SystemRoot%.
So check your path by typing set path in command prompt. If you see unexpanded %SystemRoot% and other variables in Path, you are affected (PATH should show only plain directory names, not variables).
You need to edit Path variable in registry: HKEY_CURRENT_USER\Environment and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. As it is not possible to change the type of key, save the path value somewhere, delete the key and re-create it with type REG_EXPAND_SZ. You need to logout for changes to take effect.
for me it works when I've coped findstr(from windows/system32) to wildfly/bin
Please go throught the simplest steps:-
go to C:\Windows\system32\ and copy findstr.exe file.
paste this file into the location C:\Program Files\Java\jdk1.6.0_24\bin
Run your jboss again you will get out of this.....
Check to see if you %SystemRoot% is evaluating (type set path into a command prompt, you should not see %SystemRoot%, but instead that actual path). If your path variable's (user, or systems) first entry begins with an %(an environment variable) this can cause an issue.
To resolve this, simply swap this first entry with anything else in your path that does not lead with an environment variable.
You can also hard code the directory by replacing 'findstr' with 'C:\Windows\system32\findstr'. This is useful when using systems with restricted user permissions.
I have try to work with play framework but stuck with to run activator.bat file but solution is the same just copy file from windows/system32/findsr and past it to under stuck folder then run the respective file again.
thanks to andrewsiand Suryaprakash
Please beware that current Windows systems use a Capital "S" for the System directory, so:
C:\WINDOWS\System32
%SystemRoot%\System32
Omitting the capital S will result in a neglect of the line in the %PATH%
In my case (not JBoss related) the following helped to fixed this error.
Instead of:
SET path="%path%;C:\some\additional\path"
I used:
SET "path=%path%;C:\some\additional\path"
For IBM ACE solution for
'findstr' is not recognized as an internal or external command,
Go to the path C:\Windows\System32
Find the findstr.exe, copy it and then find the path where you bin file of your application is found. eg C:\Program Files\IBM\ACE\11.0.0.12\server\bin then past it inside the bin file
cancel the console of ace and re-open it.
Then run ACE toolkit command on ace console.
Then press enter, now it can open.