2.0 htmlInstaller issues...

Sep 13, 2010 at 5:22 PM

Hi,

As discussed here (http://dotnetinstaller.codeplex.com/Thread/View.aspx?ThreadId=224650), I tried the latest (55043) and yes, a download dialog appears (as per dotnetInstaller).

I'm not going to use the download dialog - don't see the value in it with dotentInstaller... hence why I added a call to CreateInstallWindow in ConfigFileManager::OnDownload

I did set autostartdownload = True in the download config but I still see the download dialog flash up before the reference config window appears...

I also noticed that the Cancel button doesn't cancel but continues to download the reference config (as per dotnetInstaller - http://dotnetinstaller.codeplex.com/Thread/View.aspx?ThreadId=225629

So all in all, thanks... but no thanks ;)

Also, the components are displayed in reverse order (only in htmlInstaller) - bodged the for loop in InstallUI.cpp.

Also, is it possible to display the download size of a component as part of the description?

Thanks,

 

 

Sep 13, 2010 at 6:20 PM

So the first question is about the download dialog for the reference configuration. Something needs to display errors and show progress when it takes time to download the configuration. Lets assume an error can appear outside the dialog - maybe this needs an option not to display the download dialog for reference configurations? Thoughts?

I thought about merging this download process into the main window, but this presents several problems. The most obvious one is that you need the reference configuration already downloaded to display the dialog with proper text, locale and options. If I merged them, the flashing would be the same except now you have the main dialog flashing in English, then switching to Spanish for example.

I made a commit that fixes the download / cancel @ rev. 55043 and the fix for the order of components @ rev. 55052 (it's not as easy as the loop, that one's correct - the components are inserted on a different (UI) thread so the insertion is queued - the index at which to insert was calculated before the actual insertion occurred, being zero most of the time) - the fix is to move this to the UI thread.

To display download size of a component as part of a description something would need to figure out the download size. How do you see this happen? Do file a feature request if you can tell a good story :)

 

Sep 14, 2010 at 11:02 AM

My comments...

So the first question is about the download dialog for the reference configuration. Something needs to display errors and show progress when it takes time to download the configuration. Lets assume an error can appear outside the dialog - maybe this needs an option not to display the download dialog for reference configurations? Thoughts?
I agree, I think it should be an option... if an error occurs, it will be displayed in a modal I guess..?

I thought about merging this download process into the main window, but this presents several problems. The most obvious one is that you need the reference configuration already downloaded to display the dialog with proper text, locale and options. If I merged them, the flashing would be the same except now you have the main dialog flashing in English, then switching to Spanish for example.
I agree... the merge wouldn't work.

I made a commit that fixes the download / cancel @ rev. 55043 and the fix for the order of components @ rev. 55052 (it's not as easy as the loop, that one's correct - the components are inserted on a different (UI) thread so the insertion is queued - the index at which to insert was calculated before the actual insertion occurred, being zero most of the time) - the fix is to move this to the UI thread.
I'd gladly take a new revision if the new reference config dialog is an option... (I see the thread issue now..)

To display download size of a component as part of a description something would need to figure out the download size. How do you see this happen? Do file a feature request if you can tell a good story :)
My dev mgr looked at my POC and it was the first thing he said... "As a user, I'd lile to know how big each MSI is before I click Start..." - We pre-req .NET Framework 4.0 and VS Shell 2010.
Unsurprisingly, GetFileAttributesExW() doesn't like http.. So far, I've added another <Component> element called sourcesize which is added to the component description (works but obviously not dynamic).

p.s. I've upgraded the sln/proj's to VS 2008 (works okay) but VS 2010 moans about various things...

p.p.s. you seen WiX's Burn? sadly, not a patch on this... ;)

 

Sep 14, 2010 at 12:25 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Sep 14, 2010 at 12:27 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Sep 14, 2010 at 12:37 PM

I created #7165 to make the download dialog optional and #7166 to fetch file size. The second one is not trivial at all, especially that you would want the UI to come up first, then to fetch the file size asynchronously (it will often take a couple of seconds and might fail in offline scenarios - it's done via an HTTP HEAD request).

I think you could write a small utility in .NET that takes a dotNetInstaller configuration file, loads it, iterates through download dialogs and figures out the file size out there, then updates the description with the file size. Everything except the last part is already done in InstallerLib - contribute the tool to dotNetInstaller.

We won't upgrade to VS 2008 because that code won't run on Windows 95/98. I know it's time to move on from the ancient OS, but last time I tried it someone working on a charity project using dotNetInstaller to deploy software on Windows 9x machines in Africa complained. Since the upgrade doesn't really accomplish anything, I'll stick to the good old VS 2005. Certainly you can upgrade on your machine for development purposes.

We've been waiting for Burn for several years. If you're not subscribed to the wix mailing list, you should be, it's a regular heated debate. I think Burn is going to be great and I will certainly invest time into trying it out and if I love it, implement a migration path from dotNetInstaller to Burn (or someone will contribute). But wouldn't underestimate how much work it is to get a bootstrapper solve the many deployment problems out there - I don't expect Burn to be production ready and proven like dotNetInstaller for another couple of years - that's eternity in Internet time. By then dotNetInstaller will celebrate its 10th anniversary.