xsharp.eu

Terry,

Not sure what to make of your reply but thanks anyway. Unfortunately I can only do one thing at a time, so everything initially is going to be about proof of concept. I need to establish first how easy, or complex, it is to generate binaries that I can run. What the dependencies are and what the issues with dependencies may involve, and then move forward from there.

(The great thing about XHarbour apps are that you could literally drop the EXE and it's DLL's onto a new PC, specify a path setting via an .INI and the app would talk to the file server and run. Which is great if you've got a site with 50 stations. I suppose the downside is that because the app existed in virtually its own "eco-system" getting it to talk to the rest of the eco-system in more sophisticated ways always turned out to be a PIA, requiring C++ coding.)

As for the big picture stuff, I'm fine with that. I'm good at that as I've been engineering systems for 35+ years, so I've pretty much made all the mistakes that could be made, including having awareness of the more subtle ones. The devil for me with all this is going to be in the technical details.

Hi Will,
about "drop in a folder and run" is not only true for XHarbour, but also for VO and X# applications.
A development tool that requires applications have to be installed would be no choice for me (in fact, most of my applications are running directly from a shared folder, without any local files).
With .NET you can even connect to most SQL servers without any local installation and configuration.
Wolfgang

Hi Will

My reply was basically stating what you already know - that you can quite legitimately draw an analogy with real-life to gain the big picture, so at least you know what your code is aiming to do.

So in that respect it will not have helped very much.

But the whole computing eco-system is evolving, both hardware and software. The best we can do is try and get some appreciation of what is happening.

You say "I need to establish first how easy, or complex, it is to generate binaries that I can run. What the dependencies are and what the issues with dependencies may involve, and then move forward from there".

I question this approach.

Here, as in any .Net based environment you will have already moved onto a path which has simplified much of the underlying complexity of generating binaries that you can run. So, I would say, just follow it.

MS has made this a fairly easy path to follow using Visual Studio. (There is a learning curve associated with optimising, or tailoring VS to your way of doing things). But using Net 6 as a basis for desktop apps is probably best approach.

.Net is most certainly not targetted at high-performance.

It is your coding that will determine performance.

You go on to comment on C++. This is certainly the way things are going for high performance computing. C++ may well be a PIA but there is no real alternative. You'd have to learn it.


This goes hand-in-glove with "parallel programming think" using hyper threading and GPUs.

Best regards

Terry

Wolfgang,

about "drop in a folder and run" is not only true for XHarbour, but also for VO and X# applications.

That sounds very encouraging, but surely you have to at least install the .NET framework the app is built around or is that an invalid assumption?

in fact, most of my applications are running directly from a shared folder, without any local files).

I would consider that a basis (core) requirement, so that's great.

With .NET you can even connect to most SQL servers without any local installation and configuration.

I don't suppose you know if that would include PostgreSQL ?

Terry,

Given how fast modern CPU's are and also I'm expecting X# to run faster than XHarbour as code can be closer to 'native' than p-code, and on top of the fact that I'm writing business code, performance in that regard is of no concern to me. All the bottlenecks are going to come down to data access...

Hello Will,

To quickly reply your last questions: .Net Framework is part of Windows and updates with Windows. It does not require specific installation. The only thing you have to decide is which version you are going to support/use in your application properties. Basically there you have 2 supported options: the .Net Framework or .Net6. The latter is a kind of .Net rewrite supposed to replace the previous .Net Core and Framework. There are some speed and option advantages above the framework and if I am not mistaken it will be supported in the next number update of X# (3.x). However, the EOL support of these "newer" .Net versions is limited, every second version 3 years and the others 1,5 year. E.g. .Net6 released in Nov 21 is supported until Nov 24 but .Net7 expected next november is supported until May 24 only.

The last .Net Framework version is 4.8.1 (Aug 2022) and will be kept supported with Windows. Targeting a lower .Net version may be required when you use an older DLL which does not support a newer version. If that is not a consideration, targeting 4.8 you can expect the latest additions to be available. E.g. 4.8 added support for some cryptography classes which yielded an exception in earlier versions. As 4.8 was released in 2019 you can expect all Windows computers to have it. To be on the very safe side choose anything from 4.6.2 (Aug 2016). Note that I did not recommend 4.8.1 which e.g. does e.g. not support earlier Windows Server versions than 2022 and is not recommended by Microsoft (https://dotnet.microsoft.com/en-us/down ... -framework).

So in short: target your application (in the Properties) to anything between .Net Framework 4.6.2. and 4.8 if you want a long support and the best chance that all users will have it installed and you will be able to have your X# programming up and running by just copying your exe and the included DLL's (like those from the X# Redist directory). Like you did in Harbour.

Regarding your PostgreSQL: I don't use it myself but I understand it is used by quite a few X# programmers. Just search on it to see some messages. Johan Nel was written some interesting info about PostgreSQL.

Dick

Hi Will,
about the xcopy installation: with .NET you can do that for the client. That means that you don't need any configuration on the client PC to connect to the PostgreSQL server other than passing the correct parameters when you open the connection.
The server needs to be installed on a server machine (AFAIK there is also a manual installation procedure for the PostgreSQL server, but the start of the server process needs to be configured on the server machine, and also an eventual firewall exception rule).
The same is true also for the backup procedure - every SQL server needs also its backup procedure - a file copy alone normally is not enough.
The possibility to use .NET code to connect to various SQL servers without any local client configuration has also led me to implement COM modules in X# to be used from my VO applications for SQLite, MS SQL Server and PostgreSQL servers.
Wolfgang

Hello All

I can't help noticing that this tread has become ridiculously long, and question whether we are making best use of this forum.

As a Welcome thread it should be just that. Looking back through it it has becomme a multi-topic thread.

I have to agree with Robert, Chris and others who don't want to see Dick turn it into a VS bashing thread.

I quite agree with Dick who feels that his views on the shortcomings of VS should be communicated to newcomers here.

But the answer surely is to open new threads for topics as appropriate.

Hi Terry,

It's been more than ten days since the topic of "shortcomings of VS" has appeared in this thread, until you mentioned it again just now

.