PDA

View Full Version : Reading Install Path From Registry


Staggan
04-20-2006, 10:10 AM
Hi.

I am trying to test Visual Patch with our current project. I have two problems...

1. It does not seem to read the install path correctly from the registry and keeps telling me the software is not installed...

My Registry key is set as;

HKEY_LOCAL_MACHINE\software\companyname\product

Subkey is Install_Dir

And I have checked the registry key and it does show the correct path to the application


2. We do not have a single file that always changes for patches, since we may update only some assets and not the executable, so, should we also add a versioning document that always changes between builds, and use that as the key ?

Any help would be greatly appreciated.

Staggan
04-22-2006, 09:30 AM
I am still looking for help with this... I tried logging a support issue, but could not do that, as it said that there were already topics to cover this...

I am able to read the registry keys with several other patching tools... but unlike Visual Patch, they are unable to update those keys once the patch is installed...

Do I have to look for another solution, especially as time is a big consideration in getting this working...

csd214
04-23-2006, 05:27 AM
1. It does not seem to read the install path correctly from the registry and keeps telling me the software is not installed...

My experiences with VP2.0 is limited (only one single real project) but I know the LUA engine in the IR products very well. If you can’t read the install path correctly from the registry, you certainly have done some mistakes. You don’t give any details about your code and consequently it is difficult to give any advice.

The wizard gives you three options for ‘Locate Installed Version’. One of them is ‘Registry key’ which gives you a code snippet starting with
-- Location method: Registry key
-- Read a folder path from the Registry.



2. We do not have a single file that always changes for patches, since we may update only some assets and not the executable, so, should we also add a versioning document that always changes between builds, and use that as the key ?

From the help doc:
“A version can contain as many key files as you like; however, only one key file must be unique between versions.”

Perform a search for “key file” in this forum and you’ll find several posts; this is one of them: http://www.indigorose.com/forums/showthread.php?t=11491

HTH

Staggan
04-23-2006, 01:06 PM
Thanks for the reply.

I use the registry key to locate the previous install, and the registry keys are definitely correct. I use the wizard to look at the registry key for the install path, and it returns something completely wrong, normal 1.1 and then writes this to the registry, even though I am not writing anything to the registry from that patch...

Secondly, I have tried using a single file, actually called version.txt to identify the original and the new version, and this also does not work.

This is the code used to locate the key...

if not g_InstalledVersion then
local MainKey = HKEY_LOCAL_MACHINE;
local SubKey = SessionVar.Expand("Software\\Staggan_Interactive\\Product");
local ValueName = "Install_Dir";
local FolderPath = Registry.GetValue(MainKey, SubKey, ValueName);
g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", FolderPath);
if g_InstalledVersion then
SessionVar.Set("%AppFolder%", FolderPath);
end
end

And the value set in the registry for Install_Dir is definitely the path for the current version of the software. The above is run as part of the startup script.

Any ideas ?

csd214
04-24-2006, 01:34 AM
I use the wizard to look at the registry key for the install path, and it returns something completely wrong, normal 1.1 and then writes this to the registry, even though I am not writing anything to the registry from that patch...

>> it returns something completely wrong
What is the returned value in g_InstalledVersion? Use the Debug function or add a MsgBox or use the log like this:

g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", FolderPath);
if g_InstalledVersion then
VisualPatch.WriteToLogFile("*AppCtr*\t".."g_InstalledVersion has string value: "..g_InstalledVersion.."\r\n"); -- test log
SessionVar.Set("%AppFolder%", FolderPath);
else
VisualPatch.WriteToLogFile("*AppCtr*\t".."g_InstalledVersion has nil value: ".."\r\n"); -- test log
end

(I love to use the log feature in Setup Factory.)

>> and then writes this to the registry
It’s hard to believe that the app modifies the registry without a write action. Personally I have this code as an ‘On Post Patch’ action:
--[[ Update Registry ]]
Registry.SetValue(HKEY_LOCAL_MACHINE, "Software\\MyCompany\\MyProduct", "EXEVer", SessionVar.Expand("%TargetVersion%"), REG_SZ);

Look through your code; be aware, TJ_Tigger has published a great AMS app you can use with your VP2.0 projects, too. All your project code is gathered into one single text file, you can transfer it to your favourite editor, print it, save it, search it. Don’t miss to download IR Project CodeViewer.exe. :yes :yes :yes
Ref: http://www.indigorose.com/forums/showpost.php?p=64613

Lorne
04-24-2006, 02:22 PM
If your application doesn't have any good candidates for key files, and you don't want/need to use key files to verify which version is installed, you could modify the script to ignore them completely.

Basically, you'd set any file as a key file in each version (just to get around the key file checks at build time), and then modify the script to not use the CheckFolderVersion action at all. Instead, make it read the version directly from the registry, and go from there.

TJS
04-24-2006, 02:35 PM
Hmmm... I knew that this could be done in TU but assumed that the key file checks we required in VP... this is good to know.

Staggan
04-25-2006, 04:56 AM
I am able to use a key file actually.. we have added a version file for the application.

The problem still appears to be the registry key reading. I tried the script addition suggested, but no file was written out.

I have tried another patching / installer and this works fine, it reads the registry and creates no problems. However, it does not have a few of the features of Visual Patch that I want...

I have used the wizard to look for the previous path in the registry, so unless I am missing something major, this should all work...


This is the generated script for the registry read..

-- Location method: Registry key
-- Read a folder path from the Registry.
if not g_InstalledVersion then
local MainKey = HKEY_LOCAL_MACHINE;
local SubKey = SessionVar.Expand("Software\\Staggan_Interactive\\ProductName");
local ValueName = "Install_Dir";
local FolderPath = Registry.GetValue(MainKey, SubKey, ValueName);
g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", FolderPath);
if g_InstalledVersion then
SessionVar.Set("%AppFolder%", FolderPath);
end
end



ProductName is the name of our project, changed to protect the innocent.

Is something missing ?

Any help would be greatly appreciated

Lorne
04-25-2006, 10:58 AM
I have tried another patching / installer and this works fine, it reads the registry and creates no problems. However, it does not have a few of the features of Visual Patch that I want...Visual Patch has absolutely no problems reading from the Registry...the same actions are used in TrueUpdate and Setup Factory and they have been thoroughly tested over many years of use. Reading and writing from the Registry are considered critical features in our products and even the tiniest changes undergo extensive testing.

This is the generated script for the registry read..

-- Location method: Registry key
-- Read a folder path from the Registry.
if not g_InstalledVersion then
local MainKey = HKEY_LOCAL_MACHINE;
local SubKey = SessionVar.Expand("Software\\Staggan_Interactive\\ ProductName");
local ValueName = "Install_Dir";
local FolderPath = Registry.GetValue(MainKey, SubKey, ValueName);
g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", FolderPath);
if g_InstalledVersion then
SessionVar.Set("%AppFolder%", FolderPath);
end
end

ProductName is the name of our project, changed to protect the innocent.
Few things:

It looks like you have a space before ProductName above...is that space in your script, or was it just a typo when you edited out the real product name?
Does that exact registry key exist on the system you're testing on? Software\Staggan_Interactive\ProductName\Install_D ir
What is the value of Install_Dir in the Registry?
Double-check your paths and names in the script and in the Registry...because of how quickly the human brain recognizes patterns, it can actually be pretty hard to spot a typo. :)
Is g_InstalledVersion being set earlier in the script? The default script checks the current folder first, so if you're running the patch in a folder where a copy of the key file(s) exists, it might be setting g_InstalledVersion earlier and never going into this script block that looks in the Registry. Try adding a message box to determine this (see below).

Here's a modified version of that script block that will pop up some messages to show you what's happening:

-- Location method: Registry key
-- Read a folder path from the Registry.
if not g_InstalledVersion then
Dialog.Message("", "Checking Registry");
local MainKey = HKEY_LOCAL_MACHINE;
local SubKey = SessionVar.Expand("Software\\Staggan_Interactive\\ ProductName");
local ValueName = "Install_Dir";
local FolderPath = Registry.GetValue(MainKey, SubKey, ValueName);
Dialog.Message("", "Registry Key: \""..SubKey.."\\"..ValueName.."\"\r\nValue Returned: \""..FolderPath.."\"");
g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", FolderPath);
if g_InstalledVersion then
Dialog.Message("", "Installed Version Found: "..g_InstalledVersion);
SessionVar.Set("%AppFolder%", FolderPath);
end
end

Any help would be greatly appreciatedIt's a bit tough to determine what's wrong without seeing the rest of your script and what's in your Registry at that location. But if you use the modified script block above, it should give you some clues.

Staggan
04-26-2006, 12:13 PM
Thanks for the suggestions...

The space before product name is a typo... and as for the registry key it contains the path to the installation directory, this has been checked and all the keys used work for another patching tool... so the keys are fine.

The patch is run from the My Patches folder, and I don't use anything for locating the current version other than the registry. So it should not be the case that it is finding a version before that part of the script...

I'll try the amended script you sent and see what I get.

Thanks

Staggan
04-26-2006, 12:24 PM
Hi..

Your amended script was very useful. It is indeed finding the correct path from the registry, but is still telling me the software was not found...

I have double checked that the key file for both version is indeed different, and it is...

What else can I try ?

Thanks

Lorne
04-26-2006, 12:39 PM
What version does it report finding? (If it doesn't put up that third message box, it'll be the CheckFolderVersion that is failing. Which means there's something about the located files that doesn't match with any of the version tabs...)

Staggan
04-26-2006, 12:54 PM
Hi..

It doesn't give a version at all.. just says software not found...

Staggan
04-26-2006, 01:06 PM
Just to add.. I even changed the main executable in both versions and also made them key files... the effect is the same... still Software Not Found.

Staggan
04-26-2006, 01:09 PM
To add a little more, I know the versions are identical apart from the two key files as one is a copy of the other....

Lorne
04-26-2006, 02:01 PM
What is the destination path set to for those key files in Visual Patch?

It needs to match the folder path that was returned from the Registry in order for the CheckFolderVersion action to work. (See the docs for CheckFolderVersion in the help file for more info.)

Staggan
05-02-2006, 06:09 AM
Hi..

I am now able to produce a patch that locates the correct install folder. However, now I am getting a message saying that I have the latest version already...

I use a file called version.txt to differentiate bewteen builds. If I use that file, I get an error saying cannot locate software, and if I use another file, I get an error saying the latest version of the software is installed....

I am sure I am missing something, but not sure what...

Lorne
05-02-2006, 10:40 AM
Hi..

I am now able to produce a patch that locates the correct install folder. However, now I am getting a message saying that I have the latest version already...That means that either the key file in that folder matches the one in your most recent version (the version tab that is farthest to the right), or more specifically that the value in g_InstalledVersion matches the name of the rightmost tab in the project.

I use a file called version.txt to differentiate bewteen builds. If I use that file, I get an error saying cannot locate software, and if I use another file, I get an error saying the latest version of the software is installed....

I am sure I am missing something, but not sure what...

Here is the relavent part of the script:

-- Decide which "Before Patching" screen to show.
if g_InstalledVersion then
if g_InstalledVersion == VisualPatch.GetTargetVersion() then
-- The target version was found
Screen.SetStartScreen("Software is Current");
else
-- An out-of-date version was found
Screen.SetStartScreen("Ready to Patch");
end
else
-- No version was found
Screen.SetStartScreen("Cannot Locate Software");
end

What is the value of g_InstalledVersion when it reaches this part of the script?

Staggan
05-02-2006, 12:07 PM
If I use the version.txt file as the key, it tells me it cannot find the software...

If I don't use it, and use the executable instead, it tells me that I am using the most recent version (2) of the software.. even though version 1 is installed and the version.txt files are definitely different...

The only difference between the two versions is currently the version.txt file, I did this to test functionality....

Lorne
05-02-2006, 12:59 PM
To add a little more, I know the versions are identical apart from the two key files as one is a copy of the other....Are you saying that all the files in your two versions are identical, except for the two key files?

If all the files are identical between version 1 and 2 unless you include those key files (because they're the only files that are different, you said), there's nothing to do between the two versions. So of course VP will say it found the latest version of your software if - instead of using the key files - you use your copied .exe's which are exactly the same.

To put it another way: Visual Patch looks to see if you have the latest version, and everything matches up exactly between what you put on the version 2 tab (your "latest version") and what it sees in the folder. Job done - the installed files are up to date.

As for why it doesn't find the version when you use the key files...are you sure youre version 1 version.txt key file is in the folder? Are you sure it's exactly the same as the version.txt file on the version 1 tab in your project? (Even an extra carriage return will make the files different.) Use the Tools > Calculate MD5 feature in Visual Patch to compare the MD5 signatures.

Try this code block to see whether CheckFolderVersion is failing:

-- Location method: Registry key
-- Read a folder path from the Registry.
if not g_InstalledVersion then
Dialog.Message("", "Checking Registry");
local MainKey = HKEY_LOCAL_MACHINE;
local SubKey = SessionVar.Expand("Software\\Staggan_Interactive\\ ProductName");
local ValueName = "Install_Dir";
local FolderPath = Registry.GetValue(MainKey, SubKey, ValueName);
Dialog.Message("", "Registry Key: \""..SubKey.."\\"..ValueName.."\"\r\nValue Returned: \""..FolderPath.."\"");
g_InstalledVersion = VisualPatch.CheckFolderVersion("%AppFolder%", FolderPath);
local err = Application.GetLastError();
if(err > 0) then
Dialog.Message("CheckFolderVersion Error",err..": ".._tblErrorMessages[err]);
end
if g_InstalledVersion then
Dialog.Message("", "Installed Version Found: "..g_InstalledVersion);
SessionVar.Set("%AppFolder%", FolderPath);
else
Dialog.Message("","Key files in folder do not match any version");
end
end

Staggan
05-03-2006, 05:41 AM
Hi..

Sorry, I did not explain it well..

I have two identical versions of my software, one is a copy of the other.

I use the EXE file as the key file to identify the version.

I have 1 file that is different between the two and this is the version.txt file.

When I run the patch, I am told that the software does not exist.

I have run the MD5 tool and the MD5 number of both exe's is identical.


When I run the patch with your extra logging, I am told that the installed version does not match either patch versions.

Lorne
05-03-2006, 09:46 AM
I have two identical versions of my software, one is a copy of the other.Okay. Why are you needing to update from one to the other, if they're both exactly the same? If there really is not one byte that is different between the two, then you don't have two "versions," you have two "copies."

Which begs the question, what are you trying to accomplish with a patch?

I use the EXE file as the key file to identify the version.

I have 1 file that is different between the two and this is the version.txt file.If that's the only file that is different, then it should be your key file.

At least one key file in each version needs to be unique to that version. The whole point of the key file is to allow Visual Patch to verify that it has found one specific version, exactly.

Since the whole point of patching is to go from one version to another different version, this is normally easy to accomplish, and a really good idea.

I have run the MD5 tool and the MD5 number of both exe's is identical.I meant to use it on both version.txt files since I thought you were using them as key files.

When I run the patch with your extra logging, I am told that the installed version does not match either patch versions.

You should read through Chapter 1 in the user's guide (Help > User's Guide), which explains Visual Patch's version detection methods, what key files are, and how to choose them.

Staggan
05-03-2006, 10:52 AM
Ok, I got it working, but it makes no sense.

I am simply testing this tool, if it works, then we will use it, that is why I am using simply a copy with a single file changed.


Your documentation says I need to use a single file, or multiple files, that are different between versions as a key file.

So, for simplicity and ease of use I have two versions of my software, where only 1 file is changed.. version.txt

Remember, this is a test, not a full working example.

Each version of version.txt has its own MD5 signature, but for some reason if I use this file as a key file in BOTH versions, I get the error that "Key files do not match any version"

If I now change it, so that version 1 uses the main executable as the key file, and version 2 uses the version.txt file, everything works fine. Does that mean for every version I have to choose a different key file ?

Lorne
05-03-2006, 11:10 AM
Ok, I got it working, but it makes no sense.

I am simply testing this tool, if it works, then we will use it, that is why I am using simply a copy with a single file changed.You would probably find this a lot easier if you had two versions of your software to test with. For the purposes of testing, though, all you need is one or more files that are different between the two versions.

Your documentation says I need to use a single file, or multiple files, that are different between versions as a key file.

So, for simplicity and ease of use I have two versions of my software, where only 1 file is changed.. version.txtThat's perfect. Just select version.txt as the key file in both versions.

For starters, this assumes you have 2 folders with all your files, one for each version. Consider these your "source images" that will be used to create the patch. The only difference between the two folders is the data contained in the version.txt file.

For example, create version.txt in version 1 with this text in it:

"This is version 1"

Then create version.txt in version 2 with this text in it:

"This is version 2"

Select version.txt as the key file in both versions. You can select others if you want, but you don't need to.

At least one of the files needs to be unique to that version -- Visual Patch needs to be able to tell that version from the others based on the key files.

Remember, this is a test, not a full working example.

Each version of version.txt has its own MD5 signature, but for some reason if I use this file as a key file in BOTH versions, I get the error that "Key files do not match any version"Okay. Now check the MD5 signatures of those version.txt files against the one in your target folder -- the one you're trying to update. For the purpose of your test, it should match the version 1 version.txt file.

If I now change it, so that version 1 uses the main executable as the key file, and version 2 uses the version.txt file, everything works fine. Does that mean for every version I have to choose a different key file ?No, actually that won't work reliably because your EXE is the same in both versions -- at least for this test.

The combination of key files is used to tell one version apart from all others. So the most important criteria is that a version has, as its key file, a file that contains data that differentiates it from the other versions. This is normally very easy to do, even if (as in your test) it involves selecting a readme file that gets updated with the current version.

Key files are also considered "critical" files that must be there in order for a version to be considered a valid match.

In order for your version.txt file to serve as a key file for your test, it must match exactly the version.txt file listed on your version 1 tab in Visual Patch. Even a single byte of difference -- e.g. an extra space or carriage return -- will "break" the match.

Staggan
05-03-2006, 12:22 PM
Sorry I am getting very confused.

First, you say the key file is a file that is different between two versions... next you say that these two versions must be identical and have the same MD5 key....

You say

"For example, create version.txt in version 1 with this text in it:

"This is version 1"

Then create version.txt in version 2 with this text in it:

"This is version 2"

Select version.txt as the key file in both versions. You can select others if you want, but you don't need to."

So, I now have 1 key file for each version of the software, version.txt. Each version.txt is now different.


And then you say

"In order for your version.txt file to serve as a key file for your test, it must match exactly the version.txt file listed on your version 1 tab in Visual Patch. Even a single byte of difference -- e.g. an extra space or carriage return -- will "break" the match."

So, of course this will not work because the files ARE different and are supposed to be different.....

Or am I going completely mad ?

Staggan
05-03-2006, 12:26 PM
I should also add that I already tried it this way... and when I did this it could not find the software....

Lorne
05-03-2006, 01:21 PM
Sorry I am getting very confused.

First, you say the key file is a file that is different between two versions... next you say that these two versions must be identical and have the same MD5 key....Sorry, I was talking about two pairs of things:

- the two tabs in your project ("1" and "2")
- the "1" tab, and the actual installation you want to update

Let me rephrase the part that was confusing:

In order for your version.txt file to serve as a key file for your test, the version.txt file in your installation folder must match exactly the version.txt file listed on your version 1 tab in Visual Patch. Even a single byte of difference between the version.txt file in your installation folder, and the version.txt file on the "version 1" tab in Visual Patch -- e.g. an extra space or carriage return -- will "break" the match.

So, I now have 1 key file for each version of the software, version.txt. Each version.txt is now different.Good. That takes care of the Visual Patch project. Build the patch. :)

Then, make sure that you have Version 1 "installed" on your system, in the place where your registry key says it should be. And -- this is the important part -- make sure that the version.txt file in that "installed" location exactly, exactly matches the version.txt file that you added to the "version 1" tab in Visual Patch.

And then you say

"In order for your version.txt file to serve as a key file for your test, it must match exactly the version.txt file listed on your version 1 tab in Visual Patch. Even a single byte of difference -- e.g. an extra space or carriage return -- will "break" the match."

At that point I was referring to the file in the target folder that you are trying to patch.

You've created two make-believe versions. You want to bring version 1 up to version 2. You want to do this using a patch.

In order to test the patch, you need to have your "version 1" installed, so that your patch can find it, and update it to version 2. Let's call this installation of version 1 the "target folder."

You said the only thing different between version 1 and version 2 is your version.txt file. That makes it the only file that can serve as a key file. In order for "version 1" to be found, the version.txt file that is located in your target folder needs to match (exactly!) the version.txt file that you added to the version 1 tab in your Visual Patch project.

So:

the MD5 needs to be different between the two tabs in your Visual Patch project, AND
the MD5 needs to be the SAME between the version 1 tab and the target folder at the start of the test

If that isn't clear enough, try this:

Make two folders, named "Version 1" and "Version 2."
Create a file called version.txt in both of those folders. Put different text in them, so each folder has different text in its version.txt file, e.g. "This is version 1" and "This is version 2."
Create a patch project with two version tabs. Name them "1" and "2".
Add the file from your "Version 1" folder to the "1" tab.
Add the file from your "Version 2" folder to the "2" tab.
Build the patch.
Copy the "Version 1" folder to where you want it installed for the test. Rename it if you need to. (If you're using the registry search method, make sure the Insall_Dir key in the registry points to this "installation" location.)
Run the patch.

Staggan
05-03-2006, 04:14 PM
As far as I know this is exactly what I have been doing, and it does not work...

I will try again, but what you have told me is exactly what I expected should happen, and is exactly what I have done....

Lorne
05-03-2006, 04:20 PM
Yeah, it might make sense to start from scratch...just to help rule out silly human error (happens to the best of us :)).

csd214
05-03-2006, 04:47 PM
Yeah, it might make sense to start from scratch...just to help rule out silly human error (happens to the best of us :)).
I think that’s a good idea, Staggan. I have already told I’m an inexperienced VP20 user. I started my first project after reading the headlines in the user doc…. Guess what; I had several problems. You’ll find my solution:

“My version tabs were completely out of order, sorry.

I deleted the project and started from scratch; it doesn't take a long time.”

in this post http://www.indigorose.com/forums/showpost.php?p=57133&postcount=6.

Good luck, Staggan. :yes

Staggan
05-04-2006, 01:59 AM
Hi...

I have created a new project exactly as suggested, version 1 and version 2. I use the version.txt file as the key file for each version, and version 1 version.txt has an MD5 that matches the MD5 of the installed version.txt.

The only difference between version 1 and version 2 are the version.txt files.

I then got the "Software Not Found" error, the same as before.

As a test, I changed the key file in version 1 to the executable and rebuilt the patch.

Everything worked fine... except of course I want to use a single file to denote software version...

Lorne
05-04-2006, 10:19 AM
Hi...

I have created a new project exactly as suggested, version 1 and version 2. I use the version.txt file as the key file for each version, and version 1 version.txt has an MD5 that matches the MD5 of the installed version.txt.

The only difference between version 1 and version 2 are the version.txt files.

I then got the "Software Not Found" error, the same as before.
What registry key did you use? Note that the default registry key is HKEY_CURRENT_USER/Software/<company name>/<product name>/InstallFolder (not Install_Dir).

Does the value of that registry key point to the installation folder?

As a test, I changed the key file in version 1 to the executable and rebuilt the patch.

Everything worked fine... except of course I want to use a single file to denote software version...

I just performed the test myself, with no problems. Here's exactly what I did:


Copied C:\Program Files\7-Zip into C:\Temp\VP Test and renamed it "7-Zip 1"
Made a second copy and renamed it "7-Zip 2"
Added a file named version.txt inside "7-Zip 1" and put this text in it: This is version 1
Copied the version.txt file into "7-Zip 2" and changed the text to: This is version 2
Started Visual Patch and used the project wizard to create a project. I used "Lorne's Testing Service" as the company name, and "7-Zip" as the product name. Used default settings for the next 3 wizard steps.
On the "Define Versions" step, I clicked Add, changed the Version number from 1.0 to 1, set C:\Temp\VP Test\7-Zip 1 as the source folder, and C:\Temp\VP Test\7-Zip 1\version.txt as the key file. Then I clicked OK.
I clicked Add once more, left the Version number at 2, set C:\Temp\VP Test\7-Zip 2 as the source folder, and C:\Temp\VP Test\7-Zip 2\version.txt as the key file. Then I clicked OK.
For the next wizard step (Locate Installed Version), I left all three options enabled.
For the Read Location step, I left the main key as HKEY_CURRENT_USER, left the sub-key as Software\Lorne's Testing Service\7-zip, and left the value as InstallFolder.
I started regedit, navigated to HKEY_CURRENT_USER\Software, added a new key named Lorne's Testing Service. Inside that, I added a new key named 7-zip. Inside that, I added a new String value named InstallFolder. I double-clicked on InstallFolder and set its value to "C:\Program Files\7-Zip"
For the next project wizard step (File Search), I left the default values, but unchecked "Search all local hard drives"
On the Project Options step, I left all the default options enabled.
Clicked Finish, and voila, fully working project.
I pressed F7 to build the patch, change the output folder to C:\Temp\VP Test, and changed the patch filename to 7-Zip patch.exe
I ran the patch - software not found. Good -- I didn't copy the version.txt file into the installation folder yet.
I copied the version.txt file from C:\Temp\VP Test\7-Zip 1 into C:\Program Files\7-Zip
Ran the patch again, it found the software, and was able to patch it with no problems.
Opened C:\Temp\VP Test\7-Zip 1\version.txt and confirmed that it now contains "This is version 2" proving that the patch succeeded.


I'm not sure what you're doing wrong, but since I was able to perform the same test without any difficulties, and since we haven't received any reports of any problems with any of this functionality, it seems to me there must be something wrong with your test procedure. I thought it might be hard drive issue (file corruption) but comparing the MD5 signatures of the files should rule that out.

There isn't much more I can suggest without seeing your project. I know you didn't want to post too many details about your project publically. Perhaps another option would be to contact our support department (issue a ticket at support.indigorose.com), so you can provide a bit more information in confidence?

Staggan
05-04-2006, 10:23 AM
Hi Lorne...

My registry info is correct, otherwise when I just changed the key file, it would still not work.

I will try a patch again shortly, but as far as I can see, I am doing nothing wrong and following all instructions.

Failing this, I will try to create a test application that I can send, showing the problems... would that be alright ?

Lorne
05-04-2006, 11:31 AM
My registry info is correct, otherwise when I just changed the key file, it would still not work.Yeah, I found that strange as well.

I will try a patch again shortly, but as far as I can see, I am doing nothing wrong and following all instructions.

Failing this, I will try to create a test application that I can send, showing the problems... would that be alright ?Definitely. If you're able to produce a setup and project that will duplicate your test results that's something we would want to see for sure.