G#
Making the "G# Dependency injection using default constructor" example work in built app.
Building an exe with the File/Directory Info works just the same way as in the development environment, as far as I can see. I just tested that. The class type is reported correctly and if the class file is not found, no dialog pops. The only problem I see is if a class resides inside the exe. What issue did you see Mattias?
What I can see is that with option 0x10, I will be prompted for any dependencies that are not found. Thats also a bit annoying. If I remove option 0x10, all is fine.
Guess its time to dig deep inte the supported LV-versions and the history of this function...
Hi again,
I've done some investigation regarding this flag in both LV2013 and previous version. I can't remember the exact reason for the 0x10 flag, but it must have been some LV2009 issue. My conclusion is the same as Xavier posted before, if just the 0x10 flag is removed and also the file/dir info, everything should work as expected. I do believe that flag 0x10 behaviour has been change to also include the reference class and not only its dependencies, which I guess was the original reason for the 0x10 flag.
The G#Object_GetClassType.vi should look like below. I will make this the new implementation in next G# version 1.6.3. I attach it (compiled in LV2009).
Thank you all for helping fixing this,
Mattias
Hi Mattias,
this bug was re-introduced in v1.7.0.4. You modified the vi to allow multiple "meanings" of the path (path to the directory, path to a vi of the class, path to the class and so on) and you are using again the "File/Directory Info"*(see screenshot attached) vi which doesn't work within the runtime environment.
Best regards
Andrea
I am probably the one to blame here 
. I made the change due to another bug. The added code you see in the new version was previously implemented and duplicated at at least two different places in G# (GenericCreate and GenericDefaultConstructor). There were also some differences there which made the implementation not behave the same for the two cases. For legacy reasons, the path definitions wer allowed to be defined in a few different ways, and that is why the path is tested four times in the loop. I am embarassed that I did not remember this thread when I fixed the other bug (although I hope this will teach the other programmer, lets call him Mattias, to comment his commits in the future). If I should guess, the two implementations both used the File/Directory info, which is why it mistakenly got introduced again.
As you can see in the comment, there could be cases where an incorrect class could be loaded. What we need to do is to find a way to solve both cases (not load incorrect class but still be able to find the class in the exe). I will see what I can do. Hopefully, Mattias will be as fast as always and come up with a solution. I would have liked to remove the support for specifying class-paths in several ways, but we have to be backwards-compatible.
Can you get your project working if you fix this VI locally, as a temporary workaround?
BR
Thomas
Looking at this now, It looks like what has happened here is that we have added functionality to "Get Class Type" that probably should not have been added here, but to a private method used by the methods that allow the path to be specified in several ways. There could be a valid reason for introducing this. I will look through my comments about this fix hopefully this weekend.
Also, this should have been caught in a regression test, which we don't have for this. I have not worked with the test suite for G#, but will discuss with Mattias to see if that could be added.
I tracked the changes on this VI some more. The path alternatives have been there since March 2014 and was added by Mattias. So I remembered incorrectly about that, I did not introduce that due to another bug. So that code really needs to stay. But the File/Directory info VI cannot stay.
However, as you can guess from the comment in the code, I have come upon cases where I expected to load class B but ended up loading class A, and even from a different place. That was very nasty. I don't like the path variations that are allowed, Mattias. Can you conjure up a solid solution?
Andrea, if possible, could you replace the "File/Directory Info" that you disabled VI with "Check if File or Folder Exists.vi" from the "File I/O">>"Adv File Funcs"-menu? That VI claims to work for runtime with files in the exe-file, as well as with packed libraries. If you do, please let me know if that works well for your case.
//Thomas
