DLL Access and Storage

[Exergist]

As I continue to develop inline functions for VA the list of non-standard reference libraries (DLLs) will grow. This adds undesirable clutter to the VA root folder.

Would it be possible to modify the VA folder structure so that there is a "Libraries" (DLL) folder to house all of VA's required libraries as well as any additional libraries added by users for inline functions?

Better yet, would it be possible to have VA "search" through the root folder structure to find referenced DLLs? This would be very handy so that if a custom library is needed it could simply be included as part of a plugin (which would have its own folder inside of "Apps") to streamline installation and setup for users.

Thanks!!

[Pfeil]

It's a workaround, but you can use a relative path to point to a subfolder for your Referenced Assemblies(entered in the textbox at the top of the "Inline Function" window).

E.G. "/Libraries/MyLibrary.dll"

[Exergist]

Well guess I should have read the manual closer (around page 76):

Above the code editor is the, ‘Referenced Assemblies’ box. Within this box, you’ll see an initial set of common referenced assemblies that are separated by semicolons. You can add or remove assemblies from this list as you need them. Note that full paths to assemblies can be used, and that this box will accept tokens.

Unfortunately I seem to be having issues. I'm working on an inline function that uses the Interop.SpeechLib library. Everything works fine when the Interop.SpeechLib.dll file is in the root VA folder and the Reference Assembly also calls for Interop.SpeechLib.dll. However if I move the library to the location "C:\...\VoiceAttack\Apps\Recognition\" and change the reference assembly text to (no quotes) "C:\...\VoiceAttack\Apps\Recognition\Interop.SpeechLib.dll" the function will compile but if tested throws an exception:

Inline function execution exception: Exception has been thrown by the target of an invocation. Could not load file or assembly 'Interop.SpeechLib, Version=5.4.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

Reloading VA after changing the library location doesn't have an effect.

Any thoughts? Am I pointing to the subfolder incorrectly? @Gary could this be a bug?

[Pfeil]

Perhaps that issue stems from the compiler using the referenced dll to set up dynamic linking(as opposed to static linking, which would copy the contents of the dll into the compiled assembly), which means the assembly when executed will look for that file(one that reports the same properties, at least) in a number of locations, E.G. the directory it's executed from and the Windows directory(I believe).

So the compiler knows where to look for the dll, but the function within VoiceAttack that executes your assembly doesn't parse the "Referenced Assemblies" textbox for that location(And as such, doesn't pass it to the Windows component that handles this sort of thing down the line).


Though all of that is speculation on my part, I'm barely a novice programmer.

[Exergist]

Thanks for your feedback Pfeil.

Gary any thoughts?

[Gary]

I believe Pfeil is correct about the references need to be right where they are indicated for compile, but running will require the referenced dll to be visible to the caller.  You may be able to get around this by making your calls to the referenced dll by using reflection and loading the assembly at runtime instead of having a reference.  Otherwise, since the inline function runs in VA's space anything that is referenced needs to be immediately accessible by VA.

[Exergist]

So does that mean that the help manual is incorrect and libraries cannot be referenced as full paths?

Also does this mean that a separate Libraries folder or somehow having VA look for libraries in the Apps folder are totally out of the question?

[Gary]

Maybe I need to update the doc, but you can have a fully referenced path for compiling, but for running it's going to need to be where it can be seen by VA.  *UNLESS* you decide to go the reflection route and seek out the dll yourself, load and execute, or, put the dll in the GAC (not even sure if that would work since VA is signed).

[Exergist]

Hmm in this instance I may explore precompiling the inline function.

[Exergist]

So when I input the following as Referenced Assemblies my inline function compiles fine:

Code: [Select]

Microsoft.CSharp.dll; System.dll; System.Core.dll; System.Windows.Forms.dll; C:\Program Files (x86)\VoiceAttack\Apps\WSR\Libraries\Interop.SpeechLib.dll;
However when I try to do this same thing via a token I receive a compile error:

Code: [Select]

Microsoft.CSharp.dll; System.dll; System.Core.dll; System.Windows.Forms.dll; {EXP:'{VA_APPS}' + '\WSR\Libraries\Interop.SpeechLib.dll'};

Note that

Code: [Select]

{EXP:'{VA_APPS}' + '\WSR\Libraries\Interop.SpeechLib.dll'} produces the following in the VA event log:

C:\Program Files (x86)\VoiceAttack\Apps\WSR\Libraries\Interop.SpeechLib.dll

Any suggestions for making the Referenced Assemblies actually accept the token containing the library path? (which it should be able to do based on the documentation)

[Gary]

When compiling, the path to the referenced dll is valid and will work.

However, when running the application, the referenced dll must be accessible by VA.  Since the plugin/inline function is called by reflection, it can remain in a subfolder, but referenced assemblies must be, 'visible' to VA.  That means the dll must be in the same folder as VA, or in the GAC (if that's even possible, as VA is signed... can't remember all the rules).  That's just the way it works and, unfortunately, there's nothing that can be done about it.  If the documentation is misleading or wrong, it needs to be changed.   Sorry about that!

[Exergist]

Any suggestions for good primers to learn about implementing reflection? I've read a bit about it and it seems....complicated