NI Pacakge Builder - Discover excluding files -16068

[JLohse]

Hi.

We have found what seems to be an inconsistency regarding the discover tool in NI Package Builder.

I have a large amount (208) of files I would like to include in a package and I would like to add them as inputs. However when I drag and drop, or browse the result is the same, the folder into the "input - dependency view" field I often get the output: "- Info: 16068: Discovery excluded 3 file(s)".

It is the same three .dll files that are missing. There are a lot of other .dll files that are add so I do not know why these files are excluded.

At some point I found that the issue could be a long path, ID 252783. I then moved the folder, containing all the 208 files, to C:\ but the result was the same. For some reason I then moved the folder to the desktop and tried from there and all the files was discovered. 

I have attached an image of the output from both discover processes, the red one is when the folder is on C:\ and the green is on the desktop. 

The files I am trying to discover are the installation files to SQL Express and have a total size around 750MB if that has anything to say.

My workaround so far has been to manually add the tree missing files and this works fine. The package builder does complain when the solution is opened that it will not be able to discover in a bunch of different directories, image attached. 

The packages can still be build and installed successfully, the behavior just seems unintended.

I hope you can shine some light on the situation and make the discover function more consistent.

Best Regards.

Jeppe Lohse

CLD, CTA

[SeanMiddleton · Accepted solution]

HI,

Thanks for your feedback.

• Those DLL are excluded because they are Microsoft DLLs.  We want to encourage a workflow where Microsoft DLLs (and NI DLLs) are installed separately from the user-created package.
• With that said, we will investigate making this workflow simpler to support since we may have created too large of a hurdle.  To more easily include Microsoft DLLs:
  • The exclusion file is located at:
    • "C:\\Users\\<account>\\AppData\\Local\\National Instruments\\NI Package Builder\\DiscoveryExclusion.txt"
  • Then delete these lines which exclude a Microsoft directory:
    • [Windows]\\WinSxS
  • Then delete these lines which exclude Microsoft DLLs:
    • Microsoft, Microsoft.?.?.?.?.?.?.?Windows
      Microsoft, NET Framework
      Microsoft, Office
      Microsoft, Microsoft.?.?.?.?.?.?.?Visual
• I want to mention something that you might not be aware of.  If you click on the button which I highlighted in the attached image, then it will list the files which were excluded. 
• Finally, we are fixing the solution load message (Load Error PNG file) in our next release.  Sorry about that.

Regards,

Sean

[JLohse]

Hi Sean

Thank you for the quick reply.

Deleting the lines in the exclusion file worked and the files are no longer excluded. I am still wondering why they were not excluded when they where located on the desktop.

Anyway, thank you for the quick solution and extra info of the additional details button.

Best Regards,

Jeppe Lohse

CLD, CTA

[J.C._Andersen]

Hi Sean.

I have two followup questions regarding this.

When you say that you want to encourage a workflow where Microsoft DLL's and also NI DLL's are installed separately, how do you then suggest that we build a complete installation for a test station including deployment of NI TestStand and MS SQL Express database server for handling test results and test properties? We want to make the experience of deploying a new test station as seamless as possible for our customers. Thus we want the installation of all components to be installed by running just one installer that takes care of it all. In some cases it all has to run in silent mode.

The last question I have has a reference to an earlier thread that I started in here: Will the next release be a bug-fix release or another minor release? This is important to know because only bug-fix releases shows up automatically in NI Packages Manager. If it is a minor release we have to "poll" for it manually, or we have no way of knowing that it has been release.

Thanks.

[Scott_Richardson]

Hi Jens Christian -

In general, NI DLLs should be distributed via the packages that NI uses to install its software, for example a LabVIEW runtime. For Microsoft DLLs, we do not want NI Package Builder to discover system DLLs that might be called by TestStand, so we want to exclude those. NI Package Builder is doing excluding in a similar way to TestStand Deployment Utility. Potentially in the future, we would like to expose the configuration of our discovery exclusion file, but for now we just document it in the help under the information message with code 16068. Base on this posting, we will want to review the current exclusions that we define to determine if there is any adjustments necessary.

It is our desire to release quarterly so that we can quickly deliver new features and any necessary bug fixes. As such most releases will be minor releases and rarely patches, so you will need to manually "poll" for our release online or in NI Package Manager Browse Products tab since the releases will not show up on the Updates tab in NI Package Manager.

[SteenSchmidt]

---

@Scott_Richardson wrote:

It is our desire to release quarterly so that we can quickly deliver new features and any necessary bug fixes. As such most releases will be minor releases and rarely patches, so you will need to manually "poll" for our release online or in NI Package Manager Browse Products tab since the releases will not show up on the Updates tab in NI Package Manager.

---

This seems very counter intuitive: Minor releases are updates, right? Why won't they show up on the Updates tab?

Also consider:

- Minor updates may include bug fixes without a separate patch being released with the bugfix alone. Isn't it important that users discover those bugfixes?

- Users may have hundreds of packages installed, do you envision users poll for changes to each of those on a regular basis? And on every machine they use packages on?

- Most other software I use allows me to set it to automatically scan for updates. Such updates are always both minor and patches. In some cases even notification of major version updates.

I can put it in a different way: If NIPM won't notify our users of all updates, then we'll have to make such a service ourselves. It would be lacking in the product.

[CL_eisenwr]

SteenSchmidt,

I have seen the point about updates come up in several threads. The answer currently has been that NI Update is the automatic checker for major/minor updates. I do agree it would be better to have all of the functionality in a single tool, NI Package Manager, but give options to what level/type of updates are shown.

[SteenSchmidt]

An option to set check level would be a good solution.

Perhaps back to Jeppe's original thread then 😉 There has been mention of a mechanism in NIPB to be able to point out external dependencies - dependencies that are not NI packages, but for instance could be an OPC Server, or a MS SQL Express installer or what have you. Stuff that must be sucked in from other sources and which there probably should be some configuration control over (like with a standard MSI-install builder). Is that still on the roadmap? That would be a good solution for third party dependencies, instead of having to repackage them as NI packages (with varying difficulty and responsibility inheritance).

[J.C._Andersen]

Hi Scoot.

Thank you for your answer.

First I want to state that we would always install NI software using NI packages. When we build a solution in NI Package Builder where our own packages depend on e.g. TestStand and LabVIEW Runtime, we add the NI packages for these products as dependencies. I believe that is what we are suppose to do.

The problem with the MS SQL Express installation is that it comes from Microsoft as a self extracting exe. In order to run the installation with the silent switch set, you need to run the Setup.exe which is extracted from the self extracting exe. So, what we are trying to do is to add the folder which is created by the self extracting exe to a packages in our NIPB solution. Unfortunately that folder does not only contain the Setup.exe but also a bunch of other files, including some DLL's.

As Steen has just mentioned, it would be nice if the NIPB at some point could be enabled to build solutions with third party dependencies.

[CL_eisenwr]

FYI I have posted a NIPM Idea for displaying the major and minor updates.