Due to the administrative privilege of the application, I need to install my program including .exe and .dll in C:\DestFolder\SubFolder\ but I keep getting C:\Program Files\\[Manufacturer]\\[Product Name]\ where the placeholders are specified in the properties window.
I tried this article but no good.
Please don't give me answer like try changing the defaultlocation to C:\Destination\ of the Application Folder as I have already tried. Also I don't want solution like just change the installation destination path manually during the installation.
I have found the answer from this article:
"[ProgramFilesFolder] is built in, and correctly leads to the Program Files directory on the target machine, no matter how customized the setup of Window is..."
There might be tools out there that allow installing outside of Program Files.
[Edit] Infact I've found out this great extension for VS 2017 community called Wix. There's a guy who did a fabulous tutorial on it.
Related
I am using Visual Studio 2019 on Windows 10 and am trying to use GTK in C++ and installed it using vcpkg.
I've installed GTK using vcpkg according to the guide from GTK. I'm using Visual Studio 2019 and it is able to compile and run the example program here, but there is an issue regarding the theme and icons. According to the installation guide, under the section Building and distributing your application there are some things that must be done to get themes and icons to work.
I've started by downloading the Windows theme the guide suggests and have it in a share directory and then I've created a settings.ini file in an etc directory. It says to place this in the "install directory", which I assume is where Visual Studio is placing the exe for the program. I've tried it in both build and release, in the source files, in the top project directory - all with no success (and I did make sure it is targeting x64).
Just in case I also tried placing these where vcpkg is installed as well as where vcpkg installs gtk. No luck. When the program runs I get the warning
(gtkExample0.exe:16772): Gtk-WARNING **: Could not find the icon 'window-minimize-symbolic-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases
So it seems that it is never finding the ssettings.ini file telling it to use the Windows 10 theme. Has anyone had any luck with getting this to work (both from VS2019 debugging runs and in deployment)?
To summarize the files:
share\themes\Windows10\gtk-3.0\gtk-3.20\ (downloaded from suggested GitHub repo)
etc\settings.ini contains:
[Settings]
gtk-theme-name=Windows10
gtk-font-name=Segoe UI 9
I've placed these in
<VS2019Project>\x64\Release,
<VS2019Project>\x64\Debug,
C:<path_to_vcpkg>\vcpkg\packages\gtk_x64-windows,
C:<path_to_vcpkg>\vcpkg\installed\x64-windows
All with no change when running from VS2019 under Release or Debug.
Theme and icons considered as external resources are not distributed by vcpkg, and the instructions given in the distribution guide from GTK regarding where these resources should be layout on windows 10 are not crystal clear. The problem has also been reported here vcpkg issue#4417.
The solution proposed hereunder is to install
all the resources in the <VS2019Project>\x64\Release directory of your VS project where your .exe application lives [This is a local solution the problem. A global approach should consider the setting of some user-defined free desktop environment variables which is not discussed here]. Icons can be picked from an ancillary MSYS2 distribution and the theme as indicated in the GTK Guide. The solution should be replicated for the Debug branch.
Supposing you have MSYS2, install mingw-w64-x86_64-adwaita-icon-theme package with the pacman package manager if not already done on your MSYS2 installation pacman -Syu mingw-w64-x86_64-adwaita-icon-theme.
Copy C:\msys64\mingw64\share\icons to <VS2019Project>\x64\Release\share\icons
you should get both hicolor and Adwaita icons as subdirectories of your target dir.
Copy the theme resources downloaded in the source gtk-3.20 directory directly into <VS2019Project>\x64\Release\share\themes\Windows10\gtk-3.0\. Do not locate these resources into a gtk-3.20 subfolder: to understand why consult this article Theme Location [assuming here that no global desktop environment variable has been set].
Create a <VS2019Project>\x64\Release\etc\gtk-3.0 directory, put your settings.ini into it.
Recompile and you should obtain a windows 10 look and feel for your application window.
I'm new to Qt, but have been working with Visual studio for C/C++ development for a few years. Now I'm trying to build a GUI for my project. I installed Qt 5.11.0 and the Qt VS Tools on both my work computer and home PC. At work I can build and run my project with the VS debugger, however on my home system I can build but can't run either with VS debugger or simply launching the app. I tried in release and it runs fine.
The error I'm getting is :
The code execution cannot proceed because VCRUNTIME140D_APP.dll was not found.
I get 4 of these, the first two want VCRUNTIME, the second two want MSVCP140D_APP.dll.
Solutions I've tried so far :
Uninstalled Win SDK and reinstalled
Uninstalled VS2017 and SDK and reinstalled
Searched System32, SysWOW64 and VS install directories - found msvcp140d.dll and vcruntime140d.dll, but no _app.dlls
Does anyone know what these are included with and where to get them? I can't figure out why I have them on my work computer but not at home. I have the same VS updates, same Qt version, and SDK on both systems.
Using :
Visual Studio 2017 v15.7.1
Qt 5.11.0 - msvc2017_64
I suppose I can just copy the .dll's from my work pc and drop them in the appropriate locations on the other, but I'd like to know what they should have been installed with so I can have the same setup on both systems.
Edit:
I also tried changing the platform toolset to VS2015 with Qt versions msvc2015_64 and winrt_x64_msvc2015
I found this post concerning the same missing _app.dll files. There wasn't any answer there, which is why I tried reinstalling the SDK in the hope the missing files were included there.
Edit 2:
I just scanned my entire system at work and it turns out that I don't have the missing .dll there either. That tells me that there is a difference in the project properties or configuration between the two. I use git for source control, and I am currently the only contributor to this project. When I try to build and run just the example from the getting started guide I have the same problem at home with missing _app.dll files, however it works fine at work. I'm totally confused now, and any hints are greatly appreciated.
Solution:
After trying for a couple of hours making new solutions etc. I decided to delete the entire build folder and put fresh copies of all the dependencies into it. My project now runs fine in debugging mode.
I'm fairly certain that when I originally copied the Qt .dll files into it I must have grabbed them from one of the winrt folders rather than the msvc2017_64 folder. To test I replaced the working .dll files with those from the winrt_x64_msvc2017 folder and sure enough the same errors again. So, this was a dumb mistake on my part, but hopefully it'll save someone else a lot of hair-pulling in the future.
I have been able to successfully install a simple program using an Installer Project on Visual Studio Community 2017. However, I can't find out how to create a fully working deployable uninstaller for an end user.
The Installer Project was set up to only create an Application Folder (in C:\Program Files...) with the Program .exe, and nothing else. This it does successfully. I would like an installer because later I plan to make some registry keys upon installation.
To test uninstallation, I have run the original .exe file built by the Installer Project with the "Uninstall" option. This removes the Application Folder but does not remove the program from the Add/remove programs list in Windows - Leading me to believe there are other registry entries that have not been removed.
I have tried to uninstall purely from the Add/remove programs list, but then I get an error:
C:\WINDOWS\system32\msiexec.exe
"Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."
In Visual Studio, I can click "Uninstall" from the Installer Project right-click menu which does successfully remove both the Application Folder and the Add/Remove Programs Item, but this is not a deployable solution.
Notes:
OS: Windows 10
Using Visual Studio 2017 Community
Looking at the application Folder, there is neither an install nor uninstall .exe file in it. The Installer Project .exe is only in the original build location, and I cannot find how to get a copy in the Application Folder (not sure if a copy there would work).
I have tried configuring the Installer Project as x86 and x64 with no change.
I have tried using both Debug and Release build configurations with no change.
From looking around, WiX seems to have more features and flexibility, but I haven't yet dug into that. Is there an easier solution?
Has this issue occurred to anyone else? My hopes were that Installer Projects were the simple way to learn and handle installation.
Looks like I jumped to conclusions in the comment above, however I think I found the issue: I cannot uninstall the program from the Windows Apps & Features window in System Settings, but uninstalling from Control Panel\Programs\Programs and Features works fine.
When typing in "Remove" using the windows start button, the default item that comes up is "Add or Remove Programs" in System settings (This looks like a Windows 10 thing). When you click that, it forwards you to the "Apps & features window. I am now learning that for some reason this has different functionality than the control panel window. Or maybe it has lower permissions, although I am the admin and only user of this computer...
Because it can be uninstalled from Control Panel, I think this would be the preferred solution. My assumptions about the other window in system settings was my real issue. I just wish the Apps & features window aligned its functionality/permissions with control panel.
I also learned that uninstall is successful when I run msiexec.ex /I{PACKAGEID} in cmd. Not sure how relevant this is, but documenting here.
Installs and uninstalls are transactional, they either work completely or roll back completely. If you do an uninstall but the entry remains in Add/Remove Programs then it's likely that the uninstall did not in fact work.
When you do the install, if it has a UAC elevation dialog then the install is running with elevation and installing files/registry entries to locations prohibited to limited users. Removing files from those locations also requires elevation. You haven't said exactly how your uninstall works, but most likely it requires elevation to succeed, and your program isn't running elevated. If your program uninstalls silently the uninstall will fail silently, so it's possible that your program isn't actually checking that the uninstall worked.
I'd also guess that your Visual Studio session may be running elevated so uninstall from there works fine.
Apart from privileges, an uninstall from a running installed program tends not to work very well because the uninstall process cannot remove your running program or its folder because it's in use. So while you could get it to work (with elevation) you might find that your program and its folder are left behind until the next reboot. If people really want to do this, one of the strategies is to copy an uninstall program to the temp folder and fire it off asynchronously, so everything can be removed.
Uninstalls from Add/Remove Programs&Features generally work fine. Without some context that error message doesn't mean much. It's not a message that comes out of Windows Installer, so it's perhaps coming out of a custom action. Otherwise it may be an issue specific to the test machine.
There is never an uninstall exe in a Windows Installer setup. When you remove a product the system just calls the Windows API to remove the product. Windows Installer is part of the Windows OS with API support for everything that needs doing. Only non-MSI setups require an install and uninstall exe to do anything.
None of these issues seem to be related to your choice of tool. They all create MSI files and if an MSI design is not optimal it doesn't matter what tool you use. There's nothing wrong with WiX, but to install literally a few files it's overkill compared to Visual Studio.
i spent a lot of time trying to get these to install properly, so here i am.
I've already googled my problem countless times in different forms and still can't resolve it.
It's just very confusing because there are so many versions out there, and i don't even know how to build the binaries, if even have to do that, and i couldn't find the configure.exe. I don't have it after i installed QT5.
I have python, perl, Visual Studio, QT5,QT addin, and openssl installed.
When going to QT5, QT Options, then Add, add: C:\Qt\5.2.1\mingw48_32 as the path and got an error about qmake not found or something.
So I deleted libqtmain.a and libqtmaind.a as suggested by some site and that solved the problem.
I've also tried this: http://blog.kikicode.com/2011/09/qt-version-uses-unsupported-makefile.html
but i couldn't find the Trolltech folder, so i stopped.
But now my problem is this
"This QT version uses an unsupported makefile generator (used: MINGW, supported: MSVN.NET, MSBUILD).
I don't even have a configure.exe file, and can't launch it from the visual studio command line.
I really have no idea what to do. I've been attacking this problem for all of yesterday, and i've ran out of steps today. Please help me.
I don't have the express version of VS. Just so you know.
I just solved this issue. It get me mad, but is easy.
The Add-in looks to $(QTDIR)\mkspecs\default to know which one to use. The "default" folder is not created after configure and build Qt.
So the way I solved is to copy&paste the "win32-msvc2013" folder as "default".
And now the Add-in recognised Qt.
BTW, after build the sources "nmake", I make an install of them in another folder so I have just the binaries and tools but not all the source that I don't need for develop software based on Qt.
Once the compilation is complete, then type:
Set the root where the installation will be, ex:
set INSTALL_ROOT=\Sw\Qt\qt-4.8.5-install
Execute in your source's root the command:
nmake install
So after trying everything i decided to run compile the binaries.
I think not a lot of people have this problem and there is no solution on the internet because the 2013 addin is very new. So here is what i did, and what worked for me, after countless hours of trying.
I downloaded the zip located under the main downloads on their webpage: http://qt-project.org/downloads
I uninstalled the old QT. (kept the addin)
I unzipped the zip it into a folder i named QT at C:\
Then i ran the configure.bat located inside.
On the Visual Studio cmd i cd to the C:\QT\qt-everywhere-opensource-src-5.2.1
directory where the configure file is,
Tried running the 'configure' file, there was no configure.exe. Then i ran 'nmake', that took like three hours.
The i went into C:\QT\qt-everywhere-opensource-src-5.2.1\qtbase\qmake
and made a folder bin where i copied the qmake.exe found in that same folder.
Finally i went into the VS addin, qt, qt options and i added that directory.
And it works!
I'm using Qt 5.6, msvc2014, but had the same issue at first. This issue was solved for me by updating to Add-in 1.2.5 without changing anything else.
[edit] Sorry, I out thought myself. I was using a .bat file to set environment variables that wasn't set up properly. When I went to a straight VS2005 command prompt, the configure ran fine. Sorry for the noise.[/edit]
I'm trying to compile qt-everywhere-opensource for embedded. I'm using MSVC2005. However, I guess I am confused on the process. I am getting compiler errors during the configure step. I thought the configure step was just trying to generate the needed makefiles, so I'm not sure what it is trying to compile.
I expected to modify the mkspec, but I'm not sure if during configure I should point to windows headers or sdk headers. I know during the build phase I should point to sdk headers, but I'm not getting that far.
I can change the errors by modifying INCPATH, there's also a QMAKE_INCDIR that seems to have an effect. It occurred to me that since I pulled the source, maybe configure needs to build the compiler tools, in which case I should point to MSVC headers. I also tried downloading the SDK and adding the path to it's bin folder to my path ahead of the -everywhere- source, but that didn't fix the problem and I don't want to jack up my system too much testing things.
Hope someone out there can help!
When you install Qt from source under Win32, you must:
Extend the PATH variable to include $(QTDIR)\bin, where $(QTDIR) is the directory where you installed Qt.
Open a Visual Studio command prompt in $(QTDIR); a plain old Windows command prompt won't do (unless you run vcvars.bat to load Visual Studio's environment variables; but opening a Visual Studio command prompt directly is better).
At this point, configure should run properly, after which you can run nmake.
I suggest that you clear your previous installation attempts from your system before you try these steps.