TOPIC:

Believe it or not, for as long as I've worked with VO, and now X#, I've never had any occasion to open a DLL within a VO application. In connection with a more simplified web-based application, a friend suggested that I separate code for one application into two parts: the code for the UI, and the program logic. That's a good idea, because it provides me just one place where I can develop and debug for both the local and web-based apps, and for as big as it is, helps immensely with organization. So I copied code for the latter to specifically create the DLL.

The problem is that I don't know how to open or access the DLL at the start of runtime. I looked around the forum for a clue, but didn't find it. When I looked through my old VO Help file, it advised me to look through the Programmer's Guide, which I no longer have.

Hi Thomas,
if you build a DLL in VO, the compiler builds an AEF file, and you can import that in your VO repository and add it in the libraries of your application.
Wolfgang

Hi Thomas,
IMHO using a DLL in VO is relatively inefficient because (specially on large DLLs with many classes) it uses more memory at runtime, needs more time to start and may impose some reorganziations. For example, you cannot add the same library to both your DLL and the calling executable.
In X# the game changes completely, there DLLs are the way to go.
Wolfgang

I understand. I don't intend to use the DLL in the VO application, nor in its X# counterpart, but rather a web-based application that uses the program logic. Separating the code between the modules responsible for the UI and the program logic was to build a web-based application to translate single sentences in English into Spanish. The main application does that already, but the web-based application would have just two textboxes, one for user to enter the English sentence, and the other to display the Spanish translation, and use the program logic in the DLL.

One other issue that you may be able to clear up for me: depending on the nature of the English sentence, the local application may pause processing and request additional user input to complete the analysis. This it does by constructing and displaying various dialog windows for the user to enter. But if a web-based application uses a DLL that has no libraries to construct and display those windows in those cases (and that's merely assuming that GUI Classes library couldn't be included in a DLL to display in a web-based application), no additional user input can be provided and analysis can't continue. An IT friend suggested that I treat those cases as errors, but that will just produce the same result. For those particular sentences, it simply wouldn't work. It's somewhat analogous to needing to ask a question but having no vocal cords. Would there be some way to overcome that obstacle?

Hi Thomas,
I must admit I have never used VO DLLs in a non-VO application (with one exception: sometimes in the past Robert has given me a VO DLL to be used in X#, but that is already in the family).
When using a VO application in a non VO application you must make sure that the VO runtime is also correctly loaded and initialized. When the host application is a VO application, that is done correctly, but for non VO applications that must be done manually.
What is the language your VO DLL should be used with?
If it is a .NET application, then I would use X# to build the DLL, and then it can be used directly in the C#/VB.NET application.
You know that you can share source code also between X# and VO?
Wolfgang

The VO DLL will be used in a web application written in Python, using Flask to build the UI. I'll copy the code used in the DLL to a separate project in X# and build it that way, though would there be a difference in the DLL whether VO or X# is used to build it? And yeah, I know that source code can be shared between VO and X#.

Thomas,
If you create the DLL with VO then you need to access it using the .Net "PInvoke" mechanism. I am not familiar with Flask, but if would be the same as when you were accessing something from User32 or Kernel32. Make sure you only use standard Win32 datatypes for the parameters (so no Date, String, Float etc).

If you create the DLL with X# then it becomes a normal .Net assembly. Functions will become part of a compiler generated functions class. But it is probably easier to create static methods in a static class yourself, since that gives you full control over the class name. If flask is also based on .Net then you can use all .Net datatypes. You can also use X# specific datatypes (such as Date, Float, Usual etc) but you have to be aware then that these datatypes are implemented as special structures or classes with names such as XSharp.__Date and XSharp.__Usual.

Robert

I'll go over what your reply in more detail. In the meantime, something strange has happened. I used VOXPorter to convert the AEF comprising the DLL with the default options and it produced an *.sln and *viproj files. Neither of those is of a file type *.xiapp or *.viapp from which to import to X#. I'm certain that I did the same for my main application and had no problem. I don't understand what happened to change the file type.

Hi Thomas,
in the VOXPorter you need to check also the "XIDE" or the "both" option, but in your case, as you don't use Visual Studio, "XIDE" may be better:

Wolfgang
P.S. about integrating foreign DLLs in Python code, I found this link:
stackoverflow.com/questions/252417/how-c...dll-file-from-python

Hi Thomas,

ThomasWYale wrote: I'll go over what your reply in more detail. In the meantime, something strange has happened. I used VOXPorter to convert the AEF comprising the DLL with the default options and it produced an *.sln and *viproj files. Neither of those is of a file type *.xiapp or *.viapp from which to import to X#. I'm certain that I did the same for my main application and had no problem. I don't understand what happened to change the file type.

The .sln file is used for VS, you just double click on it and it will open the ported app in VS. Same for the .viproj file for XIDE, you can double click on it, select XIDE as the default app to open this file type and it will open in XIDE. The .xiapp/.viapp files are only needed in order to add the ported app inside an already existing project of XIDE, and those can be found inside the directory of each ported app/library.

.

Hi Thomas,

ThomasWYale wrote: The VO DLL will be used in a web application written in Python, using Flask to build the UI. I'll copy the code used in the DLL to a separate project in X# and build it that way, though would there be a difference in the DLL whether VO or X# is used to build it? And yeah, I know that source code can be shared between VO and X#.

maybe this is not exactly what you were looking for, but ....
If you move your VO DLL to X#, then you can "easily" use it from Python.
I suggest you have a look at pythonnet.github.io/; which allows you to use .NET code directly from Python.... and X# is pure .NET code..

HTH,
Fab

I've been struggling for a month and a friend and I have resolved a lot of configuration issues in VS for this web application. The DLL has been generated from an X# project with x86 platform option chosen in the properties.

The only issue (so far) that remains is that when I try to call the function processSentenceWeb(), which is the point of entry, within the web app, an error message appears, "Exception thrown, function 'processSentenceWeb' not found." Using DUMPBIN with the /exports option reveals no exported endpoints.

This is despite that according to X# documentation, transported code is global, since VO has no concept of namespaces, so shouldn't everything in the DLL be visible once it's accessed by any application? A simulated application, in which a form using VOGUI resources in a dialog uses the DLL, accesses the same function and works fine.

Hi Thomas,
regarding namespaces: from inside the application, a X# application may not use use namespaces, but since it is a real .NET DLL, it is using namespaces.
And I don't think an X# DLL can be used as any VO DLL because there is a difference: a VO DLL can export a C style interface whereas a X# DLL cannot.
You should be able to use your X# DLL in Flask like a C# DLL:
stackoverflow.com/questions/7367976/call...-library-from-python
Unfortunately, I have played a bit with "Unmanaged Exports" tool by Robert Giesecke and was not able to make it run, even with C# and Visual Studio.
Maybe someone like Robert or Chris may help you with the unmanaged exports - maybe you can offer Robert v.d. Hulst to pay him the the time he need to solve that.
It is written in German, but it is the same issue: www.xsharp.eu/forum/german/2673-gma-qrco...g-dll?start=40#22118
Wolfgang

Guys,
It is possible to export types in an X# assembly without namespace. These types are considered to be part of a "global" namespace.
Functions and globals are always compiled as members of a compiler generated static class Functions.
For X# core assemblies this class is part of the global namespace. For other dialects the class is placed inside a namespace that is derived from the name of the assembly. FOr example: Foo.Dll has a functions class with a name Foo.Functions and for Foo.exe the name becomes Foo.Exe.Functions.

Robert

Hi Robert,
thank you very much!
But what I was able to understand: Thomas needs a C like interface, and the X# compiler does not creates that - maybe it could be an option in the X# compiler to do that. It is something the C# compiler cannot do - and it would be an unique feature for a .NET compiler.
It needs two steps: the Unmanaged Exports DLL by Robert Giesecke that adds a new attribute and a post build operation that uses ILDasm and ILAsm to add these export definitions.
Wolfgang

Wolfgang,
I have never looked at this. So I have no idea how this works.

Robert

Franz's last message that he implemented all 3 examples to show code in his test app seems to imply that he was able to access the DLL. I've attempted to install it with directions from here, though it's from 9 years ago.

stackoverflow.com/questions/10240029/how...e-nupkg-file-locally

The Package Manager as shown here no longer exists in VS Community Edition, but I did open the pane for Package Manager Console and looked up how to enter expressions to install Giesecke's nupkg file. (Screenshot.jpg) It's the correct syntax as far as I can see, but there is no project Default. I didn't understand that error. I searched elsewhere and found this more recent article from 2022.

docs.microsoft.com/en-us/nuget/quickstar...age-in-visual-studio

I right-clicked References for the project in the Solutions Explorer but the option "Manage NuGet Packages..." is disabled. (Screenshot2.jpg) This is maddening. Do you know of any other ways to get it installed?

Hello Thomas,

There are many articles about greyed out NuGet options. Basically there are dozens of solutions, because it's VS = Microsoft and then it probably won't work for random reasons. Like clean the solution, restarting, not working in debug mode. making sure the project is saved, etc.
We were recently unable to remove a NuGet reference from a project. We solved that by removing the xml reference from the .packagefiles and from the X# project file.

Because of all these problems, I stopped installing NuGet files. A NuGet package is just a zip file. Rename it, put the DLL's from your zip in your project directory and add the references. Ready without the whole bunch of issues Microsoft has reserved for you when using NuGet.

Dick

Hi Thomas,
using Visual Studio 2019 I was able to install the extension, but was not able to make it work because it is designed to work only on .NET 2.0 executables.
For never .NET executables you have to use another tool, but even investing a few hours of work I was not able to make it work on a C# DLL.
Normally, when I have to try something like this, I try first with Visual Studio and C#, then move it over to X# in Visual Studio and then to X# on XIDE.
But in this case you will need the help from someone other, maybe "our" Robert here.
Wolfgang