When my NSIS installer runs it creates these random files in the same directory that the installer is in.
The files have no extension type(not .txt, etc.) and have a random number as a name like 526310.
Has anyone else experienced this issue? I have debugged my installer(which is rather complex) and found it occurs when I write to files(not copy/extract files but write). It still could be my installer code doing it but I have debugged for hours and cant find a cause within my own code.
Any ideas what could cause this and how to fix it?
Related
I have a fairly large application (~750k LOC) that I distribute using the Package and Deployment Wizard. I fully understand that it would be nice to migrate to .NET (that ain't happening - see the code size above), and that the PDW is deeply flawed. However, for the most part I've made it work well for my end users, by customizing the Setup1 application, writing a menu-driven wrapper for the Setup application, and by running it in silent mode. (Note that the problem I'm about to describe occurred even before I started using silent mode.)
The issue I'm having is that my application requires quite a few auxiliary files, which I've added to the PDW project in the "Included files" section. When a user does a clean installation (either from scratch, or after un-installing a previous installation), everything works fine. However, if they simply run the installer to update the existing installation, the executable file and any OCXs I've updated get copied over the previous versions just fine, but my auxiliary files don't - I have to have the user manually delete them, and then the Setup1 program will re-install them as it should.
I've checked in the Setup.lst file, and all of the files are listed there, with their current date stamps. In fact, in my "BuildAll.bat" file, I do the Windows equivalent of a "touch" (copy /b "TheFile.dat" +,,) to force the date stamp to be current. However, if the file exists on the target machine, it won't be over-written even though it's older. There are no errors reported, either visibly or in the .LOG file (which is required if using the silent option).
A couple of additional points: Some of the auxiliary files are themselves VB6 applications - just the .exe files. Those do get copied correctly if they're newer than the existing files. Other than being files with internal versioning information, there's no difference between them and the other auxiliary files (which are things like media files, or text-based .txt or .dat files).
So, what's going on, and how do I fix it (besides moving to Inno or some other solution that won't work for me...)? Thanks in advance for any help!
~~
Mark Moulding
Our software project uses Inno Setup to roll it out to the customers. We found on some target computers it takes a long time for some DLLs to be copied to the system32 directory (about 2 minutes per file). The first intention was this files are hardly monitored by the virus scanner. But it has nothing to do with the certain files itself. If I change the order of the DLLs to be copied - always the first 3 files takes this long time. Because of this behaviour it's out of question that the virus scanner finds something peculiar within the files.
I found another strange thing: In the PrepareToInstall function the installer executes vcredist_x86_vc++_2013.exe. If I exchange the file to another executable file that is packed within the installation the problem persists. But if I disable the execution of the pre-requisite installation file later all DLLs are copied within a fraction of a second.
Summarised: If I copy a prerequisite file (doesn't matter what) later on the first 3 or 4 copied DLLs needing a very long time to be copied.
Does somebody here find an similar problem or knows a way to solve this. Any help is welcome.
Other information:
Its the same for both Win7 or Win10
The user owns local administrative rights
Running the solution without problems in Visual studio 2017, or directly through .exe file in solution folder (inside release and debug folders). But when the ".exe" file is not in the solution folder, it will crash and stop working.
I found that these lines are causing the issue:
ScreenReaderAPIWrapper.ScreenReader sc = new ScreenReaderAPIWrapper.ScreenReader();
sc.SayString(textDisplay.Text.ToString());
The ScreenReaderAPIWrapper library for .net you're using is a wrapper around another library called UniversalSpeech. There are several solutions alike out there, like Davy Kager's Tolk or Chris Toth's AccessibleOutput. All of these libraries make use of native APIs provided by corresponding screen reader modules (jfwapi.dll, saapi32.dll, NvdaController32.dll and others).
For these libraries to work, you have to provide all of the needed DLLs along with your executable, otherwise you'll get those errors about the exe file that stopped working.
If you need to distribute your program, consider using installer tools like NSIS or InnoSetup to pack all needed files into one single installer.
So I have been trying to build an installer for my game with NSIS. For the most part it works fine but just noticed that it seems to be skipping certain files for no reason. Or no reason I can figure out.
At first I was using this line to gather up all the files in the source folder:
File /r "${NSISDIR}\game\source\*.*"
However, I noticed that this didn't get everything. Granted it found all sub-folders and kept the hierarchy correct. There didn't seem to be any rhyme or reason to what it skipped. Then I tried listing all files and directories separately and found out why. Example:
File "${NSISDIR}\OWTD-DE\source\pygame.math.pyd"
This produces the following error:
File: "C:\Program Files (x86)\NSIS\game\source\pygame.math.pyd" -> no files found.
But that file exists, I can see it in the source folder. This was the case for all missing files. At first I thought it may be the two periods in the name, but various files have that naming convention and they are added fine. I cannot figure out how to get it to recognize these files. Any ideas?
${NSISDIR} is a define used to access the UI resources in the Contrib subfolder, you are not supposed to put your files there. Your source files should not be in Program Files, only installed files should be located there. Also, on 64-bit systems there are two Program Files folders and there are some compatibility hacks in Windows related to %ProgramFiles% so putting your source files there is not optimal. Just because you see that file there does not mean it is actually in Program Files, it could be UAC Virtualization/VirtualStore tricking you...
Normally you would keep your .nsi somewhere in the same directory tree as the rest of your files so you can use relative paths but you can also use a define if you really want to:
!define MYSOURCE "c:\foo\bar"
...
Section
File /r "${MYSOURCE}\*.*"
SectionEnd
If it still misses some files I would suggest trying Process Monitor so you can see the low-level details...
Weirdly enough, this process did not work very well on Windows Home 64-Bit but did on Windows Professional 64-Bit. I'm not sure if this an issue with NSIS itself or what, but nothing was different between the two except the OS. And there really isn't much difference between those two operating systems. However, perhaps some configuration differences between the two was the real issue.
While marked solved, I'm not really sure what the actual issue and solution could be.
I have an old program that saves its files to Program Files. We are updating it to run properly on Windows 7. The problem is that we now can't find our saved files. Windows 7 allowed our program to save to program files, but obviously put the files somewhere else. We can't find that 'somewhere else'. Does anybody know where Windows 7 places its files when we save in Program Files?
Update:
We've looked in program files, in program files (x86), we've used Windows Explorer search function to try and find the directory name. Nothing works, but when we check to see if the directory we are making already exists in our application, we find it and put up our error dialog box.
Look in C:\Users\[USERNAME]\AppData\Local\VirtualStore\Program Files\[APPNAME]
Possibly program files (86) if your application is a 32 bit app. The place they should be saved is in the users directory though (or even better, give the user the choice of where to save).