Media requested does not match media provided - BUT IT DOES?!

[Andromeda]

Thanks Rolf,

I had hoped that the Application Builder would have accepted the next major version, but alas, I still get "The media that you have provided is a valid installer, but it does not match the media requested". Same thing for the latest minor version on the NI download site.

This affects all of the projects using NI-VISA that I've migrated from another machine. I believe that LabVIEW keeps a registry of where it can find any additional installers that the Application Builder requires, as all of the migrated projects request the same media path (it's an instance of a built application installer). I had hoped that placing the NI-VISA installer in the cached drivers directory would have let LabVIEW find it, but no such luck. Even the version of the drivers that came with that version of LabVIEW isn't accepted. 

[rolfk]

---

@Andromeda wrote:

Thanks Rolf,

I had hoped that the Application Builder would have accepted the next major version, but alas, I still get "The media that you have provided is a valid installer, but it does not match the media requested". Same thing for the latest minor version on the NI download site.

This affects all of the projects using NI-VISA that I've migrated from another machine. I believe that LabVIEW keeps a registry of where it can find any additional installers that the Application Builder requires, as all of the migrated projects request the same media path (it's an instance of a built application installer). I had hoped that placing the NI-VISA installer in the cached drivers directory would have let LabVIEW find it, but no such luck. Even the version of the drivers that came with that version of LabVIEW isn't accepted. 

---

It depends also what component this is about. LabVIEW Toolkits and components often only work for the specific LabVIEW version that they are meant for. Installing a higher major version won't do anything here, as they will simply install in whatever LabVIEW version they were built for if that is present on your computer, but nowhere else.

Drivers such as NI-VISA, GPIB, DAQmx, etc. are a different story. They only can exist once on your computer as they contain parts that install directly into the Windows kernel and Windows is not built to allow different versions of a driver to be installed alongside each other. Here upgrading to a newer version truly will upgrade all. And while NI-VISA and NI-4882 are fully integrated into LabVIEW and don't really require LabVIEW specific components, DAQmx and most other drivers require also VI libraries to be installed into LabVIEW and their installer only supports the same and three previous LabVIEW versions. 

And then there are hybrid things like the NI Vision Toolkit, they are LabVIEW libraries but also only can exist once on your Windows system.

[Andromeda]

Thanks for the differentiation Rolf,

I might be best not to include a NI-VISA installer in our application installers, but it's convenient for our users, and I am under the impression that the NI-VISA installer won't overwrite a more current version that the user happens to have installed on their machine. 

What I'd like to be able to change is the location where the Application Builder believes it can find a particular installer: in this case, a specific version of the NI-VISA installer.

The project file doesn't appear to contain this information - somewhere, the Application Builder must maintain a list of where to find various installers.

The project file itself simply appears to specify which version of the NI-VISA installer it should bundle into the application installer:

<Property Name="DistPart[2].flavorID" Type="Str">_deployment_</Property>

<Property Name="DistPart[2].productID" Type="Str">{C13DF63E-9B02-4CA4-B4CA-3E9B56EFB217}</Property>

<Property Name="DistPart[2].productName" Type="Str">NI-VISA Runtime 14.0</Property>

<Property Name="DistPart[2].upgradeCode" Type="Str">{8627993A-3F66-483C-A562-0D3BA3F267B1}</Property>

I am under the impression that the Application Builder maintain this list somewhere as a private list. I'd like to make the Application Builder forget where it thinks that the NI-VISA runtime installer is located, so that I can point it to an actual NI installer (it currently looks for the NI-VISA installer in a non-existent previous version of the built application). Any ideas?

Thanks,

[rolfk]

These packages are all cached in  <ProgramData>\National Instruments\MDF\ProductCache. The mapping between the specific GUID and the actual product name/location is somewhere in the registry.

[Andromeda]

I originally placed the installer in:

<ProgramData>\National Instruments\MDF\ProductCache

My hope had been that LabVIEW might enumerate the installers in this directory to build its list of where each of the installer live. Alas, this is not so. I've confirmed that the product code in the LabVIEW project file (in this case, C13DF63E-9B02-4CA4-B4CA-3E9B56EFB217) matches the product code of the installer in that directory.

The same product code does does indeed appear as a key in the registry, where it provides a localized description string for the product. However, I can't find a path association in the registry, which makes me wonder where the path association might be. The registry would be a natural place to put it, but that does not appear to be the case. 

Since the Application Builder insists that the only possible location in which it can find the NI-VISA installer is the built application itself, I copied an installer that was built on the older machine into the build location. And, hey presto, the Application Builder was OK with that, and proceed to bundle the. NI-VISA runtime installer into the installer.

... almost.

Next, it wanted me to specify the distribution path for the application (an nidist.id). Perversely, no matter what I specified, it refused to accept the path. I always got a dialog that says "Invalid path for (product name). Try again?"

I finally made a fresh copy of the installer that had been built on the old machine, and pointed the dialog there. That appears to work.

 I am underwhelmed by the brilliance of NI's process of keeping track of where additional installers are located.