I'm creating a hotfix based on an installation file. When I run the hotfix, the first dialog box shows "Welcome to the hotfix for App version . Nothing in my hotfix project refers to this wrong number and I don't see a way to override the value it's putting there. The .msi file in the base image folder did have references to the wrong version number, but I changed them. The hotfix file is still showing the wrong version number. Any idea how I can override this or find where it's pulling this wrong version number from? Thanks!
Open Dialog editor in InstallShield (located under User Interface > Dialogs) and find InstallWelcome dialog. See what its text looks like; maybe there is some hardcoded version referred there. If there is no hardcoded version, see what property is being referred to in the text (e.g.[ProductVersion]), and make sure it's a correct property and it's set to the correct value.
Related
I have a question regarding Dependency Properties in WPF.
I am working on a project which uses controls from another package. I modified one of the controls by adding new dependency properties to it. However, when I try to access them in xaml that is in my project, I get error stating that there's no such property in my control. At the same time when I set the values of those properties in style for this control in a file that is located in the same package as the control, everything works. Also, the old dependency properties work fine.
I'm not sure what code to include to illustrate this, please give a hint.
Could anybody at least hint what is going on?
Thank you in advance.
The problem was that I didn't include in Build-Events of my first solution where the controls reside the path where to copy the respective dll so that the second solution could detect the changes.
I am currently trying to expand our installation program with an option for the user to specify the name of the program group where shortcuts are created under the start menu. (I am aware that this is a somewhat outdated concept)
I am using InstallShield 2015.
I created a localizable property named [PROGRAMGROUP_NAME]. This has automatically created an {ID_STRING46} which I've set to the desired default value. So far so good.
I managed to create a custom dialog with an edit control, which is linked to the above property.
Now comes the tricky part: Under Shortcuts, under "Programs Menu" I first want to add a folder with the program group name, under which to place several shortcuts.
If I enter [PROGRAMGROUP_NAME] that is literally what the name becomes. If I use {ID_STRING46}, it uses the default value, and not what I've entered in the dialog.
Incidentally, when I tried to rename ID_STRING46 to something more meaningful, other things started going wrong so I've left that as is.
What is going wrong here? How do I get the value of the property to be used for the folder name?
EDIT
I am trying to use a custom action now, but I have trouble defining it. My Dialog that sets the property is after CostFinalize, so I assume I have to use SetDirectory - but I have trouble defining it. I get an error stating "could not access network location "
EDIT
I've managed to progress a step. I have manually added a directory with key DIRECTORY_PROGRAM_GROUP (important that it's all caps to make it public) to the directory table. Then, I use a custom action to set that directory to the desired value [ProgramMenuFolder][PROGRAM_GROUP_NAME] after I've run my dialog, and I've modified the shortcut to be created in that folder.
Seems to work great, however, now the program group is no longer removed when uninstalling...
Shortcuts are installed to folders, and the name of the folders below ProgramMenuFolder become the program group as you describe it. So you will need to either build up the Directory table (either directly---note that the DefaultDir column is localizable, and there may already be a string you can update---or through the Files and Folders view) to do what you want, or use custom actions (set property, if before costing; set directory, if after costing) to adjust the location to which your shortcut is installed.
As for the problems renaming ID_STRING46, odds are you didn't update a reference after you changed the name of the string. The simplest way to track down where these are may be to examine differences in the built installer (perhaps using InstallShield's MSI Diff) and then update the relevant references using the direct editor if you can't find them in the normal views.
I tried to add a user-defined field to my setup created with NSIS. The documentation of 'VIAddVersionKey' states:
Adds a field in the Version Tab of the File Properties. This can either
be a field provided by the system or a user defined field.
But adding a simple test element like this:
VIAddVersionKey "test" "test"
Does not add anything new to the installer attributes, even if compiling the setup does not yield any warnings related to this. It seems that only the predefined fields are actually visible.
Unfortunately, I could not find any example configuration in the shipped NSIS examples, nor was I successful finding anything on the internet. This is why I am wondering, if I am missing something here?
So, what do I have to do, to actually get a user-defined field in an NSIS installer?
NSIS works as advertised, the field is successfully added to the version information block. You did not mention which version of Windows you are using but you might not see the field if you are using an inferior version. Windows 95..2003 displays all fields on the version tab, Vista and later switched to the shell property system as its source and only displays a few standard fields on the details tab.
VIProductVersion 1.0.0.0
VIAddVersionKey "test" "test"
will give you the following result:
You can inspect the version block by installing a shell extension or use a PE resource editor like Resource Hacker.
A typical "upgrade table" for InstallShield MSI installation cntains two records: "from any version to current is upgrade" and "from current to any is downgrade". This requires to manually copy-paste "current version" number every time a major, minor or build number has changed, that is not very good.
Currently i'm using a script that parses .ism project file and replace version number in upgrade table before build. But this is a dirty hack. Maybe it is possible to use "ProductVersion" MSI property in upgrade table, so product version is stored only in this property? I have tried to enter this property name multiple ways, like [ProductVersion] or ##ProductVersion##, but nothing helps - it is not being replaced by property value, and resulting MSI contains "##ProductVersion##" text instead of "1.30.1264" property value.
A new project should contain two records intended to behave like you describe. However instead of storing an actual product version, they should have a marker token, something like ***ALL_VERSIONS*** (sorry, I'm not near my copy of InstallShield right now). The name for this token isn't great, because what really happens is the current ProductVersion is substituted for it at build.
If you've already changed the token to an actual version, you can change it back with the "friendly" view by selecting a radio button referencing "my version" instead of the actual version. Or you can create a new project to see it, and copy it in. The token works in either the minimum or maximum field in all recent versions (but just in the maximum field in some older versions) of InstallShield.
So, I've got a native vc++ application that we currently have stored in TFS2010 (no SP), and we have finnally gotten to the point after the migration from TFS2005 to TFS2010 where we need to branch the code...
After branching the code, which now in TFS2010 does everything on the server and no longer leaves all of the files checked out on the client machine, and which also did NOT throw any errors of any sort... if we try to open the branch copy of the application we get an error:
"There appears to be a discrepancy between the solution's source control information about some project(s) and the information in the project's files(s). ... blah blah blah"
Now this error is being thrown because inside the project file (vcxproj) the SccProjectName value was not updated as part of the branching, so it is still pointing to full path of the trunk source location. Although when it throws this error it will prompt for a check-out and will update the value to the correct value... but it's will be annoying for it to happen every time we branch and there's no way to change it before it throws the error.
Online in various places the 'solution' (I use this term loosely because it doesn't work...) is to change the SccProjectName to "SAK" so that it will use the value in the mssccprj.scc hint file, however the TFS plugin doesn't use a mssccprj.scc hint file... so it will continue to throw the error...
So is there another solution to this issue? or does anybody know if the TFS2010 SP1 fixes this issue?
I had the exact same problem when moving code around in TFS 2010. Here is the solution that I found to work:
It is easier to do this by selecting the solution in Solution Explorer, going to File -> Source Control -> Change Source Control and then unbinding everything. Close the dialog, then re-open it and rebind everything. Save the changes and compare the VCXPROJ files now. The server path and the rest of the TFS info has been removed and replaced with SAK.
Source: http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/786d7d3e-5182-4452-b49b-3436de6f9c36/