Making the "G# Dependency injection using default constructor" example work in built app.

[lsi]

To be more specific I just tested my specific problem, i.e. that the "Check if File or Folder Exists.vi" would find the class at first try (according to your logic) in the .exe. All the other parts of the logic, namely those depending on the specific error codes, are untested. So probably you should check if this VI gives the same error codes in the same situations.

Cheers

Andrea

[lsi]

Hi all,

given a possible new release of the library I am coming back to the issue. I am always puzzled as to how it is working LabVIEW with compiled code! While in my original answer I stated that "Check if File or Folder Exists.vi"  VI works within an executable, I have to say that now I observe that this is not the case at least in LV2017. As a result every time I install G# I have to edit G#Object_GetClassType.vi method to make the dependency injection work within an executable.

Would it be possible that you find a solution to this for the next release? I would be grateful!

Best regards

Andrea

[thols]

Am I correct in assuming that the change you make is to replace the "File/Directory Info" with "Check if File or Folder Exists.vi"? 

(I am not on a PC with LabVIEW now so I cannot check what it looks like today, but I don't think that change was made, but I see no reason it shouldn't be changed)

[lsi]

Sorry I was definitely not clear about the modification I do. I basically disable the check altogether as the attached picture illustrates

I know this disables some functionality but it makes the dependency injection work.

Just for clarity the current implementation you deliver uses "Check if File or Folder Exists.vi", which as said doesn't seem to work within an executable. As far as I can remember the "Check if File or Folder Exists.vi" replaced the "File/Directory Info" which as well was found not to work within executables.

I hope I was a bit clearer about the issue.

To verify the malfunctioning it is sufficient to build an executable out the dependency injection example you ship with the library

Best regards

Andrea

[Mattias_Ericsson]

Hi,

Yes, got the same problem. Your modification is basically the same solution that was until the 1.6.1 release and it work there. I am not really sure why we put in that check there, I will investigate a bit more and probably remove it until the next release.

Mattias Ericsson

ADDQ

[thols]

The reason for the check being there is stated on the comment in the BD. If the class file is not found, LV will search for it and can find another class with the same filename and use that, causing really nasty bugs. One could even load a class with the same name but from another namespace.

The x20 option states that it will search for missing dependencies but it will search for the class as well and there is no way I know of to prevent that. I believe that behavior was changed in LV2013, and before it just threw an error.

What makes things even worse is that the code allows for some differences in path definition, it can even lead to another class being loaded from another path (mentioned in another note on the BD). That has happened to me and it was not easy to track down. Lets say you have a class A in folder B. The class named B can suddenly be loaded instead. The code that allows for specifying class path in different ways should never have been let into the code. Any code depending on such functionality should manage such things, it should not be in G#. I urge to remove that code completely. If that breaks code that uses G# than so be it, it is simple to spot and correct and much better than keeping this bug-inducing code.

So if the check shall be removed, the extra code allowing different path specifications has to be removed too.

The file check could be conditionally disabled so it is not run for exe:s but I suggest instead to implement in this VI to check the class path after loading and verify that it matches the specified path. I have attached my suggestion. I tested with one class and it seems to work as expected as it detects if the class was not loaded from the specified path. The code is neat, which usually means it is good 🙂

[lsi]

The code looks good to me. I didn't try to see if there is any problem within an exe, but this looks very unlikely.

Cheers

Andrea

[Mattias_Ericsson]

Hi,

We need to consider the backward compability also. We definitly need to support just specifying the folder path, I do believe that is one of the most common path. I do suggest to just add a simple check to the path whether it is an exepath or not. See attached VI. This works with both examples when building the exe. Backward compability will still be intact.

However, I do believe putting the class to inject inside the exe is difficult, since it is hard to know the actual path inside the exe. In the example, we read out the path and then use it to inject, which is not the way you would normally use dependency injection in reality.

Mattias

[lsi]

Dear Mattias,

concerning the last point, what I normally do in architectures where I have abstract classes is that of creating a small VI that generates the relative paths of the concrete classes with respect to the abstract class and store them flattening to XML. Then at run-time I  get the path of the abstract class then I unflatten the relative paths and construct the absolute paths within the exe. In this manner I am always able to have the paths of the concrete classes within the exe.

When G# will be available packaged in a project library so that I can distribute my code in a packed library I will have to think about another method 😉

Cheers and looking forward to the next release

Andrea

[thols]

I see three things that needs to be considered:

* Make it work when path is inside an exe
* Check/verify that the loaded class path is at the expected path
* Backwards compatibility

The second point was not needed pre-LV2013 since an error occured if the path was incorrect, but now it is needed. This needs to work regardless of the file being inside an exe or not. If it does not, the code is not backwards-compatible, and in a much worse way than allowing different path variations. OK, this has never worked correctly post-LV2013 for files in exe's and since almost no-one packs their classes to inject inside the exe (It seems contradictory) it has never needed to be fixed, but what started in 2013 was the risk of classes being called from the wrong location. The code allowing for different path specs did not consider the post-LV2013 behaviour and has not since been backwards compatible. I would argue that it is much more important to have the backwards-compatibility of knowing that the class has been loaded from where it is specified to be rather than to let the user specify a path in different ways (which was a feature that was not initially there).

Yes, compatibility needs to be considered, but not at the expense of keeping code that can produce bugs. Calling code that uses the path-variations would not work anymore which is good, because then the user can easily see what needs to be fixed. And I'm sure that the user will happily fix their paths when they learn that that means that they will be safe from producing nasty bugs.

Another downside of allowing different path formats is that if we do not check that the path exists and send that path to the Get LV Class Default Value is that it takes time to let LabVIEW search for the class. Depending on the search specs, it can take a long time. This is another incompatibility and it would all go away if we did not allow path variations.

Andrea, you can pack G# as a lvlibp, there is an empty G#.lvlib just next to the G#Object.lvclass and a text file with instruction how to add it to the lvlib (also discussed here). It would be nice to have lvlibp in the installer, but VIPM does not support it. One possibility would be to post the lvlibp on github. I have a LV2019-version but I have not verified it so I'm not sure if I should upload it there, or should I?