I have a standard windows forms application that is being deployed using the VS2017 setup project. When opening the setup project using the "File System", I added to the application folder the following:
Primary output from the win forms app.
The EPPlus library's dll.
Some excel files.
The setup project gives the output .msi package just fine. The problem is, when I run the .msi output after building the setup project (of course after building the source project) and run the application, I do not see my updates, even the files on C:\Program Files .... directory are not modified. I tried changing the product code and the increasing the version and it does not work. My questions are:
Besides removing and installing the program again, is there anyway to make the installer package actually updating the software's installation?
How to avoid the problem in #1 no matter how much I update the software?
What is the cause and how to avoid this error "Another version of this product is already installed"? I'm not sure of what I did for it to pop up.
If I want some part of the source code to be in a separate dll, is it as simple as adding a class library project and adding its output to the setup project?
Thank you very much.
The way you do the upgrade is to use the RemovePreviousVersions project setting. The steps are:
Increment the setup project's version and accept the changes, this will include a change of ProductCode.
Make sure that RemovePreviousVersions is set true.
The UpgradeCode (setup project properties) needs to be the same so don't change it.
Increment the file versions of the binaries that need updating (that's the standard rule about updating versioned binaries).
The resulting MSI will do a major upgrade (in Windows Installer terminology) and upgrade the older version, replacing it with your new product MSI. Note that an upgrade will work only with the same context of install. An Everyone will not upgrade a Just me, so that will result in two entries in Programs and Features. Doing the install creating a verbose log and searching foe FindRelatedProducts entries will tell you if it found the upgrade or not. msiexec /I [path to msi file] /l*vx [path to a text log file]
There's a longer explanation here:
https://www.red-gate.com/simple-talk/dotnet/visual-studio/updates-to-setup-projects/?_ga=2.138201520.1662048302.1514485579-1682631157.1514485579
which is old but relevant. and doesn't mention the requirement to update binary file versions (it wasn't needed with early VS setup projects).
Related
I have many Qt projects in Visual Studio, using the new Qt/MsBuild format provided by the Qt VS Tools. When compiling in my development environment, where I have the Qt VS Tools installed, everything works flawlessly (compiling from IDE and from command line).
We have a computer dedicated to nightly builds, where only the compiler and msbuild are available (no IDE nor Qt VS Tools are installed).
When compiling the projects in such computer we get an error:
QtMsBuild: could not locate qt.targets, qt.props; project may not build correctly.
Followed by several lines such as
e:********\Preferences.h(4): fatal error C1083: Cannot open include file: 'ui_Preferences.h': No such file or directory
(Project contains Preferences.ui).
How can I solve such errors when Qt VS Tools are not installed?
One solution provided by the Tools' creators is to copy %LOCALAPPDATA%\QtMsBuild into each project directory. But we are talking about hundred of projects. Doing manually, and more on, pushing them as part of the project itself doesn't sound very elegant.
One option would be to add a pre-build step that copies it from a common place into each project (and adding a **/QtMsBuild line to each .gitignore file). Again, looks like too much work.
When looking at the .vcxproj file for the Qt project you find this fragment (the reason for the solution provided by creators):
<PropertyGroup Condition="'$(QtMsBuild)'=='' or !Exists('$(QtMsBuild)\qt.targets')">
<QtMsBuild>$(MSBuildProjectDirectory)\QtMsBuild</QtMsBuild>
</PropertyGroup>
So, the simplest solution (without being able to install the tools), is to copy the %LOCALAPPDATA\QtMsBuild directory (from a system with the Tools installed) into the night computer (in any common place, but I decided to keep the location used by the tools) and then setting an environment variable:
set QtMsBuild=%LOCALAPPDATA%\QtMsBuild
PS: do not add double quotes to the variable (at least I had problems with them, so VS couldn't find the files).
Update 9-14-2020
I'm not sure on which version it started, but Qt projects created with (at least) the v2.5.2 Qt VS Tools fails to compile indicating that the Qt version has not been set. To solve so, you can
Copy the Registry entries from a computer with tools installed, located at HKCU\SOFTWARE\Digia\Versions.
If you will rely on a single Qt version (but that may be update globally for all projects), you can skip the Registry and just set the Qt version of all projects to $(DefaultQtVersion) (the same used in past project formats) and define an environment variable pointing to the directory of the version: set DefaultQtVersion=c:\Qt\Qt_5_15_0\Win32, for example.
I had problems in my case setting up $Env:QtToolsPath="$Env:QT_PATH\bin" fixed the problem. (It was not finding qmake for some checks). This, I think, is required when using QtMsBuild v3.3
Not sure if this info is 100% correct but may help someone.
For me to use MsBuild with Qt using QtMsBuild (not installing Visual Studio and/or VS plugins), I need to set up:
Example (PowerShell):
- $Env:PATH="$Env:MSBUILD_PATH;$Env:PATH"
- $Env:QT_PATH="D:\BuildTools\Qt\5.15.1\msvc2019_64"
- $Env:QtMsBuild="D:\BuildTools\Qt\QtMsBuild303" #303 Against visual studio project version
- $Env:QtToolsPath="$Env:QT_PATH\bin" #Support QtMSBuild , At desktop is done by the plug in
- $Env:PATH="$Env:QtMsBuild;$Env:PATH"
- $Env:PATH="$Env:QT_PATH\bin;$Env:PATH"
I hit this and got it working.
I followed #cbuchart 's advice; but needed to do a little more/different.
So here is what I did. I copied %LOCALAPPDATA%\QtMsBuild to my repo. I then edited my .vcxproj with a text editor. I adjusted the line that looks like:
<QtMsBuild Condition="'$(QtMsBuild)'=='' OR !Exists('$(QtMsBuild)\qt.targets')">$(MSBuildProjectDirectory)\QtMsBuild</QtMsBuild>
To be:
<QtMsBuild Condition="'$(QtMsBuild)'=='' OR !Exists('$(QtMsBuild)\qt.targets')">$(MSBuildProjectDirectory)\..\QtMsBuild</QtMsBuild>
Depending on the relative location of where your project(s) are to the copied QtMsBuild directory you might want to adjust this. In my case the .vcxproj was in a directory one level from the directory that contains the QtMsBuild directory I copied.
Next in the QtMsBuild/Qt.props file I added the following:
<PropertyGroup>
<DefaultQtVersion>$(MSBuildThisFileDirectory)\..\Qt5.15.0\msvc2019_64</DefaultQtVersion>
<QtToolsPath>$(DefaultQtVersion)\bin</QtToolsPath>
</PropertyGroup>
That was added right after the opening Project tag in that file.
This was as #cbuchart mentioned something might have changed. I didn't do the Registry idea; but added those lines instead. I think it is possible to add them to a different file that gets imported before Qt.props if desired.
Now as for what this "Qt5.15.0\msvc2019_64" is; you'll need the tools, includes, libraries from a computer with Qt installed in order to build (also DLLs if your build needs to run the executable (i.e. tests)). This might be a lot of files so you can reduce it some if you know what you are doing. It might make sense to have these be put into it's own submodule or something.
After that it should uic/moc files and ultimately build (and run).
I got too. Maybe you need update your visual studio and then restart your computer ...
problem solved. reason: install 'qt vs tools' latest version but the visual studio
not support of it.
I was making a 2048 game on Code::Blocks, but due to debugging problems, I move to Visual Studio Community 2017. It seems that conio.h doesn't work there, so I'm trying to switch to curses.h library.
I've read a lot of tutorials, but none of them worked for me. I visited their website and downloaded the .zip file with 384 kilobytes (KB), but I do not know what to do with these files.
Help, please?
I have found a very useful website which talks about PDCurses and its installation in Visual Studio. Even though it is for 2010/2013, it really worked for me in VS2017 — even the demo programs (with very minute changes)!
So here is the steps I did (since you already have PDCurses):
Take the developer command prompt of VS2017 community edition and type
in set PDCURSES_SRCDIR=<PDCurses Directory Location>; in my case it
was
set PDCURSES_SRCDIR=C:\pdcurses-master
Note: Here we are setting up the environment variable needed for compilation. If you need additional functionality defined by the pdcurses library, you may want to set corresponding variables in this step. For example, if you need wide character support, you can use set WIDE=1. To see what all are the options available, you can open up the make file (mentioned in next step) in any text editor and look for if conditionals.
Navigate in the command window to the directory of PDCurses/win32 (in my case C:\pdcurses-master\win32)
nmake –f vcwin32.mak
(This is the make file for PDCurses.) It will create the pdcurses.lib for our Visual Studio.
Now we need to incorporate the generated library into our project. So open up your project and go to project properties
In “VC++ Directories”, change:
Include directories: Add a new file-path to PDCurses installation directory, in my case it is C:\pdcurses-master.
Library directories: Add a new file-path to PDCurses installation library directory, in my case it is C:\pdcurses-master\win32.
In C/C++:
In “Code Generation” tab, change “Runtime Library” to “Multithreaded Debug (/MTd)”. (Usually, it is set already)
In Linker:
In “Input” tab, add pdcurses.lib to Additional Dependencies (I initially got confused - remember, it is the input tab of linker)
Click on Apply, and OK.
Then wow! I ran some sample programs (demos) from the pdcurses project and all of them worked for me with very slight modifications.
Note: I created a Windows (also known as Win32, as in Win32 API) console application with Visual Studio 2017 and loaded the project. I did include stdafx.h and compilation was successful and I was able to see the output in the terminal window.
The above website also provides a PDF document too. The instruction there starts from the downloading the pdcurses from website.
This is old news now, but it might help somebody to know that pdcurses is packaged up on vcpkg.
To use it, (assuming you have vcpkg installed, of course, (Installing vcpkg) )
vcpkg install pdcurses
and you're off to the races. vcpkg will take care of making sure the include and library paths are all set.
I'm trying to use curl from within my windows c++ app but keep running into problems.
I'm using visual studio 2013 on a windows 8.1 machine.
Here's what I've done so far:
Cloned the repo from github
Built the libcurl project which produced three files: libcurl.dll, libcurl_imp.lib and libcurl_imp.exp
In my app project I added the curl include directory to the Additional Include Directories
Added the libcurl_imp.lib to the Additional Dependencies
Built my project
When I run my executable it says:
the program can't start because libcurl.dll is missing from your computer
I found a few things on it, but they solved it by adding the libcurl dll along with the exe, which isn't what I'm looking for as I want my executable to contain the libcurl so that it will work on machines without the need to have the dll.
Any ideas?
Thanks.
Edit
The 2nd step is done pretty much straight forward, I just right clicked on the project (libcurl) and chose buiild.
Due to the comments I've rebuilt it after changing the Configuration Type to Static library, so now it only produces one file: libcurl.dll which, as far as I know not a static library...
2nd edit
I wasted too much time on getting http functionality, and based on the info which I found thanks to a comment here (using libcurl without dll) I've decided to abandon this approach, and I found something which suits my needs perfectly and is simple to install/use: C++ REST SDK (codename "Casablanca")
Try to add libcurl.dll directory to PATH environment variable.
I have just installed Qt_SDK_Win_offline_v1_1_4_en.exe and run QT Creator.
I am working on Win7 64 bit.
I wanted to make simply app with form and button on it to test Qt. I choose New->Project QT Widget->Aplikacja Gui QT ---> then Desktop application.
When I run Play Button - that should build and run the application I get a message: that I should check path and privileges. I can't also run the exe files as administrator manually because windows give me message that I don't have privileges. I gave full privileges in file Properties but then after run I am getting error that I don't have mingwm10.dll.
I gave full privileges in file Properties but then after run I am getting error that I don't have mingwm10.dll.
This means the library required can't be found in any of the locations Windows searches to find libraries. The usual method to get around this is by making sure the folder containing the copy of mingwm10.dll which the Qt SDK installs is in your PATH environment variable. Here is one of the many Google-able guides to settings those variables.
Ok, I found a partial solution, I could finally run the exe file.
First, something must have changed in my Windows7 because every new created folder (and files in it)had restrictions and noone could make all operations.
So, after changing properties of folder, I got message about missing dlls files, so I started to copy them from QT folder. There are at least a few different versions of each dll, and only one is correct, so I copy those form mingw folder bacause I used mingw compiler, and finally after copying 4-5 dll I run the exe file.
But this is not what I am expecting from app that install pack has almost 2GB...
thanks
m.
I was trying to figure out why a debug build was blowing up with the "dependent assembly microsoft.vc80.debugcrt could not be found" event error.
After deleting everything (anything not .cpp or .h) and recreating the solution - I still had the problem.
A google search was fruitless and a re-install of VS didn't produce any change.
I did have the dlls in C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c.
I opened the \debug\.exe.intermediate.manifest file and it had 2 (dependentAssembly) entries:
1st: name='Microsoft.VC80.DebugCRT' version='8.0.50608.0'
2nd: name='Microsoft.VC80.DebugCRT' version='8.0.50727.762'
If I delete one and change the other one to
name='Microsoft.VC80.DebugCRT' version='8.0.50727.42'
I can get a build that will start.
Granted I did have VS2008 installed - but what is controlling the versions ? or How can I get the right debug dll version to "stick".
VS2008 was de-installed through the control panel.
EDIT: Found nothing in the registry if DebugCRT is searched for.
the environment path points to the VS8 folders .
There is only 1 DebugCRT folder in the c:\windows\winsxs\policies folder
(8.0.50.727.42)
The c:\windows\winsxs\manifests folder only has the .42 version of .cat and .manifest
The .manifest file (in above manifest folder) has version="8.0.50727.42"
Clarification: the manifest file has 2 "dependentAssembly" entries each with different versions and not the .42. I can delete 1 entry and change the version on the other to match the .42 to get a debug build that starts.
EDIT2:I'm also using boost and inside the DLLs there is the .762 version
The version was picked up by from the Boost DLLs which were a download, pre-compiled version of Boost. Once the libraries were re-compiled (and re-installed) a re-build of the solution produced a manifest with a single version and the program linked and ran.
So -Check the libs and dlls that are imported into the solution for version used.
VS 2008 is VC90 not VC80, so that's not part of the problem. The relation between manifest-requested assembly and SxS-loaded assenbly is found in C:\WINDOWS\WinSxS\Policies. IIRC, "8.0.50608.0" is generated by VS2005 pre-SP1. It's wrong, and should have been 8.0.50727.42, but this is caught by the policy.
I'm not sure how you're getting two manifests. What are your manifest settings?
I'd suggest rebuilding Boost in your particular environment. Also, you could do away with the Side by Side assemblies altogether by linking the CRT statically...