Hey Phil,
We cover the XML format pretty extensively in the "Building from Commandline" help article.
If you're not building from commandline then this article will tell you how to modify registry: Registry changes.
Tell me if this helps.
We are using wyBuild, wyUpdate, & AutomaticUpdater, and they are working fine so far.
However, on updating a release, the version does not change in the control panel (registry).
I see that wyBuild has the plage where registry keys and values can be created or removed.
I also see a few questions on this in the forum, and one response says to use xml format (AddVersion).
Can you explain what the xml format (AddVersion) is? I don't see anything about that in wyBuild, or elsewhere in the forum.
We need to be able to update the version in control panel, i.e. the registry. The registry location may vary depending on factors such as the user installed initial MSI for everyone/user, the OS version, 32 vs 64 bit, etc.
thanks,
Phil Evans
Hey Phil,
We cover the XML format pretty extensively in the "Building from Commandline" help article.
If you're not building from commandline then this article will tell you how to modify registry: Registry changes.
Tell me if this helps.
Hi Wyatt, thanks for your response.
I see the information on your web site (http://wyday.com/wybuild/help/commandline.php) for wybuild.cmd.exe.
Looks like wybuild.cmd.exe is a nice command line utility that allows for doing most everything that you can do in wyBuild, such as creating/updating the wyp project file, adding files, building client.wyc, building the server update wys and wyu files, etc.
Since we're doing well with wyBuild, we would prefer to use that over a command line utility.
What we need to do is find the best way to update the registry entry which is used in Control Panel for the version of our application after an update using wyUpdate/AutomaticUpdater. For instance, if our application is updated via wyUpdate/AutomaticUpdater from version 2.0 to 2.1, it currently still shows as 2.0 in the version column in Control Panel.
That's a problem not only in showing the misleading incorrect version in Control Panel, but since we also provide MSI files for users to download and install (in addition to providing updating via wyUpdate/AutomaticUpdater within our application), if the user installs an earlier version MSI, Windows will allow it, since it thinks the earlier version is installed.
I see the information on your web site (http://wyday.com/wybuild/help/registry.php) to do with the registry. However, it looks like in wyBuild you can only add and remove registry entries, not update registry value names, which is what we need to do. I don't think we can remove and then add a new registry entry, because that would require knowing guid value data ahead of time (see below).
In searching the registry I see the following entry for our application, that I believe is an entry used in Control Panel for the registry, although this may vary depending on OS and 32 vs. 64 bit:
Base KeyHKEY_LOCAL_MACHINE
Sub KeySOFTWARE\Classes\Installer\Assemblies\C:|Program Files (x86)|OurFolder|OurApplication.exe
Value NameOurApplication,Version="2.0.0.0",Culture="neutral",ProcessorArchitecture="MSIL"
Value TypeREG_MULTI_SZ
Value dataB&[E'A6ZUA4]bfvDqJar>DN8!FOi@ZUTE{XCtTy&`
So using the %version% and %basedir% variables, it appears for the registry subkey:
SOFTWARE\Classes\Installer\Assemblies\%basedir%|OurApplication.exe
we need to update the Value Name to:
OurApplication,Version="%version% ",Culture="neutral",ProcessorArchitecture="MSIL"
In summary: How can we update a registry entry using wyBuild? Do the above registry entries look correct? Do we need to make registry changes differently based on the OS and 32 bit vs. 64 bit?
However, it looks like in wyBuild you can only add and remove registry entries, not update registry value names, which is what we need to do. I don't think we can remove and then add a new registry entry, because that would require knowing guid value data ahead of time (see below).
No, you can update registry changes. "Create value" is the same as "Update value".
SOFTWARE\Classes\Installer\Assemblies\%basedir%|OurApplication.exe
Is the subkey really variable? Because wyUpdate doesn't support "run time" variables like %basedir% in the subkey field -- only in the value data field.
Do we need to make registry changes differently based on the OS and 32 bit vs. 64 bit?
By default wyUpdate always uses the "main nodes" of the registry. Not the Wow64 node. To use the Wow64 on 64-bit then check that checkbox.
Thank for your reply Wyatt.
I should also have mentioned that the first install for a user is from an MSI file, and then subsequent updates are either via wyUpdate within our application, or they many choose to download a new MSI. We also have to provide MSPs for corporate users for the sys admin to update via group policy.... but getting back to the registry changes for the version that shows in Control Panel (and is important to disallow users from installing an MSI with an older version) that we hoped we could do in wyUpdate:
You said:No, you can update registry changes. "Create value" is the same as "Update value".Our response:It would appear that I need to change the Value Name, not the Value Data. In looking at the registry entry that would need to be updated for the version to change in Control Panel I see: Base Key: HKEY_LOCAL_MACHINE Sub Key: SOFTWARE\Classes\Installer\Assemblies\C:|Program Files (x86)|OurFolder|OurApplication.exe Value Name: OurApplication,Version="2.0.0.0",Culture="neutral",ProcessorArchitecture="MSIL" Value Type: REG_MULTI_SZ Value data: B&[E'A6ZUA4]bfvDqJar>DN8!FOi@ZUTE{XCtTy&`I would want to update Version="2.0.0.0" to Version="2.1.0.0" in the Value Name above when updating to version 2.1.0.0 for instance.
You said:Is the subkey really variable? Because wyUpdate doesn't support "run time" variables like %basedir% in the subkey field -- only in the value data field.Our response:The sub key above is variable, since the user could have installed in C:\Program Files (x86), or another folder if they prefer.
In summary:So it looks like the registry update capabilities of wyUpdate will not work for us to be able the registry for the new version. We are exploring writing code which could be run after wyUpdate finishes which would make the change to the registry.
So it looks like the registry update capabilities of wyUpdate will not work for us to be able the registry for the new version. We are exploring writing code which could be run after wyUpdate finishes which would make the change to the registry.
That's unfortunately how you'll have to do it -- we haven't solved this type of problem yet. You can just use a simple batch file to update the registry.
Hi Sam,
Thanks for your response. We added some code to update the registry that seems to work OK:
/// <summary> /// UpdateOurApplicationRegistry - Update Our Application Registry /// </summary> public static bool UpdateOurApplicationRegistry() { bool bStatus = false;
try { // uninstall Wow6432Node bStatus = UpdateOurApplicationRegistryKey("SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall");
// uninstall bStatus = UpdateOurApplicationRegistryKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall");
return bStatus;
} catch (Exception ex) { string strError = ex.Message; return false; }
}
/// <summary> /// UpdateOurApplicationRegistry - Update Our Application Registry /// </summary> public static bool UpdateOurApplicationRegistryKey(string strKey) { int i, j = 0;
RegistryKey rk = null; RegistryKey sk1 = null; RegistryKey sk2 = null;
string[] strSubKeys = null; string[] strValueNames = null;
string[] strValues = null;
string[] separatorComma = { "," }; string[] separatorEqual = { "=" };
string strSubkey = ""; string strValueName = "";
string strValueVersion = ""; string strCurrentVersion = "";
string strValue = "";
bool bFound = false;
try { // get base registry key rk = Registry.LocalMachine;
// open installer subkey sk1 = rk.OpenSubKey(strKey);
// get the key that has: // Value Name == DisplayName && Value data == Our Application // Value Name == DisplayVersion strSubKeys = sk1.GetSubKeyNames(); for (i = 0; i < strSubKeys.Length; i++) { strSubkey = strSubKeys; sk2 = sk1.OpenSubKey(strSubkey,true); strValueNames = sk2.GetValueNames(); // Value Name == DisplayName && Value data == Our Application bFound = false; for (j = 0; j < strValueNames.Length; j++) { strValueName = strValueNames[j].ToUpper(); if (strValueName == "DISPLAYNAME") { // get value strValue = (string)sk2.GetValue(strValueName); if (strValue.ToUpper() == "OUR APPLICATION") { bFound = true; break; } } } // DisplayName && Our Application not found, continue to next key if (bFound == false) continue; // Value Name == DisplayVersion bFound = false; for (j = 0; j < strValueNames.Length; j++) { strValueName = strValueNames[j].ToUpper(); if (strValueName.ToUpper() == "DISPLAYVERSION") { bFound = true; break; } } // DisplayVersion continue to next key if (bFound == false) continue; // get value strValueVersion = (string)sk2.GetValue(strValueName); // get current version strCurrentVersion = Assembly.GetEntryAssembly().GetName().Version.Major.ToString() + "." + Assembly.GetEntryAssembly().GetName().Version.Minor.ToString() + "." + Assembly.GetEntryAssembly().GetName().Version.Build.ToString(); // done if current version already if (strValueVersion == strCurrentVersion) return true; // set value sk2.SetValue(strValueName, strCurrentVersion, RegistryValueKind.String); // exit method return true; } return true; } catch (Exception ex) { string strError = ex.Message; return false; } }