LogMAN

Done 🙂

It depends. Sources files link to each other using relative paths, except for items in well-known locations (vi.lib, user.lib, instr.lib, etc.), which are referenced relative to their well-known location. As long as you don't change the relative location of files, nothing changes. This is a side-effect of how the dependency tree is generated. Instead of re-computing linkage information, LabVIEW relies on linkage information that is stored in a VI. So, if you change a typedef and don't apply (and save) all its callers, then the callers will have outdated type information, which can result in "ghost" dependencies. Clearing the compiled object cache and mass-compiling your project should generally fix these issues. There are some exceptions where this doesn't work but let's just hope it doesn't apply here 🙂

It appears to be working when unchecking the "Remove unused polymorphic VI instances" option in the build specification. Not sure why because the library does not seem to include any polymorphic VIs 🤔

The latter. Just like @hooovahh explained, the files are copied to a temporary location which can result in longer paths. The output directory for your application determines the location of the temporary folder, which is actually just the name of the executable as a folder (i.e. "Application.exe" but it's a folder). EDIT: Regarding vi.lib, these files also reside inside the "Application.exe" folder. Here is an example for JSONtext: "C:\Code\Repository\builds\Untitled Project 1\My Application\Application.exe\1abvi3w\vi.lib\JDP Science\JSONtext\LVClass Serializer" Here is an example of what it looks like during build.

This error happens when one of the files exceeds the maximum path length of 256 characters on Windows. While the file path can be short enough in your source repository, it might exceed the maximum path length during build. Find attached a VI that extracts the longest path in a folder. Point it to the working directory of your project and see how long the longest path is. Find Longest Path.vi

To what end? NI will never go back to perpetual licenses, no matter how many offers we reject. Mainstream support for LabVIEW 2021 ends in August 2025, which means no driver support, no updates, and no bug fixes. By then you should have a long-term strategy and either pay for subscriptions or stop using LabVIEW. As a side note, if you own a perpetual license you can get up to 3 years of subscription for the price of your current SSP. This should give you enough time to figure out your long-term strategy and convince management Of course, if you let your SSP expire and are later forced to upgrade, than you have to pay the full price...

You cannot directly create PPLs from classes. Instead, put the class inside a project library to create a PPL.

Powered by LabVIEW NXG 😋

In C#/.NET, memory usage can fluctuate because of garbage collection. Objects that aren't used anymore can stay in memory until the garbage collector releases them. https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/ This could explain why your memory usage goes up and down. There is a way to invoke the garbage collector explicitly by calling GC.Collect(). This will cause the garbage collector to release unused objects.

Don't tell him about Excel...

No subscription = no money = no support I believe this is the case for most software products.

You need an active subscription to download previous versions. This has been the case for many years.