InstallAware

So where are we on this subject?

I think a compiler variable will work fine as long as setting it to zero will block the change. Also it would be nice if we could set a value in InstallAware so that any new projects created could have whatever value we want to use as a default.

I'm still confused though about why the value is not restored to it's prior value. You mentioned that the system state would be changed during the install. Well the state is changed as soon at you change that reg value anyway. As for it being a MS bug I agree 60 minutes is too long but 10 seconds is too short for normal web browsing. Not everyone has a T1 line lol.

I would like to see the Compiler Variable for the timeout value and the ability to restore the original value when the install engine ends.

I was happy to find and read this topic as I have currently run into issues in regards to the aforementioned registry key change. As for a possible solution, if there is no consequence in changing the timeout as the installer initializes and then reverting it back to what it was set to before than that is the option that I prefer. A compiler variable will also work, I just want something ASAP.

When will be be given a fix for this issue? If it is not soon I am going to need to workaround this by having my application check and change the key when my application loads (users are getting anxious). This issuing is causing my application to clash with another vendors application that a lot of my users are using (i.e; the vendors web app is not working properly).

Will the update scheduler also be blocked from causing this change in the fix?

tmiller11 wrote:When will be be given a fix for this issue?

I do not think there is a plan to fix this. I believe you will have to work around this issue yourself.

Not at all, we've obtained valuable feedback through this thread and will be incorporating this in an upcoming update.

Hi Michael,

Do you have a timeframe for this release? I need an immediate fix and wasn't sure if I should stall for something soon or not.

Sorry, no time frame as yet.

tmiller11 wrote:Hi Michael,

Do you have a timeframe for this release? I need an immediate fix and wasn't sure if I should stall for something soon or not.

I would figure out a work around. This problem was reported July 12.

Jay, please be publicly advised that we don't tolerate negative bias against our hard-working selves in these official InstallAware forums.

CandiceJones wrote:Jay, please be publicly advised that we don't tolerate negative bias against our hard-working selves in these official InstallAware forums.

Hi Candice,

I am aware of your ability to ban customers from forums. I would not think my response had a "negative bias". Your customer was trying to find out from InstallAware when the problem would be fixed because he needed an "immediate fix". IA responded with "no timeframe". I was assisting the poster that he would need to create a workaround because of the time that has already passed with this as a known issue. Perhaps IA will be posting a timeframe for the fix, in which case my response can be ignored, and the poster can decide based on this date if he needs to create a "workaround".

Respectfully,
Jay

Thanks for the note, Jay - it is appreciated!

Hi!

When the first post of this issue appear i didn't take it seriously for my installer. And today i'm gonna be one of the numerous developers who want that (ReceiveTimeout and other) parameter to be outcome correctly.

A little story:
We (the company I work for) had many problems with Web Updates. Till today we struggled with sporadic Web Update failures. InstallAware's Download File function returns ERROR. No more info to look in. Using the same Setup.exe some machines were successful in updating some were not.

After two month of issue search, I took a notice to this topic (i would say it become a flame, 3 pages, wow!). So I check this parameter (ReceiveTomeout) in the registry of our customers, and what i see, this parameter is set to 10 seconds.

I simply opened a web browser on one of our customers machine and try to download a web update installation executable from the server (another customer machine) and get a timeout error!!! This means that
a product created by InstallAware Studio has step on it's own minefield.
Receiving the same TimeOut error.

My Project Manager is very anxious and angry on me because of this. It was I who recommended to use InstallAware as a RAD tool for our installer products. Now we need to overcome this issue (look for workaround). We have thousands of client machines which use Web Updates (inside their networks). We cannot put a requirement for their network that it should have a ReceiveTimeout less than 10 seconds.

InstallAware, please, at least provide us with the info when you made this change inside the registry (during the first execution of Setup.exe or not). Is there any wai I can change it back during setup script? How to outcome this?

P.S. As an advice (still have a ray of hope that i'll be heard) for future versions (maybe my company would prolong the license after all of this) Download File would return more informative error message, instead of just ERROR. And IA's installers never ever make a change to the system that is not on the installation script!

Desperately in need of your help!!!
Thanks in advance.

We are still unable to locally reproduce this issue on any of our machines, but we fully understand and acknowledge that this is causing issues in the real world for a growing portion of our customer base.

The workaround is very simple - just use the free Write Registry Persist plug-in, available for free at this very forum:
http://www.installaware.com/forum/viewtopic.php?t=530
And set the timeout to whatever value you like.

As documented earlier on this thread, the value will be changed any time Download File is called, or a Web Media Block statement is activated (which happens when any setup commands that require access to installation media, such as Install Files, execute following a Web Media Block declaration).

We're definitely sorry about the unforeseen hassle - if its any consolation, we were trying to make the product better! This issue will be resolved in upcoming updates, based on all feedback from this thread, internally within InstallAware. Until then, the workaround above should be great.

Hi, Michael!

Thank you for such a quick response!

I'll try to implement your workaround. If I understand correctly i need to change the registry after Download File or Web Media Block was used?

What about Download File itself? In my case Download File is the source of a problem. Download File receives timeout after 10 seconds. I don't know why is this, but such is the configuration of a network of our clients, and we cannot change it. I suppose they have low ping or some delay in a request. Though it is a local network.

If I change back to 1 minute the Timeout interval, Download File would preserve the change?

Or Timeout will be changed inside Download Timeout call? If it is so, then reseting the value before Download File would mean nothing. Cause the timeout is inside Download File. Same for changing it afterward (only to restore the functionality of other applications). Web Update download would still have ERROR result.

Any ideas?

That's an interesting problem. Yes, the change would be made inside the Download File call...

I am not sure how this could be addressed, other than re-trying the download, providing redundant download URLs, and such. You may provide multiple URLs (even if they are the same) as part of a Web Media Block declaration, for instance.

Hi Michael,
By using the plugin you recommended to rewrite the value of HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ReceiveTimeout, I noticed that it changes the type of the key from binary to string...

Is it possible not to change the type? Or, does the key type have any influence what so ever?

Thanks in advance for your help!