LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

distributing dll versions

If I try to install a DLL that I've created with CVI, will it override the same dll of a newer version?

 

i.e., if by chance an old distribution of a dll gets used, will it install on top of a newer version of the same dll?  Is this behavior any different depending upon whether the DLL is distributed as a DLL only, or as part of a dependency to another DLL or executable?

 

Menchar

0 Kudos
Message 1 of 7
(4,541 Views)

With CVI distributions, upgrade versioning is not handled on a file-by-file basis, but rather at the level of the installer (all or nothing). So if we're talking about two different builds of your distribution (with different installer version numbers) then the older one will not install over the newer one, so the newer DLL will remain. Because the versioning is handled only at the installer level, if you create two separate distributions in CVI that contain the same DLL, both of them will actually install the file. In that case, the DLL on the system depends on whichever installer ran last. Additionally, when either package is uninstalled, the shared file will be removed, likely breaking the remaining package. You really want to avoid having multiple different distributions that install the same files to the same locations.

 

If you need per-file versioning (e.g. to include shared component DLLs in multiple different distributions), then you can use a 3rd-party tool to create a merge module. There is a button on the Drivers & Components tab that allows you to add merge modules to your distribution. The benefit of creating a merge module is that the files in it will retain the same component GUIDs in every different distribution you merge it into, which will prevent the blind overwiting that occurs otherwise.

 

When you include the CVI RTE in your distribution, it is usually included in merge module form.

 

Mert A.

National Instruments

0 Kudos
Message 2 of 7
(4,521 Views)

Mert -

 

Thanks for the reply.  I guess merge modules is more than you (NI) might want to bite off as far as distribution editor functionality.

 

Does anyone have any thoughts on a good third party tool?  I seem to recall that there was one particular tool that everyone seems to use ... I just can't remember its name.

 

Menchar

0 Kudos
Message 3 of 7
(4,478 Views)

There's a variety of tools out there on the market today. I use WiX to create installers and merge modules and I can personally say that its a great tool to use.

 

Best Regards,

Jonathan N.
National Instruments
0 Kudos
Message 4 of 7
(4,465 Views)

Thanks for the tip.

 

How hard was it for you to come up to speed on the tool?    Was it worth the effort?

 

Menchar

0 Kudos
Message 5 of 7
(4,451 Views)

I researched and played around with WiX for probably a good-month or so before I started actually using it. I could have picked it up sooner (i.e. maybe a good week) but I wanted to thoroughly understand this new tool and all that it had to offer. The time spent was definitly worth the investment as WiX has made our lives much easier. 

 

As a side note, if you like Visual Studio, WiX 3 introduced template projects to get your started (i.e. templates for MSMs, MSIs, etc). If you are needing to create a new MSM, you could start off with their MSM template and go from there.

 

Best of luck...

Message Edited by Jonathan N on 02-19-2009 12:17 PM
Jonathan N.
National Instruments
0 Kudos
Message 6 of 7
(4,446 Views)

Hello,

 

i hope i´m right within this thread, but as i´ve seen your familar with Wix.

 

I´m currently using Windows Installer XML V3 to deploy a larger software project. The project is based on .NET 3.5 and Windows.Forms.

This works fine.

 

The software also has the ability to be extended by, what we call 'plugins'.

As we have some plugins that are very common and used by nearly every user we also want to deploy them with the installer / msi package as an optional install option.

This also works fine for most of the packages.

 

But some of them depend on NI Analysis Enterprise. So i add all the necessary msm packages as listed in the documentation.

But WIX returns an error if i try to build the msi then:

 

 

 

light.exe(0,0): error LGHT0204: ICE30: The target file 'NATION~1.CON|NationalInstruments.Common.config' is installed in '[ProgramFilesFolder]\' by two different components on an LFN system: 'C__380348CE3F0F45BF9C3D53C615155DFF.243BBD6632074B44BCDC8E5E58FE6937' and 'C__66FEB06DFC8145D79D54E8D9A51BE781.243BBD6632074B44BCDC8E5E58FE6937'. This breaks component reference counting.

light.exe(0,0): error LGHT0204: ICE30: The target file 'NATION~1.CON|NationalInstruments.Common.config' is installed in '[ProgramFilesFolder]\' by two different components on an LFN system: 'C__380348CE3F0F45BF9C3D53C615155DFF.243BBD6632074B44BCDC8E5E58FE6937' and 'C__66FEB06DFC8145D79D54E8D9A51BE781.243BBD6632074B44BCDC8E5E58FE6937'. This breaks component reference counting.

error LGHT0204: ICE83: Both MsiPublishAssemblies AND MsiUnpublishAssemblies actions MUST be present in InstallExecuteSequence table.

error LGHT0204: ICE83: The MsiPublishAssemblies action MUST be present in AdvtExecuteSequence table.

 

 

 

I was able to get rid of the ICE30 errors by creating my own MSM package throw the VisualStudio2008 Setup assistant and adding this msm to my WIX project.

But this is on the one hand not the way i want to use it and on the other hand the ICE83 errors still remain.

So i´m still unable to build my msi file.

 

This error is very similar to this one:

http://forums.ni.com/ni/board/message?board.id=232&message.id=4200

but this thread is quite old now, and no solution is provided. 

 

Anyone of you have any suggestions about this ?

 

 Thanks in advance,

    Matthias

0 Kudos
Message 7 of 7
(4,250 Views)