TOPIC:

I have created a small demo of how to do a Winforms app with X# against .Net core.
This shows that the compiler is ready for it !

Very nice Robert! I'm glad to see you diving into .Net Core like this and showing us some of the internals that are involved.

Hi Robert,

Thanks for sharing this video.... Gonna watch this.

Regards,

Rene

Hi Robert,

Done watching. This is great. X# indeed can ride now to DNC bandwagon and with .NET 5 on 2020....

Anyway, I will re-join FOX this June and look forward moving my "huge" VO apps completely to X# and its native runtime, no Vn dependencies whatsoever. Anyway, so much time left till September release of .NET Core 3. I want to work on single base class libs for our "Windows Desktop Apps" as well as for my our mobile and web apps; and starts on PostgreSQL version of our apps. I have open look on what to do next: either a full conversion to X# with ADS or full re-write with X# but with base class libs copy pasted code from VO and new Postgres database. I will decide on this by October 2019. Beside, I am still very busy with new apps in VO. They have said, VO is dead, yeah, Long Live VO.

Anyway, I also interested on taking a look at Phil's DBF to Postgres code. But the way I look at this, it should be always a re-write for DBF/RDD moving to ADO.NET and EF. IMHO re-write is way move forward.

Regards,

Rene

Hi Robert,
thank you very much for this video! It was very interesting and I look forward to the .NET Core support for X# in Visual Studio!
Wolfgang

Robert,

I always seem to learn something new from you.

Quick question, how do you see .Net Core fitting into our future?

Re. Net Core, as I understand it the standard Net Framework will end with about v4.8, then it will stop and MS will only develop Net Core. This is why the version jumps from Net Core 3 in September to Net Core 5 in 2020, as it will be taking over where Framework 4.7 or 4.8 leaves off.

HTH

NIck

Nick,
That's right.
For me the most important part of this is that .Net will no longer be part of the OS, but will be distributed with the apps. So you can use features of newer versions of .Net without having to update all of your servers and workstations in a network.

Robert

Further to what Robert said, I think for me based on the MicroSoft announcement is that it is a joint project between the .NET, Xamarin and Mono teams with a great emphasis on running seamlessly on iOS, Linux, Windows and Android.

A good read on the .NET Core application deployment options: docs.microsoft.com/en-us/dotnet/core/deploying/index

In brief, you can create three types of deployments for .NET Core applications:

1. Framework-dependent deployments (FDD)
2. Self-contained deployments (SCD)
3. Framework-dependent executables (FDE))

Framework-dependent deployment. As the name implies, framework-dependent deployment (FDD) relies on the presence of a shared system-wide version of .NET Core on the target system. Because .NET Core is already present, your app is also portable between installations of .NET Core. Your app contains only its own code and any third-party dependencies that are outside of the .NET Core libraries. FDDs contain .dll files that can be launched by using the dotnet utility from the command line. For example, dotnet app.dll runs an application named app.

Self-contained deployment. Unlike FDD, a self-contained deployment (SCD) doesn't rely on the presence of shared components on the target system. All components, including both the .NET Core libraries and the .NET Core runtime, are included with the application and are isolated from other .NET Core applications. SCDs include an executable (such as app.exe on Windows platforms for an application named app), which is a renamed version of the platform-specific .NET Core host, and a .dll file (such as app.dll), which is the actual application.

Framework-dependent executables. Produces an executable that runs on a target platform. Similar to FDDs, framework-dependent executables (FDE) are platform-specific and aren't self-contained. These deployments still rely on the presence of a shared system-wide version of .NET Core to run. Unlike an SCD, your app only contains your code and any third-party dependencies that are outside of the .NET Core libraries. FDEs produce an executable that runs on the target platform.