From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

size of 2010SP1 RTE

Solved!
Go to solution

Hi Wolfgang,

 

Unfortunately, this was a necessary change that was made in order to support soft dependencies in distributions, and to move away from using merge modules.

 

There's an item in the readme that addresses this. It links to this knowledge base entry, which has a possible workaround.

 

Luis

0 Kudos
Message 21 of 23
(4,771 Views)

Thank you Luis for the link!

 

Unfortunately, when using the Advanced Analysis Library the workaround cannot be used. Also, when following the steps given in the linked article to use merge modules, I received the following error:

 

merge.png

 

So the sad summary is: in the last three years the size of my executable has grown by about 25%, but the size of the distribution kit has grown by 700%... I am very unhappy about this general tendency of ever growing software package sizes. In few years we will need Blue Ray drives to distribute a simple 'Hello world' executable...Smiley Sad

 

OK, just for fun:


I have created a distribution kit of the following code:

 

#include <ansi_c.h>
int main ( int argc, char *argv [] )

{
    printf ( "%s", "Hello world" );
}    

The new MSI approach requires 74 MB, the workaround using merge modules is 22 MB only...

Just to add, the same error message appears for this example, so I tend to assume that something is wrong with this merge module approach.

0 Kudos
Message 22 of 23
(4,753 Views)

Hi Wolfgang,

 

Sorry I haven't responded earlier, I've been busy with some other projects recently.

 

I understand your frustration that deployment sizes keep increasing in recent years, and yes, it is irritating that a simple "hello, world" program now uses up almost 100 MB. The details for why this is happening to the software industry as a whole are a bit too messy to go into here, but the fundamental problem is that software nowadays has myriad dependencies, and it's sometimes pretty hard to pull these dependencies apart individually (via the use of merge modules for example). Using merge modules is fine for simple things, but as multiple patching/upgrade/downgrade scenarios increase in complexity, it becomes far too easy for something to go wrong when merge modules are packaged individually in an installation.

 

This is why the CVI distribution builder tool (and not just) has begun to move away from the use of merge modules. In CVI 2012 and earlier, whenever you deselected individual components under the CVI Run-Time Engine sub-tree, merge modules were used to include those components. This caused a never-ending stream of configuration problems with some of the more complicated upgrade/downgrade scenarios, and so the decision was made to replace merge modules with soft dependencies.

 

Yes, it's true that even when every single soft dependency is removed, the remaining installer is still noticeably larger, unfortunately. This is why that Knowledge Base article I linked to suggests pulling in merge modules, manually, as a way of maintaining the CVI 2012 behavior.

 

Unfortunately, one of downsides of using merge modules just became apparent with this error that you ran into. I haven't confirmed this yet, since I'm not looking at your computer, but I suspect that the reason for it is that some other software package upgraded the very same Microsoft merge modules that CVI installs, and so now the exact version dependency that parts of the CVI Run-Time Engine declare on these Microsoft merge modules can no longer be satisfied (unfortunately, merge modules must declare an exact dependency and not a version range).

 

To confirm that this is the reason for the error you're seeing, you could try temporarily hiding/renaming the two files listed below with the two that I'm attaching in this post. Then you can try rebuilding your distribution again and hopefully you won't get any errors.

 

 

C:\Program Files (x86)\Common Files\Merge Modules\Microsoft_VC90_CRT_x86.msm

C:\Program Files (x86)\Common Files\Merge Modules\policy_9_0_Microsoft_VC90_CRT_x86.msm

 

If you're able to build it without any errors you should end up with a distribution that's not much bigger than what you would have built with CVI 2012. The downside is that you might have to do this dance of occasionally replacing files in the global C:\Program Files (x86)\Common Files\Merge Modules\ merge module cache, since these files can also be installed/uninstalled/upgraded by applications other than CVI.

 

Luis

 

0 Kudos
Message 23 of 23
(4,707 Views)