import shared library wizard does not work well with source control tools

[Southern_Cross]

Is there any way to get the Import Shared Library wizard to work well with source code control tools? Meaning, if I create a shared library with the wizard on one machine and then submit the library to source control there is no way for me to pull the source down on another machine and then edit/modify the existing library. I have to start all over from scratch. For libraries that have a large number of API functions this is a huge time loss. 

I noticed that the wizard creates some XML files in,

C:\Users\<myUser>\Documents\LabVIEW Data\Shared Library

but it is a union of information from all libraries created on that specific machine.

This seems like a poorly design tool with not thought into team development and software maintenance. 

If there is a work around please let me know.

Thanks.

[Kelle]

When you create the shared library, a DLL is created.  DLLs are not meant to make easy to see the source code.  This is pretty much the same for other langauges such as C.  Thus, regardless of if you use source control or not, you will not be able to easily pull out the source code from the DLL to edit it, because that is not what DLLs are meant for.  If you are working across multiple computers and/or using source control, commiting VIs and LabVIEW libraries will allow you to do more of what it sounds like you are trying to accomplish. 

You may want to look at this:  http://www.ni.com/tutorial/9648/en/ and http://www.ni.com/tutorial/4067/en/and http://www.ni.com/newsletter/51261/en/

and for team-based LabVIEW development:  http://www.ni.com/tutorial/11537/en/

[Southern_Cross]

Kelle,

Thanks for your response. There is some confusion here. I'm talking about the VI library the Import Wizard creates to wrap the shared library. After re-reading my original post I realized that I did not describe the problem very well. Sorry for the confusion.

So, what I'm trying to understand is, how to get the VIs created by the Import Wizard to work well with source control and a team development environment. The Wizard caches the configuration of the VIs that it creates to wrap the .dll/.so. The Wizard also lets one return and update the configuration and regenerate the VIs again, however, this must be done on the machine that the Wizard was originally used to generate the VIs in the first place. As far as I can tell, one cannot update an existing set of VIs that wrap a .dll/.so from another machine. This is the point that I was trying to make. I was not refering to the source code of the .dll/.so. I'm referring to the VIs created by the Wizard. 

For example, let's say I create the .dll/.so with a handful of functions exported. I then use the Wizard and generate all the wrapping VIs. I submit these VIs to source control. Another team member starts using the wrapping VIs in an application. After some time it is determined that a few more functions needs to be added and a few function's interfaces need to be modified. The .dll/.so source code is modified and the built producing the updated .dll/.so. However, I still have to modify all the VIs that wrap the modified existing functions and I have to create wrapping VIs for the new functions. This is the purpose of the Wizard! But, only the machine the created the VIs in the first place can update the "project" that configures the Wizard to modify them. This is the root of the problem that I'm trying to see if there is a solution for. This is a design flaw from my perspective. If the Wizard meta data was generated along side the generated VIs then that meta data could also be stored in source control. Then any machine and any team member could successfully update the wrapping VIs. 

This is not a big deal for .dll/.so that only have a small number of functions. However, I create .dll/.so that have a large number of functions, and while the Wizard provides a huge time savings, its still a significant amount of time to use the Wizard from scratch if I need to regenerate the wrapping VIs. Control & Indicator names needs to be modified, datatypes needs to be specified, Call Library Node configurations made, etc... It's still a significant amount of work to configure all of this for a .dll/.so that has a large number of exported functions. Not being able to reuse the existing configuration machine independent in a team setting is a loss of productivity.

[Kelle]

Oh, ok.  Thanks for the clarification.  Is there a way to edit with the wizard?  From my understanding, it seems like the wizard should create a lvlib of the functions that are pulled out of the dll.  And if we want to add to the lvlib, then we have to do so manually or we can just re-run the wizard and add whatever else that we need into it, and it is the same regardless of if we are on the same computer or not.  (Actually, can you post about how to edit with the wizard if that is possible on the same computer?  I am interested in learning about that.)  I understand the time sink involved if you are doing a lot of configuration and changes in the wizard, but wouldn't you have to make those changes either ways if the functions' parameters are changing in the new dll?

Sorry, I'm probably still a bit short of understanding everything that you are saying.  If it is possible to edit with the wizard on the creating computer but not another computer, then maybe post in the idea exchange?  It would be neat to be able to add more VIs from a dll more easily. 

[Southern_Cross]

---

@Kelle wrote:

Oh, ok.  Thanks for the clarification.  Is there a way to edit with the wizard?  From my understanding, it seems like the wizard should create a lvlib of the functions that are pulled out of the dll.  And if we want to add to the lvlib, then we have to do so manually or we can just re-run the wizard and add whatever else that we need into it, and it is the same regardless of if we are on the same computer or not.  (Actually, can you post about how to edit with the wizard if that is possible on the same computer?  I am interested in learning about that.)  I understand the time sink involved if you are doing a lot of configuration and changes in the wizard, but wouldn't you have to make those changes either ways if the functions' parameters are changing in the new dll?

Sorry, I'm probably still a bit short of understanding everything that you are saying.  If it is possible to edit with the wizard on the creating computer but not another computer, then maybe post in the idea exchange?  It would be neat to be able to add more VIs from a dll more easily. 

---

The following document does a good job showing how to use the import wizard: https://decibel.ni.com/content/docs/DOC-9078

But, it only mentioned the ability to update/edit an existing set of VIs that wrap the DLL. It's labled as UPDATE but in actuality you're regenerating all the VIs again. But, all the previous configuration information is reused. That's a great benefit of the wizard. For example, look at all the input that are frequently customized in step #11 in the link above. Now, do that for a bunch of functions... It's silly that one would have to redo all of that over and over again every time they need to update the library of VIs wrapping the DLL.

[Kelle]

Thanks for pointing out that document.  I looked into it as well as the Shared Library that you had mentioned in the initial post.  It looks like HeaderParserResult.xml is what populates the update list in the wizard and contains reference to all the DLLs that have been used on the wizard, but the actual settings for each project is stored in individual xml files named after the DLL.  I guess you could commit the HeaderParseResult xml, but the paths would have to be changed to match the local machine.  You could also commit the xml specific to the dll so that the settings are retained when using update in the wizard.  That's the workaround that comes to mind when working with the wizard between different users.