This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- FlexNet Connect
- :
- FlexNet Connect Forum
- :
- Error 1155 when installing a patch
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 14, 2002
08:56 AM
Error 1155 when installing a patch
I am trying to download and install a Software Application Update for version 1.00 of my product, to update it to version 1.10. I have registered my product, both versions, and a Software Application Update message. The message points to a file on my computer (e.g., file://mylocation\Update.exe). Update.exe was created using the InstallShield Developer 7.04 Patch Wizard.
The update apparently downloads successfully, and the installation process starts. However, I get an error message "1155: File G:\Documents and Settings\Administrator\Desktop\ISScript.msi not found". At first I thought something might be wrong with the patch itself, so I manually launched Update.exe on my computer. It successfully updated to version 1.10, so the patch is OK. The error occurs only when applying the patch via the Update Service.
Anyone have an idea what's going wrong? All input appreciated, thanks.
The update apparently downloads successfully, and the installation process starts. However, I get an error message "1155: File G:\Documents and Settings\Administrator\Desktop\ISScript.msi not found". At first I thought something might be wrong with the patch itself, so I manually launched Update.exe on my computer. It successfully updated to version 1.10, so the patch is OK. The error occurs only when applying the patch via the Update Service.
Anyone have an idea what's going wrong? All input appreciated, thanks.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 14, 2002
11:15 AM
Very strange. The Update Service only downloads and runs the update. It can pass command line options. But the update should act the same either way.
To debug, lets first double check that the file is the same.
If you are using the full (web-like) UI, you have option to download the update without running it. Give that a try. After downloading the file, make sure it is indeed the correct file. Then try running the file.
If the file is the same, we will have to look at how update.exe goes looking for the MSI - as it can't seem to find it.
To debug, lets first double check that the file is the same.
If you are using the full (web-like) UI, you have option to download the update without running it. Give that a try. After downloading the file, make sure it is indeed the correct file. Then try running the file.
If the file is the same, we will have to look at how update.exe goes looking for the MSI - as it can't seem to find it.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 15, 2002
09:55 AM
Chris, thanks for your suggestion. Before you posted your response I had received the same suggestion from another source. Yes, the Update.exe file is the same (no change in size or file permissions). I got the same error when I downloaded and then manually launched it.
As you suspected, ISScript.msi isn't found in any of the folders that are searched on the target computer. And I did not pack it into Update.exe; I specified "Copy from source media" when I used the Patch Wizard. When I first used the Patch Wizard I tried to specify "Extract engine from Update.exe", but that caused a crash and the patch would not generate.
I'm using the same computer to develop the test app, the test install, generate the patch, and test the update. So, the folder that had Update.exe on my computer also had ISScript.msi when I generated the patch by specifying "Copy from source media". When I checked the integrity of the patch itself by launching Update.exe on my computer, that's why it worked, and that made me erroneously suspect that something was wrong with the Update Service.
When I ran the Patch Wizard again specifying "Download engine from the Web", then tried the Update Service, everything worked OK! 🙂
I wonder if there's a way to specify downloading every file in a folder (and not just Update.exe) when you create a Software Application Update message in Update Service. That would be another way to avoid this problem. Thoughts??
As you suspected, ISScript.msi isn't found in any of the folders that are searched on the target computer. And I did not pack it into Update.exe; I specified "Copy from source media" when I used the Patch Wizard. When I first used the Patch Wizard I tried to specify "Extract engine from Update.exe", but that caused a crash and the patch would not generate.
I'm using the same computer to develop the test app, the test install, generate the patch, and test the update. So, the folder that had Update.exe on my computer also had ISScript.msi when I generated the patch by specifying "Copy from source media". When I checked the integrity of the patch itself by launching Update.exe on my computer, that's why it worked, and that made me erroneously suspect that something was wrong with the Update Service.
When I ran the Patch Wizard again specifying "Download engine from the Web", then tried the Update Service, everything worked OK! 🙂
I wonder if there's a way to specify downloading every file in a folder (and not just Update.exe) when you create a Software Application Update message in Update Service. That would be another way to avoid this problem. Thoughts??
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 16, 2002
11:55 AM
We have bounced around that idea.
Concept: You provide updated files in a folder and the Update Service just downloads them. This would be very useful if you are frequently updating tons of content (i.e. 300 PDF files on a weekly basis) and don't want to bother with patching. In some cases the author of the content doesn't even sit in the same building as the engineer who created the product. However, the concept runs into problems if you start installing key files (or new files). MSI prefers that you use it to install those things.
In the end, I think a couple of things need to be done to make updating easier:
1. Make patch creation easier - especially when you just need to send out a couple of new files. Our Developer product team is working on that one.
2. A "sync" feature for sending out content that is updated frequently.
I would love to hear any additional thoughts or ideas on this topic.
Concept: You provide updated files in a folder and the Update Service just downloads them. This would be very useful if you are frequently updating tons of content (i.e. 300 PDF files on a weekly basis) and don't want to bother with patching. In some cases the author of the content doesn't even sit in the same building as the engineer who created the product. However, the concept runs into problems if you start installing key files (or new files). MSI prefers that you use it to install those things.
In the end, I think a couple of things need to be done to make updating easier:
1. Make patch creation easier - especially when you just need to send out a couple of new files. Our Developer product team is working on that one.
2. A "sync" feature for sending out content that is updated frequently.
I would love to hear any additional thoughts or ideas on this topic.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 16, 2002
12:49 PM
Chris, in response to your request for some ideas, here are a few thoughts.
I used to be the administrator for internet distribution of software updates at my prior company. We used a tool called Castanet, written by Marimba, Inc., in Mountain View, California. I know that InstallShield currently has some sort of technology partnership agreement with Marimba, but I am uncertain of the details. Castanet is expressly intended to provide remote customers with web-based software updates. Briefly, here are some product features offered by Castanet that would prove useful to the InstallShield Update Service, if the technology agreement would permit it.
1. There is actually no concept of a "patch" at all. Instead, when a customer connects to the website that hosts updates for the product they've purchased, the customer's computer (the client) communicates with the update server (called a "transmitter" in Castanet lingo) to dynamically determine any differences between what the client computer has and what it should have. Once this has been determined, a new "patch" (if you want to call it that) is created on the fly that contains whatever is necessary to bring that particular client up to date. New files are sent, old files are deleted on the client, and modified files are sent "bitwise" (just as the Patch Wizard does, only the difference bits are used). In effect, any client that has any earlier version of the product is updated to the latest version. I.e., messages are not targeted to particular versions.
2. If the data transfer is interrupted, the client can reconnect later and "pick up where it left off". There is no need to start all over again.
3. The update can be performed for a client running any operating system. When the client communicates with the server, the server automatically determines the O/S of the client, searches to see if a compiled version of the app is available for that O/S, and if so, the updates needed to bring that specific client up to the latest version are sent.
4. If a company has thousands (or hundreds of thousands) of customers who regularly check the server for updates, the administrator has the option to easily "chain" servers together ... if one is overloaded, then clients are invisibly directed to another server in the chain (all servers have the same update files available). The customer never knows the difference.
5. A check for updates can be scheduled to occur automatically. Some companies use this feature to update all their employees' computers at, say, 4 am on each Sunday. At the start of each week, every employee automatically has "the latest stuff", without any effort on their part.
I could make a few other suggestions, but this reply is getting a little long-winded. If you're interested let me know and perhaps I could send a private message with more details.
Hope you find this info. to be interesting and beneficial.
I used to be the administrator for internet distribution of software updates at my prior company. We used a tool called Castanet, written by Marimba, Inc., in Mountain View, California. I know that InstallShield currently has some sort of technology partnership agreement with Marimba, but I am uncertain of the details. Castanet is expressly intended to provide remote customers with web-based software updates. Briefly, here are some product features offered by Castanet that would prove useful to the InstallShield Update Service, if the technology agreement would permit it.
1. There is actually no concept of a "patch" at all. Instead, when a customer connects to the website that hosts updates for the product they've purchased, the customer's computer (the client) communicates with the update server (called a "transmitter" in Castanet lingo) to dynamically determine any differences between what the client computer has and what it should have. Once this has been determined, a new "patch" (if you want to call it that) is created on the fly that contains whatever is necessary to bring that particular client up to date. New files are sent, old files are deleted on the client, and modified files are sent "bitwise" (just as the Patch Wizard does, only the difference bits are used). In effect, any client that has any earlier version of the product is updated to the latest version. I.e., messages are not targeted to particular versions.
2. If the data transfer is interrupted, the client can reconnect later and "pick up where it left off". There is no need to start all over again.
3. The update can be performed for a client running any operating system. When the client communicates with the server, the server automatically determines the O/S of the client, searches to see if a compiled version of the app is available for that O/S, and if so, the updates needed to bring that specific client up to the latest version are sent.
4. If a company has thousands (or hundreds of thousands) of customers who regularly check the server for updates, the administrator has the option to easily "chain" servers together ... if one is overloaded, then clients are invisibly directed to another server in the chain (all servers have the same update files available). The customer never knows the difference.
5. A check for updates can be scheduled to occur automatically. Some companies use this feature to update all their employees' computers at, say, 4 am on each Sunday. At the start of each week, every employee automatically has "the latest stuff", without any effort on their part.
I could make a few other suggestions, but this reply is getting a little long-winded. If you're interested let me know and perhaps I could send a private message with more details.
Hope you find this info. to be interesting and beneficial.
