Leaderboard

Upgrade Code, Product Code, and Package Code are three terminologies used by Microsoft Windows Installer (MSI) to identify the three dependencies your application installer is missing -- read more about what they mean here: http://blogs.msdn.com/b/pusu/archive/2009/06/10/understanding-msi.aspx (There are many explanations, this is just one good one) It sounds like you're on the right track using virtual virgin machines to test your distributable. Quick question -- if you install the distributable on your dev machine, will it run without the three errors about missing dependencies? I'm guessing the answer is yes. In this case, you can query your dev machine for those three Upgrade Codes to see if they exist as installed products in the registry. This reverse-lookup should point you to the actual name of the product needed, not just a GUID. Another option is inspection of the MSI (google "free MSI editor"). Using a tool like this, sleuthing for the three Upgrade Codes likely reveals the name of the dependent MSIs. Finally, I would recommend inverting your distribution building process. First, just build an installer with nothing but your application and the LV RTE, and install this on a staging machine. Of course it will fail, but then manually run app-specific driver installers on the staging machine, until you have finally satisfied dependencies of the application. This technique is way more agile than including dependencies into your installer to test, since you don't have to rebuild each iteration. (Full disclosure -- my company provides products and services with a laser-focus on LabVIEW application deployment)

Here is some of the Twitter thread: QUOTE I mentioned Releasing VI Scripting in NI Labs to NI right when NI Labs was first announced. Nothing has become of it however which is sad. Question to you MikaelH: How do you get scripting enabled in 8.6?

Here is my position on the topic: Scripting is out there and many people are using it to create some amazing tools for assisting LabVIEW development and automating various tasks. I'd like for NI to give us its blessing to create such tools, so that we don't feel like renegade outlaws and can feel comfortable sharing them with others. And, I'd love for NI staff to be able to contribute to the technical discussions around scripting -- the current position from NI seems to be that it doesn't exist. Bottom line, machine readable and writable source code is a prerequisite for creating software engineering tools. And, it would be great for NI to empower the LabVIEW community to create better software engineering tools for LabVIEW. Bottom line: I think that it would be of great value to let the LabVIEW ecosystem create innovative features and tools on the LabVIEW platform. It's a win-win situation.