The short of it is, I have VMs for building different scenarios of software. I do not wish to snapshot the code as it is backup elsewhere so I am storing all my code on the host PC and only building/testing in VMs to save space. Unfortunately I am receiving program database update errors when I try to build from a location mapped to the host hdd.
I know there is nothing wrong with the C++ projects as they build fine if moved inside the VM.
I have tried:
-cleaning/rebuilding
-removing the debug/release folders entirely
-checking out a copy of the source onto the host drive from within the VM
*Even when the idb and pdb files that the compiler complains about are created by VS, the problem persists.
How can I stop these C2471 errors when building from a non-local drive?
Perhaps, problem in the files that was created by compiler at previus build. Try to remove Debug (or Release) folder and build project again.
I'm not entirely sure as to why, but the issue seems to be related to using shared folders in VirtualBox. If the folders are referenced via a direct UNC path to the host machine it appears to work fine, but accessing through a shared folder (mapped or unmapped to a drive letter) doesn't appear to have the correct permissions.
Related
for a self-built installer I need a way to execute code after closing of an application itself.
Application structure
Main application: The installer is started from it when needed, it closes itself in the process.
Installer: This is also located in the folder of the main application and therefore also accesses all dll files. When an update is available, a zip file is first downloaded and then unpacked into the temp folder. Afterwards, all files are moved from there to the shared application directory.
The problem
The problem is that the updater can only update a few dll files at runtime that are not used by itself, because some are write-protected due to the installer's access.
A solution
Moving the files from the temp folder to the shared application folder must happen after closing the installer. But I don't know how to realize that.
Thanks a lot!
If your problem are the DLLs shared by the installer and main application, then you can do this: Before you run the installer, your main application can copy all the needed DLLs and the installer EXE from your main application folder to a temporary folder and run it from there. Your installer must then only wait until the main application gets closed and then replace all its files in the main folder. And once your update is finished, delete this temporary copy of the installer with its DLLs.
Note that if you want to overwrite files in Program Files folder, your installer will have to be run with elevated privileges. Google for "runas" command... you will need it when starting your installer with QProcess.
But there may be also other problems. If your first installation was with normal installer, it typically creates some entries in registry and also generates list of files for later uninstall. And if your new versions will contain different files than originally installed version, then your subsequent uninstall may malfunction or may leave some files existing on users' computers. And you certainly do not want this.
And yet another potential problem. You may have running several instances of your application. In that case quitting one instance will still leave the other instances running and hence their files will not be replacable by the installer - it will fail.
So as you can see, these are quire serious aspects to take into account.
How I do it in my software and I suggest you try it too? I prepare one installer file (.exe) with InnoSetup (freeware!). This can be used for first installation as well as for automatic updates. Then if I create a new version and put it on the server, the running main application detects it, downloads the new installer and runs this installer (of course it asks the user if it should proceed). The installer then asks for elevated privileges, asks to close the running application (it usually is closed automatically when starting the installer) and overwrites the existing installation. All this is standard functionality built in the installer created by InnoSetup. And correctly updates the uninstall instructions... It took me several days to set up everything to my needs but it works well. The only "drawback" is that it is not completely silent, it shows some dialogs. But this is no real issue for me. Maybe it is better for the users to see what is happening on their computer...
Your question implies Windows. I'll make a suggestion from a Win32 perspective.
In our application, we have a similar issue. Periodically, our application downloads an update executable into a temp folder and then launches it. When the update EXE runs, it makes sure the main application has exited, unpacks the files into the application's installation folder, and then starts the application back up again. It's actually more complicated than that, as it really copies the new files into a different install folder, but I'll save those details unless you really need it.
The problem is that the updater can only update a few dll files at runtime that are not used by itself, because some are write-protected due to the installer's access.
This is the core of your issue. My advice is to have the Installer EXE statically linked to both the VC runtime and the other code its sharing with the application. That is, no DLL dependencies all. If you really need to share code between the installer and the application, but still want the application to use a DLL, you can do this. Have the shared code built as both a DLL (with a stub lib) and also built as a full LIB. May require some minor refactoring to your build or redundantly build the same source files. The Installer code links with the full LIB. The application code links with the stub LIB for the DLL like it does now.
If you are just looking for a way to launch the process, the API you want is CreateProcess.
Also, have you looked at the open source options like Omaha - which is what Google Chrome has used for silent updates?
Moving the files from the temp folder to the shared application folder must happen after closing the installer. But I don't know how to realize that.
The "Windows way" would be to use PendingFileRenameOperations as described in this blog-post and have Windows do the move during the next startup. Of course that implies one more of the annoying "Please reboot to finish the installation" messages.
I am trying to create a WPF project for the first time using VS2017 v15.8.
I am getting the error message consistently, although there are times I have been able to get it to run. When I go to run it again though I receive the error message. I have read all of the proposed solutions and nothing has worked including the following:
Restart computer
Rebuild the solution/project. (tried deleting .exe file before doing this also)
Confirmed the Output path is correct
Kill the MSBuild process tree
I also tried different combinations.
Any help in finding a solution to this is greatly appreciated.
That typically happens to me, when i forget to stop my running program. As the executable is running, it is open and hence should not be overwritten.
I have been able to work around this. The issues I was having occurred when I was trying to save the project to a network drive or to the default location in my user profile on the local drive. I tried creating it again and saved it in a root folder on the local drive it worked.
Is there a way to change the location of the tmp directory ember-cli is using to process trees? (without using symlinks)
I am trying to develop an ember app using a linux VM on a windows host. Shared folders of any type (be it virtualbox shared folders, nfs or smb) are slow, don't allow symlinks and ember-cli produces a lot of files in the tmp directory. Being able to move this tmp to the native filesystem of the VM would help a lot.
This should be easily configurable, but i couldn't find any configuration option that would allow it.
No. Nobody answered and the help of the ember-cli build doesn't show that parameter.
How about creating a RAMDisk and hardlinking your project tmp folder to it? In Windows this can be done as follows:
Create RAM DISK with imdisk
mklink /j "C:\project\tmp\" "H:\ember-tmp" where C:\project is your local project folder and H: is your RAM Disk.
I'm afraid I don't know the Linux equivalents but it should be easy enough to find. Apparently this can roughly halve your build times with no chance of losing data.
Information sourced from https://emberjs-developer.quora.com/How-to-make-Ember-js-CLI-ember-s-32-times-faster and kudos to Stefan Penner for the suggestion.
Note the link folder MUST already exist before you run mklink otherwise you get the misleading message "Local volumes are required to complete the operation" and the link destination (junction folder) MUST NOT exist otherwise you get the message "Cannot create a file when that file already exists".
Note as of Ember 3.0 you can now change the cache by doing the below
BROCCOLI_PERSISTENT_FILTER_CACHE_ROOT=/path/to/my/other/tmp/
This will output the broccolli files to the path of your choosing. You will need to do the tidy up operation yourself on this custom path
More information here
https://github.com/stefanpenner/async-disk-cache/issues/35
I’m currently logged onto a machine and my current problem involves a custom build step that has trouble copying a .dll to the Bin directory because Windows says it cannot access the file because it’s currently being used by another process.
I’m able to reproduce this on several other projects. The sequence of events is that I build a release successfully, do some test, checkout another SHA when doing a git bisect, and attempt to build a release from that SHA without doing a git clean -xfd (intentionally, because I’m trying to cache as much reusable data as possible). The weird thing is that I tried to use Process Explorer (procexp) and tasklist /m <locked_dll.dll> to search for whatever is holding onto this dll, and am unable to find anything holding onto the dll. I’m on a non-admin account, and I’m not sure if that is causing Windows to hide certain processes from me. Rebooting the machine helps, but that’s not an acceptable solution since I’m trying to automate things. I’m able to delete the .dll, and when I try to build the project in VS, it’ll complain that it still can’t access the dll when trying to copy it over to the Bin folder. Any ideas? I’m going to keep researching the issue, but as of right now, I’m sort of stumped.
EDIT:
This seems to be a duplicate question (Error: Cannot access file bin/Debug/... because it is being used by another process), but I'll leave this open to see if anyone has found anything new related to the topic.
I've seen this problem in VS 2010 with a large .Net solution with multiple projects in it. Every case I've seen so far pertains to have one project with dependency DLLs that another project also uses, and that other project also uses the first project as a reference, and also uses the same dependency DLLs that happen to be a different version from the first project.
To describe it a different way:
Project A depends on v1 of DLL A
Project B depends on project A and v2 of DLL A
Both project A and B are in the same solution
The solution is to use the same version of DLL A. I usually run into this when upgrading to a new version of SQLite, and I forget to update the dependency in all of my projects.
After talking with a few coworkers, I found the solution to my problem. procexp and tasklist did not see which process was locking the dll because there was no process locking the dll on that particular machine.
I have a hardware configuration where machine A (a host PC) is connected to machine B (acts as a client that retrieves instructions from machine A) using a network switch. machine B runs the same binaries that link to the same dll's. Thus, obviously, running procexp or tasklist on machine A will not see anything locking the dll's because machine B is the culprit.
I'm creating an application that uses ImageMagick++ to load and convert a sequence of pngs into gifs.
Everything works on my dev machine (unless I uninstall ImageMagick++), but it crashes on other users machines when it tries to use the gif and png coders. I don't want end users to have to install ImageMagick in order to user the software.
It requires IM_MOD_RL_gif_.dll and IM_MOD_RL_png_.dll from the ImageMagick install directory: C:\Program Files (x86)\ImageMagick-6.8.9-Q16\modules\coders
It finds all the dlls and functions correctly when copied to the local directory except the coders.
Which don't work regardless of whether I copy them directly to the program directory. The following locations also failed (based off of advice I found elsewhere on the web).
applicationDir/
applicationDir/ImageMagick-6.8.9-Q16/modules/coders
applicationDir/bin/ImageMagick-6.8.9-Q16/modules/coders
applicationDir/modules/coders
Is there anyway to make an application using ImageMagick++ check the local directory for coder dll's without having to rebuild ImageMagick++ myself?
I'll respond here because I've seen a similar question unanswered elsewhere.
You just need to set the environment variable MAGICK_CODER_MODULE_PATH for the process using the coders.