Embeded Files - how to NOT extract all if only one needed?

Sep 25, 2009 at 10:31 AM
Edited Sep 25, 2009 at 11:58 AM

Hello everyone,

i'm new here and not native speaker - please don't be mean :)

I use dotNetInstaller BootStrap to deploy my prerequisities - its a big number of them.All of them goes like embedded files.

Questions:

1. How can i tell dotnetinstaller to not extract embedded files that are not "checkboxed" / not needed? They are siblings of each component right now but all of them  are extracted on start of installation.

2. How i can put some check box unchecked from start (Component is not installed but also not neccesary - in my case Alladin Diagnostix)

3. How i can pass commandline parameters of bootstrapper to all / choised components? (UPDATE:Already found - /ComponentArgs)

 

Some wishes:

Firewall exceptions - before any of download dialog is even showed - so i can make silent download ( may be already there - just not found them :))

Antivirus Exceptions - probably throught INI or XML configuration file beind shipped with Main installer and updated separately

Thank you for attention, reading and patience with my English.

 

Sep 25, 2009 at 12:42 PM
  1. This is not possible today. The feature would need to be implemented very differently - http://dotnetinstaller.codeplex.com/WorkItem/View.aspx?WorkItemId=4072
  2. The only thing that governs selection is installed checks. Add an installed check that always resolved that the component is installed and leave the component Required = false. I think it should be easier, so it's a useful feature request to leave the component unchecked - http://dotnetinstaller.codeplex.com/WorkItem/View.aspx?WorkItemId=4073
  3. ComponentArgs is specific to each component - do you really need an option to pass arguments to all components in one line?
  4. Can you please describe more in detail what you mean by firewall and anti-virus exceptions? How would that work?

Thx
dB.

Sep 25, 2009 at 1:47 PM
dblock wrote:
  1. This is not possible today. The feature would need to be implemented very differently - http://dotnetinstaller.codeplex.com/WorkItem/View.aspx?WorkItemId=4072
  2. The only thing that governs selection is installed checks. Add an installed check that always resolved that the component is installed and leave the component Required = false. I think it should be easier, so it's a useful feature request to leave the component unchecked - http://dotnetinstaller.codeplex.com/WorkItem/View.aspx?WorkItemId=4073
  3. ComponentArgs is specific to each component - do you really need an option to pass arguments to all components in one line?
  4. Can you please describe more in detail what you mean by firewall and anti-virus exceptions? How would that work?

Thx
dB.

1. I think it is already implemented because editor support internal embedded nodes - they staing thought before different checks

2.This trick is good but in case i udes "Installed" flag for those that are really installed - this flag appears on not installed node and looks ugly + mislead people

3.This feature is very good for Admins of big networks - so they can custom installprocess with batch (even huge one -they like it :))

4.I saw this feature in many usual installlers - they can create firewall exception to let yours installer / strap open needed ports for download

of corse i can write dll/exe with needed steps and run them by my self - but it will be a huge chunk of work and probably i'll reinvent this "bicycle" again but with qudratic wheels.

Thank you.

Andrew

Sep 25, 2009 at 2:05 PM
Edited Sep 25, 2009 at 2:05 PM
  1. While it looks implemented the extraction will extract everything all the time. Also many people separate embedded files from the configuration file, ie. they use a command line embedding with the InstallerLinker.
  2. Yep. This is probably not too hard to implement.
  3. Makes sense. Although this is just impractical rather than impossible without the "all" option (you have to specify it for each component).  
    I created http://dotnetinstaller.codeplex.com/WorkItem/View.aspx?WorkItemId=4074.
  4. I see. I filed http://dotnetinstaller.codeplex.com/WorkItem/View.aspx?WorkItemId=4075, please add your comments. If you could add some examples of installers that do that (and maybe some details how) that would be helpful.

Rather than adding some external DLLs yourself, why don't you contribute a feature to dotNetInstaller itself? See the doc on contributing, setting up your development environment, etc. You could start with something simple like (2) or (3).

cheers
dB.

Oct 2, 2009 at 10:17 AM

Ok then, i'll need a link with conditions of participation. I plan to start with selective cab extraction if it not produce huge overhaul in many places.

Andrew.

Oct 2, 2009 at 5:14 PM

There's a "contributing" section in the CHM. Let me know if it's insufficient or something doesn't work.

The most important thing would be, as Davide Icardi (the original author of dotNetInstaller) says: "always discuss the feature before rushing into an implementation". I'd add that I won't accept patches without unit tests that cover the new feature(s). The infrastructure for that is totally mature and you can test library-level constructs and drive the entire application from NUnit tests.

I was thinking about how to implement this specific feature. You could add an option to the EmbedFile and EmbedFolder component(s) to only extract when the parent component is required. Then, instead of including the files into the "master" CAB, the linker would generate individual CABs and embed them as resources that are named "component name.cab". Obviously that's the cab that needs to be extracted at bootstrapper runtime before the component is extracted and cleaned up when the component finished executing.

I am here to help you, feel free to ask questions.

 

Dec 2, 2009 at 4:06 AM

I've implemented this, without giving users any options (I don't think it's necessary). Files that are embedded under a component are CAB-ed into separate .CABs and extracted before a component needs to be installed. This is much more efficent in terms of disk space requirements (no need for the giant CAB which would double disk space requirements) and is faster since you only need to extract components that are needed for installation. I have this 700MB bootstrapper here and I upgraded it with zero configuration changes. It feels a lot better from the user perspective - there's a lot less waiting for the extraction.

Build 1.8.6034.0.

 

Mar 13, 2010 at 4:04 PM
Edited Mar 15, 2010 at 12:22 AM

Hi,

sorry to dig this old post out, could be for the record: I needed the exact same feature as 2. and implemented it myself. I could post a patch or a diff. I will post on the work item site. Such collaborations in particular could me made more easy with git...

Edit:
I just overread you said

There's a "contributing" section in the CHM. Let me know if it's insufficient or something doesn't work.

I will read it first.

Tom