Error 1357 while saving OOP-based toolkit's overridden methods

[kosist]

I've faced this issue while building our internal toolkit, and now it was possible to replicate it with dummy project.

There is Tree toolkit which is unpublished in VIPM repository, but it is possible to download and install it from NI forum. I've created project which includes VI from examples for this toolkit just. As it is unpublished, I was trying to add it as internal dependency - so from Package Build configuration first scanned the project for dependencies, then this toolkit was added there, and then I've removed it manually.

But following error occurred during the build (on the screenshot). It could not copy and save method "To Variant.vi", because VI with the same name already existed in the target folder/memory. 

That method is dynamic dispatch method, which is overridden in multiple classes (on the screenshot).

Is there a way to configure build somehow so VIs will be moved to subfolders to avoid name collisions (something similar as LabVIEW build has - that in case of "Always Include" classes it moves VIs with the same name to separate subfolders), or some additional prefix will be applied to its name? Or, root cause of this error is something else?

In our case, in order to be able to build the toolkit, we had to remove Tree toolkit from dependencies, and implement functionality which we needed as custom library. We couldn't distribute VIPC with our toolkit, so that's why we wanted to keep all dependencies ether as internal (for toolkits which are not published) or let VIPM install them during installation of our toolkit (for toolkits which are published and available in public VIPM repositories). But that was just a workaround... 

Thank you very much,

Sincerely, Ivan.

[Jim Kring]

Hi Ivan,

You're right: Error 1357 during a package build generally occurs when two VIs of the same filename (but in different lvclass'es or lvlib's) are targeted into the same folder during the build.

Fortunately, if the classes/libs (with the same-named method VIs) are stored underneath your VI Package's source folder then you can create a custom destination folder for each of them (and target each lvclass/lvlib with it's own specific destination folder).

So, maybe you could move the Tree API into your project source folder.  Then, you can have more subtle control over choosing specific destinations for each of its classes.  I see that the Tree API is distributed as both a VIP and a ZIP file. Maybe you could just extract the zip into your project folder.  Also, you might want to rename the root level Tree API.lvlib to something like "TREE API__MYPROJECT.lvlib" so that there will not be a name collision if the packaged version of the Tree API is also installed.

Also, I see that there's a newer Tree Map library which *is* published in VIPM. I'm not sure what it would take (or whether it's possible) to upgrade from the Tree API to the Tree Map -- I haven't used either of those libraries yet. Yet, maybe that's another option.

Note: this approach with custom destinations will not work for internalized package dependencies, since package dependencies are installed underneath the LabVIEW folder and only files saved under the project source folder are shown in the source file settings view in the VI package builder.  Said differently: files located under the <LabVIEW> folder cannot be targeted to a custom destination -- it only works for files stored under the VI Package's source folder. The solution then, is to move those dependencies into the project source folder, as described above.

Hope one of those possibilities works for you and thanks for the feedback. You're right that it would be great if there was VI name collision detection in the package builder and it could save the colliding files into different folders automatically.

[Jim Kring]

Hi again, Ivan.

I went ahead and created a new Knowledge Base entry for this issue, since many others have experienced this error message:

Error 1357 during a package build (File Already Exists)

Let me know if that makes sense and/or if I missed anything (other possible workarounds or made any misstatements in the recommended workarounds).

[kosist]

Thank you @Jim Kring for the KB and for the suggested workarounds.

We were considering the option of adding toolkit directly to source, but then decided simply to get rid of it completely since we've used it just as simple DVR-based lookup table. Moving to Tree Map was not possible, because it supports LabVIEW 2019 and later, but our project is done in LabVIEW 2015...

[Jim Kring]

OK, glad you found a work around (sort of). Sorry that VI Package builder couldn't handle that automatically.