I am having this warning:
ISDEV : warning -6487: If you intend to distribute this upgrade as a patch, you should author the 'Patch Optimization' setting on the Advanced Settings panel of the Release Wizard
while creating the setup with Installshield. Does anyone know what does it mean and explain the options?
In the configuration wizard, I could not find where I indicate "this is a patch". Actually it is not a patch and it should be standard exe file. Is this warning says I am doing something wrong?
This warning is telling you that you might be doing something wrong. If you are building your second version and you intend to distribute it as a minor upgrade or especially as a patch, then consider taking the warning's advice.
Patches are created by having built two .msi files, and then using the Patch Design view to turn their changes into a .msp file. Certain things, such as dynamic file links, increase the chances that the two .msi files will be subtly incompatible; the "Patch Optimization" setting helps decrease the chance of such incompatibilities by giving InstallShield access to the layout of the previous .msi file. Since InstallShield cannot predict whether you will later build a patch, it warns while building the main .msi file.
Related
I may not have the option to simply update to a more recent VC++ version as would be ideal - the project is big and the update could break a lot of things, plus my lead may tell me not to pursue this. I'm wondering if anybody knows of a means by which an MFC app written using VC++08 can check resolution during runtime?
Thank you, #IInspectable for providing the answer I needed. A full update is not needed. DPI awareness can be activated via the app's manifest file. The link they provided was invaluable. Should anybody else have this issue and is using vs2008, if you cannot find the manifest file in the same dir as your exe after building, chances are, vs2008 has embedded the manifest in the exe. You can change this by opening the project's properties, going to manifest tool->IO. If you want to keep the manifest embedded, you can put your additional manifest info in a separate manifest file and provide the tool with the path of this file. The manifest tool will merge your manifest files.
I'm quite new in the InstallShield stuff, I took this project from a leaving co-worker. However, here's my problem:
I was trying to update a MySQL Server with the setup from 5.7.17 to 5.7.19, which works great most of the times.
I got the feature "MySQL", splitted in "MySQL Data" (includes the performance_schema and mysql database), "MySQL Service" (Service batch files) and "MySQL Binaries" (the files).
For the update, I just changed the binaries by the new one and left the rest. All features are selected and my log tells me, that it installs all files which it hasn't installed by now, leaving the existing files untouched. As this is an update, it seems correct to me.
But sometimes, at the end of the setup process, it uninstalls almost anything of my MySQL Feature again; the databases, the batch files and almost any core file which wasn't changed by the setup before. But why is that and how can I stop my setup from do so?
Kind regards
I think what you're describing is that your file containing the data is not getting updated. Since this type of file cannot be versioned, that's what Windows installer uses to determine whether or not to upgrade the file, you will need to mark the component containing this file to Always Overwrite. Check out the MS docs for the Component table for how to do this with the Attributes field.
You may want to check the conditions on the components in question. Also, check the install sequence to see if it is calling uninstall out of sequence.
We have a Libraries folder where we keep third-party DLLs and our own utility DLLs for all applications to reference. I want to do development against one of our utility DLLs and an application that consumes it at the same time. But if I check out the library DLL to change it for temporary local use, TFS insists on checking it out exclusively, which trips other people up. I understand the reasoning behind it doing that (hard/impossible to merge a DLL, so two people shouldn't be working on one at the same time), but I just want to mess with my local copy while I'm working on the library it represents.
I suppose I could delete my application's reference to the DLL and recreate the reference pointing to some other place, but of course this just begs for me to forget and check it in like that, which would obviously be bad. Not to mention that this is a pain in the neck.
How should I proceed in such a situation?
You are using a server workspace that does not allow editing outwith TFS. In TFS 2012 local workspaces were introduced which do not have a read only flag for files and you are free to edit at will.
You can change your existing workspace in a few clicks: http://msdn.microsoft.com/en-us/library/bb892960.aspx
You could just go into the file system and mark the file as writeable. Once you are happy the binary is good you could check it out, copy the new version of the file over and check it back in again. TFS marks binary files like this as locked for good reason, as you can't merge them in the way you can with textual content.
The best approach would be to use a NuGet repository to manage your binary dependencies, instead of relying on binaries checked into source control.
I have a home machine and office machine I use to publish websites using Visual Studio 2013. If I make a change from the same machine, and re-publish, just the changes are published, not all files.
However, when using my clone machine at the office, even if I do a get latest, make one small change, and re-publish, all files are published, not just the ones that changed, and not just the ones that have been recompiled. ALL dll files, even third party dlls that have not changed or have been recompiled with a new date, are republished. Same thing happens if my cohort publishes a small change on his machine after I did the last publish. Not a problem if publishing twice from the same machine as then only the changed files are published.
Is there anyway to prevent complete republishing just because a different machine is used to publish than the one used for the last publish? Thanks.
This seems to make "Determining Changes" a lot slower, but for .Net 4.5 [and
up(?)], use this info from:
https://msdn.microsoft.com/en-us/library/ee942158:
To configure Web Deploy to use checksums instead of dates to determine
which files need to be copied to the server, add the following element
to the .pubxml file (Publish Settings):
<MSDeployUseChecksum>true</MSDeployUseChecksum>
Like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MSDeployUseChecksum>true</MSDeployUseChecksum>
<!— other settings omitted to keep the example short -->
<PublishDatabaseSettings>
<!— this section omitted to keep the example short -->
</PublishDatabaseSettings>
</PropertyGroup>
</Project>
First of all, I do not understand the behavior of MSBuild+VS2013 and the publishing feature completely as I just started to use the publishing feature myself. I'm looking for a way to speed up publishing via FTP web deploy in VS2013. (I'm not using TFS for a get latest though.)
I would say this is partially explained in a different context at this SO question. The MSBuild process. Timestamps of certain files are being compared and then could indicate MSBuild/VS2013 whether a target (build output) is up-to-date or not. Then files that are not up-to-date are being recompiled.
As you all work on different machines, timestamps are likely to be different quite soon.
To find out what is actually going on during builds/publishes, set build output verbosity to detailed or diagnostic, for a moment:
VS2013 menu - Tools - Options... - Project and solutions - Build and run - output verbosity - set to -> detailed or diagnostic. Run the build, and see the Output panel/tab in VS2013. Select "show output from: Build" to see results if not already visible. Don't forget to set it to the original setting after checking the build details, as it could slow the build down a bit.
But why even unchanged third party dll's are being republished? Possibly because these dll's ARE actually overwritten during a build. You might have the assembly reference property "Copy local" set to true to get your website running without any manual uploads to be done for this. Or you are using a commandline copy command with the overwrite parameter explicitly set to true during project's post build event (like 'copy /y ...' or 'xcopy /y ...'). Then the timestamp of the file that is to be published is overwritten for sure, see in
the "obj\Release\Package\PackageTmp" folder (or for example: "\Debug" instead of "\Release" if Debug build is set for the selected publish profile.)
Furthermore, VS2013 as default does NOT check timestamp differences on the targeted webserver if you are using FTP publishing, at least that is my experience. As for the other publishing options like a web deploy I don't know yet. But the differences you experience seem normal behavior to me, as you run builds on different machines and publishing files from different machines as well. So timestamps are likely to be different... which, again, indicates 'changed' files to be published.
As I'm curious how this question should be solved, I was looking for this in the first place:
Maybe a TFS build server is an option for you, configured with a rolling build. But I read on a specific SO (sorry, can't add more links at this moment as I've just registered) that is suggesting to do clean builds to prevent new problems. And that will force full publishing again as files are all being changed by the clean build... so that won't work I think.
As an answer, you might want to use these FAQ answers on MSDN for web deployments. See the questions:
"Can I exclude specific files or folders from deployment?" .NET 4.0/4.5 and/or
"How to make Web Deploy use file checksums instead of dates to
determine which files were changed?" .NET 4.5 only!
The first option is to exclude files.
The second option is to use a checksum to compare files instead of timestamps, but that could be somewhat slowing the build(?) process, as the FAQ says. Note the first few lines on that FAQ pages, on how you can edit your publishing profile to apply one or both of these elements!
Also it is an option to put the thirdparty dll's in a different project which you then could only include that project in the deploy for a certain solution configuration (VS2013 menu - Build - Configuration Manager, see the checkboxes in the 'deploy' column there for every project. Though I'm not sure if this is part of the VS2013 'publish' feature as a web deployment, because this deploy column checkboxes are greyed out for my solution projects for some reason I don't understand yet... so I can't test it to verify this option.)
Though it sounds logic, don't forget to create backups/copies/screenshots first before you change any settings or publishing profiles, and then change the same settings/configurable files on the other machines you and your colleagues work at.
I am using Installshield 2010. I made a basic MSI setup, and I am having a problem with uninstalling.
Uninstalling does not remove all folders.
After a complete install, I then uninstall only to find that there is still a path leftover.
For example, C:\ProgramFiles\CompanyName\Account\User_1234.xml
still remains, while everything else is gone.
The User_1234.xml file is generated by the application, and this file is not normally in the install process. So it makes sense why this file may have some problems getting rid of it (installer side).
At the same time, I would think that it would be removed due to the fact that it is within the CompanyName folder.
Is there any way to specify to get rid of everything inside and including the CompanyName folder?
Thanks for any ideas.
You have a couple problems and I'll address the obvious one first. Yes, Windows Installer default behavior is to not delete user data. This could be files not installed by the installer or files that were modified since the installer modified them. To get the installer to remove them, you must author the RemoveFiles table to teach it which files to remove.
Remove Files Table (Windows Installer)
Now I'll address the less obvious problem. You shouldn't expect your application to be able to write to ProgramFiles at runtime. I don't know what your software does but you should seriously consider this aspect of your application design.