On Windows Server 2008 64-bit, I need an .msi installer file to write some files to \windows\system32\inetsrv folder. (The files are some XML Schema validation files, that C# XmlReaderSettings.Schema.Add() expects to be in that folder).
When the installer runs, the files end up in \windows\SysWOW64\inetsrv folder, not where they need to be.
I attempted to have the installer then write to \windows\Sysnative folder, and the installer created a folder with that exact name, which I didn't expect to be possible. See this page for a good discussion on suppressing SysWOW64 redirection.
How should I get the .msi to write my files to the \windows\system32\inetsrv folder on Windows 2008 64-bit?
Here are the system folder properties you can use. I know it is counter-intuitive, but have you tried System64Folder? Read the remarks.
If that doesn't work, try just tacking System32 on to the end of WindowsFolder.
Edit-1: Try setting the Win64 attribute on your Component element and see if the redirection behavior changes.
I tried to use Sysnative in wxs file but I got the same result: create a Sysnative folder under Windows instead of using System32.
So I used Sysnative in a vbscript CA: found the Windows folder (&H24&) and append \Sysnative. This works, but a second CA is needed to delete the files during uninstall.
I solved my problem by writing the files to \windows, rather than \windows\system32.
It turns out that the C# XmlReaderSettings.Schema.Add() will work with a fully qualified path under the \windows directory. It just defaults to the system32 folder if the path supplied is not fully qualified.
This isn't really an answer to the question, but it is a work-around for my immediate needs.
Related
I'm trying to create a self-extract EXE to run my installer program, which is conformed by 3 files so I need to pack it for distribution.
The problem is that once the file is created using WinRAR, it's automatically deleted by Windows Defender because it thinks it's a trojan named Wacatac.
What can I do about it?? I can't find any info on this trojan to know what to do to avoid this.
Fixed - I had to switch compression format to ZIP instead of RAR, this way Windows Defender no longer identifies the file as a virus/trojan.
The TexLive system uses lualatex. I have an application that needs to know the location of lualatex.exe.
Now, if lualatex is in the PATH evnvironmental variable, I'm in luck. If it isn't there, then I have to go and do a full-computer file-search for the file.
Is there another way I could find it?
I mean, is there some lualatex registry value or directory that is standard in every installation?
[update]
Okay, I have found a certain standard; if TexLive is installed, in the %userprofile% directory, there will be directories for .texlive2012 or .texlive2013 - I wonder if there is a way to use that knowledge to find the installation directory. The contents of those folders do not reveal anything, however.
It depends on what LaTeX installation you are using. If it's MikTeX (under 64 bit Windows) it will be in
C:\Program Files\MiKTeX 2.9\miktex\bin\x64\
So I think it will always be in "the bin folder".
I want to be able to program LUA in Visual Studio 2013 Ultimate. I have BabeLua to try to do this. In the program there is a tab called settings. Within that tab there are 5 textboxes that I do not understand
LUA Scripts Folder -
Folder where the files are stored? (Documents/Visual Studio 2013/ Projects)?
Lua exe Path
Working Path
Command line
Setting Name
Can someone give me an explanation to all of these Fields?
This prompt seems to be slightly different than the one I am seeing with the latest update of babelua, but regardless:
Lua scripts folder: This should be the explicit path to some file folder where your script is located.
Lua exe path: explicitly provide the path to your exe (which you can download from here.
Note: be sure to download the windows 32 Bit version, even if your machine happens to be 64 bit. There appears to be some sort of bug
that prevents Babelua from running in debug mode with the 64 bit
version.
Working path: I just provide the same path to the folder containing the lua exe.
Command line: This is where you provide the name of the script(s) you want to run. If you wrote a file in your project called "script.lua" you would provide the name of that file, with the extension, in this area.
Lua project name: This is different than the "setting name" prompt you have, but its rather self-explanatory.
Example:
Lua scripts folder: C:\Users\kevin1michael\Documents\LuaScripts
Lua exe path: C:\Users\kevin1michael\Documents\Lua\32BitLua\lua5.1.exe
Working path: C:\Users\kevin1michael\Documents\Lua\32BitLua
Command line: script1.lua
Lua project name: Project1
Using Advanced Installer, I have created and run a simple installer that contains a single .exe.
This .exe started as an executable jar (w/ splashscreen) and was built into a Windows .exe using Launch4j.
Once the application is installed (in C:\Program Files (x86)...), I can't execute it from the installation directory. However, if I copy the .exe to anywhere else, Desktop, or any other directories created by other installers, the .exe will start perfectly.
This appears to be a folder or application permissions issue. Comparing the permissions between this folder and the one created by Advanced Installer, the permissions and settings are identical.
The ONLY difference I see, between the installed .exe and the same .exe copied to another folder, is that the "Edit Permissions" button has an admin shield on it (one originally installed by AI).
Is there a setting in Advanced Installer that will allow my .exe to run once installed, or is this just trickery employed by AI to get you to pay for a more robust version? I am unable to make any changes in the OS that enable this file to run in the directory created by AI.
If the executable fails to run from Program Files but does works from another folder it most probably happens that your EXE needs write access to that folder. If you launch it with the option "Run as administrator" it should work. This is not caused by a limitation from Advanced Installer.
Starting with Vista onward you can embed a manifest file into an executable file, that specifies for the OS the execution level, so you can set the level to "RequireAdministrator", thus your will EXE will always behave as you launch it with the option "Run as administrator" when launched from a shortcut or double-clicked.
The cause of this error was that the target directory included an exclamation mark. "!".
I had switched to using InnoInstaller and it was working in an initial version, until I later switched the target dir to include the exclamation mark, and it was broken in the same way. (Removing it fixed.)
Have no idea why this was causing the problem, just an fyi.
Recently I ran into trouble when I discovered that vista restricts what can be installed into the system32 directory even though I am the administrator for this computer. It will not allow me to register dll files so I can use programs like wget globally like how programs "nslookup" etc are used. Keeps giving me this error.
Regsvr32: The module "C:\Windows\System32\libeay32.dll" failed to load.
make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.
The specified module could not be found.
Moving the required DLL files to system32 prompts me to confirm administrator privileges are needed to move these files, So I give the permission, copy the files to system32, and run wget to confirm. This is where it tells me it cannot find the DLL's required to run and when using regsvr32 it says it cannot find the entry point so it will not load the DLL asking me if it is a valid DLL or OCX file.
If I leave the DLL's that came with wget in the same folder as wget outsite of system32 they work vice adding them to system32 with the exe it will not work saying it cannot read the those dll files.
Is there a way around this or Do I need to Upgrade to Windows 7 to get away from these problems/restrictions?
Try Dependency Walker on wget.exe and see it it gives you more info about the problem
Could it be a permission problem when you copy the file to system32? Make sure your user has read/execute rights to it
Put it (and wget.exe) in some other folder that also is in %path%. c:\windows (Ugly) or a custom folder like c:\tools that you add to the system variables.
Use a version of wget that does not depend on that dll
Note: regsvr32 is not required for dlls in system32, it only works when the dll exports the DllRegisterServer function