Re: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 installed - Possible?
Isn't it nice to be out of DLL Hell and into .Net Runtime Purgatory? On Tue, Jul 28, 2020 at 5:01 PM Tracy Pearson wrote: > Thank you Richard, and Rick. > > I will consult with my team on the path we may take in the future. > > Tracy > > > -Original Message- > From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Richard Kaye > Sent: Tuesday, July 28, 2020 5:21 PM > To: profox@leafe.com > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > installed - Possible? > > As I thought might happen, Rick posted an answer. Here it is: > > If you're shipping a vertical application your best bet is to bundle the > runtimes with the application. .NET Core supports building the application > in framework independent mode which includes all the runtime files required > to run the application as part of the build output. IOW, you build a fully > self-contained application that has no runtime dependencies on a .NET Core > Framework. In your case I think this would make sense because the target > machines are unlikely to have a pre-installed runtime of any kind and it > side-steps the potential version mismatches. Doing this will make the > distribution much larger though - a full runtime installation adds roughly > 80-90megs to the application (about 30-35megs in an installer package). > > The other option is to rely on specific runtime versions being available. > .NET Core rolls forward to higher point releases, but only up to the next > point release. (ie. 3.1 and 3.2 are considered different but a 3.11 app can > run on 3.15 but a 3.15 app can't run on 3.11). > > In the situation with churches it's unlikely that pre-existing versions of > .NET Core exist, so distributing self-contained is the way to go I think. > > Or if that's all too much hassle - don't use .NET Core but use (full) .NET > Framework instead, since that will pre-exist on any Windows machine Windows > 7 and forward and just work. This is one of the main reasons why I'm > sticking with full framework for the time being for any desktop, non-server > application development. > > +++ Rick --- > > -- > > rk > > -Original Message- > From: ProfoxTech On Behalf Of Richard Kaye > Sent: Tuesday, July 28, 2020 2:55 PM > To: profoxt...@leafe.com > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > installed - Possible? > > I thought about cross-posting it for you, Tracy. I'll act as your agent in > this matter for my usual 20% commission. 😉 > > -- > > rk > > -Original Message- > From: ProfoxTech On Behalf Of Tracy Pearson > Sent: Tuesday, July 28, 2020 2:39 PM > To: profoxt...@leafe.com > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > installed - Possible? > > Well, the required version is 3.1.4. Yet it compiled requiring 3.1.6 > because that is the most recent 3.1.X installed. > So the downgrade you might be thinking of is going to 3.0 which is no > longer supported. > Or 2.1 which doesn't have access to some of the features I'm using in C# 8. > > > -Original Message- > From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Stephen > Russell > Sent: Tuesday, July 28, 2020 2:26 PM > To: ProFox Email List > Subject: Re: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > installed - Possible? > > You can downgrade the version of core required in the project. Either > way, you have to supply that in your installer. Your clients probably > won't have it on thier machines. I'd consider using the M$ one because it > will bring in the correct bootstraping you'll need. > > I only do web installs and not systems that use a forms based UI. > > > > On Tue, Jul 28, 2020 at 12:11 PM Tracy Pearson > wrote: > > > My searches on the internet are fetching a bunch of build .NET Core > > 2.1 with .NET Core 3.0 installed. > > I'm in the later stages of getting a product ready for release and the > test > > machines and build machines are still on 3.1.5. > > > > When I want to do a quick build from my system which was installed at > > 3.1.6, it refuses to run on the test machines. I get this: > > It was not possible to find any compatible framework version The > > framework 'Microsoft.AspNetCore.App', version '3.1.6' was not found. > > > > I tried dotnet build -f netcoreapp3.1.5 and got this: > > C:\Program > > > > > > Files\dotnet\sdk\3.1.302\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Target > > FrameworkInference.targets(127,5): error NETSDK1045: The current .NET > > SDK does not support targeting .NET Core 3.1.5. Either target .NET > > Core 3.1 > or > > lower, or use a version of the .NET SDK that supports .NET Core 3.1.5. > > [c:\work\pcservice\PcService12\PcService12.csproj] > > > > I distribute software to churches. I don't expect them to have a > > dedicated IT group. > > My concern is what happens when the SDK on the build machine moves > > from > > 3.1.5 to 3.1.6 due to an update from Microsoft. > > If I have already shipped the product and have it
Re: ADMIN: Archives seem uncooperative
On Jul 28, 2020, at 19:20, Ted Roche wrote: > > No rush. Archival blog posts aren't going anywhere. Glad you found the > problem. As always, thanks for the hosting! Looks like a corrupted index. Should be fine now. -- Ed Leafe ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/771b4d2d-0bec-41ee-bff3-fd54a5b72...@leafe.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 installed - Possible?
Rofl Op wo 29 jul. 2020 15:30 schreef Eric Selje : > Isn't it nice to be out of DLL Hell and into .Net Runtime Purgatory? > > > > On Tue, Jul 28, 2020 at 5:01 PM Tracy Pearson > wrote: > > > Thank you Richard, and Rick. > > > > I will consult with my team on the path we may take in the future. > > > > Tracy > > > > > > -Original Message- > > From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Richard Kaye > > Sent: Tuesday, July 28, 2020 5:21 PM > > To: profox@leafe.com > > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > > installed - Possible? > > > > As I thought might happen, Rick posted an answer. Here it is: > > > > If you're shipping a vertical application your best bet is to bundle the > > runtimes with the application. .NET Core supports building the > application > > in framework independent mode which includes all the runtime files > required > > to run the application as part of the build output. IOW, you build a > fully > > self-contained application that has no runtime dependencies on a .NET > Core > > Framework. In your case I think this would make sense because the target > > machines are unlikely to have a pre-installed runtime of any kind and it > > side-steps the potential version mismatches. Doing this will make the > > distribution much larger though - a full runtime installation adds > roughly > > 80-90megs to the application (about 30-35megs in an installer package). > > > > The other option is to rely on specific runtime versions being available. > > .NET Core rolls forward to higher point releases, but only up to the next > > point release. (ie. 3.1 and 3.2 are considered different but a 3.11 app > can > > run on 3.15 but a 3.15 app can't run on 3.11). > > > > In the situation with churches it's unlikely that pre-existing versions > of > > .NET Core exist, so distributing self-contained is the way to go I think. > > > > Or if that's all too much hassle - don't use .NET Core but use (full) > .NET > > Framework instead, since that will pre-exist on any Windows machine > Windows > > 7 and forward and just work. This is one of the main reasons why I'm > > sticking with full framework for the time being for any desktop, > non-server > > application development. > > > > +++ Rick --- > > > > -- > > > > rk > > > > -Original Message- > > From: ProfoxTech On Behalf Of Richard > Kaye > > Sent: Tuesday, July 28, 2020 2:55 PM > > To: profoxt...@leafe.com > > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > > installed - Possible? > > > > I thought about cross-posting it for you, Tracy. I'll act as your agent > in > > this matter for my usual 20% commission. 😉 > > > > -- > > > > rk > > > > -Original Message- > > From: ProfoxTech On Behalf Of Tracy > Pearson > > Sent: Tuesday, July 28, 2020 2:39 PM > > To: profoxt...@leafe.com > > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > > installed - Possible? > > > > Well, the required version is 3.1.4. Yet it compiled requiring 3.1.6 > > because that is the most recent 3.1.X installed. > > So the downgrade you might be thinking of is going to 3.0 which is no > > longer supported. > > Or 2.1 which doesn't have access to some of the features I'm using in C# > 8. > > > > > > -Original Message- > > From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Stephen > > Russell > > Sent: Tuesday, July 28, 2020 2:26 PM > > To: ProFox Email List > > Subject: Re: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > > installed - Possible? > > > > You can downgrade the version of core required in the project. Either > > way, you have to supply that in your installer. Your clients probably > > won't have it on thier machines. I'd consider using the M$ one because > it > > will bring in the correct bootstraping you'll need. > > > > I only do web installs and not systems that use a forms based UI. > > > > > > > > On Tue, Jul 28, 2020 at 12:11 PM Tracy Pearson > > wrote: > > > > > My searches on the internet are fetching a bunch of build .NET Core > > > 2.1 with .NET Core 3.0 installed. > > > I'm in the later stages of getting a product ready for release and the > > test > > > machines and build machines are still on 3.1.5. > > > > > > When I want to do a quick build from my system which was installed at > > > 3.1.6, it refuses to run on the test machines. I get this: > > > It was not possible to find any compatible framework version The > > > framework 'Microsoft.AspNetCore.App', version '3.1.6' was not found. > > > > > > I tried dotnet build -f netcoreapp3.1.5 and got this: > > > C:\Program > > > > > > > > > > > Files\dotnet\sdk\3.1.302\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Target > > > FrameworkInference.targets(127,5): error NETSDK1045: The current .NET > > > SDK does not support targeting .NET Core 3.1.5. Either target .NET > > > Core 3.1 > > or > > > lower, or use a version of the .NET SDK that supports .NET Core 3.1.5. > > > [c
RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 installed - Possible?
Thanks for bringing up old memories. I'm glad I don't suffer from PTSD over those. Yet, I still deal with DLL issues. Older versions of the software I maintain has VFP 9 SP1 and a COM DLL. Occasional a customer will get some other VFP product installed. That other product only installs the VFP 9 SP2 HF 3 dlls they need. Meaning, they don't ship the VFP9T.DLL. Suddenly functionality of my program stops working. Since this is done in a separate thread (Thank you Christof for the DMUTL.DLL), no crashing error happens in the program. It happens often enough I wrote a CMD file to search the C: drive for all instances of VFP9*.DLL, display the full path of it and the version. Later I wrote a .NET Framework WPF app that searches the PATH for VFP9*.DLL files, and gives the tech the ability to overwrite the offending problem DLL. Sometimes it suggests they should delete the file. For those sometimes clever people that think the VFP 9 files are missing and they download RTM and copy them in to the program directory. Oh to have knowledge and not know you don't have enough of the picture to make a good decision. The bane of software design. I live in both it seems. Tracy -Original Message- From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Eric Selje Sent: Wednesday, July 29, 2020 9:29 AM To: ProFox Email List Subject: Re: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 installed - Possible? Isn't it nice to be out of DLL Hell and into .Net Runtime Purgatory? On Tue, Jul 28, 2020 at 5:01 PM Tracy Pearson wrote: > Thank you Richard, and Rick. > > I will consult with my team on the path we may take in the future. > > Tracy > > > -Original Message- > From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Richard Kaye > Sent: Tuesday, July 28, 2020 5:21 PM > To: profox@leafe.com > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > installed - Possible? > > As I thought might happen, Rick posted an answer. Here it is: > > If you're shipping a vertical application your best bet is to bundle the > runtimes with the application. .NET Core supports building the application > in framework independent mode which includes all the runtime files required > to run the application as part of the build output. IOW, you build a fully > self-contained application that has no runtime dependencies on a .NET Core > Framework. In your case I think this would make sense because the target > machines are unlikely to have a pre-installed runtime of any kind and it > side-steps the potential version mismatches. Doing this will make the > distribution much larger though - a full runtime installation adds roughly > 80-90megs to the application (about 30-35megs in an installer package). > > The other option is to rely on specific runtime versions being available. > .NET Core rolls forward to higher point releases, but only up to the next > point release. (ie. 3.1 and 3.2 are considered different but a 3.11 app can > run on 3.15 but a 3.15 app can't run on 3.11). > > In the situation with churches it's unlikely that pre-existing versions of > .NET Core exist, so distributing self-contained is the way to go I think. > > Or if that's all too much hassle - don't use .NET Core but use (full) .NET > Framework instead, since that will pre-exist on any Windows machine Windows > 7 and forward and just work. This is one of the main reasons why I'm > sticking with full framework for the time being for any desktop, non-server > application development. > > +++ Rick --- > > -- > > rk > > -Original Message- > From: ProfoxTech On Behalf Of Richard Kaye > Sent: Tuesday, July 28, 2020 2:55 PM > To: profoxt...@leafe.com > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > installed - Possible? > > I thought about cross-posting it for you, Tracy. I'll act as your agent in > this matter for my usual 20% commission. 😉 > > -- > > rk > > -Original Message- > From: ProfoxTech On Behalf Of Tracy Pearson > Sent: Tuesday, July 28, 2020 2:39 PM > To: profoxt...@leafe.com > Subject: RE: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > installed - Possible? > > Well, the required version is 3.1.4. Yet it compiled requiring 3.1.6 > because that is the most recent 3.1.X installed. > So the downgrade you might be thinking of is going to 3.0 which is no > longer supported. > Or 2.1 which doesn't have access to some of the features I'm using in C# 8. > > > -Original Message- > From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Stephen > Russell > Sent: Tuesday, July 28, 2020 2:26 PM > To: ProFox Email List > Subject: Re: [NF] .NET Core build to runtime 3.1.5 with SDK for 3.1.6 > installed - Possible? > > You can downgrade the version of core required in the project. Either > way, you have to supply that in your installer. Your clients probably > won't have it on thier machines. I'd consider using the M$ one because it > will brin
Re: ADMIN: Archives seem uncooperative
Yep, all my broken links re-check as good. Thanks! On Wed, Jul 29, 2020 at 9:32 AM Ed Leafe wrote: > On Jul 28, 2020, at 19:20, Ted Roche wrote: > > > > No rush. Archival blog posts aren't going anywhere. Glad you found the > > problem. As always, thanks for the hosting! > > Looks like a corrupted index. Should be fine now. > > -- Ed Leafe > > > > > > > [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/cacw6n4uom-cpe_hxzjc11h8+1bsvk0i+w-iu6_rlxak8gqm...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: ADMIN: Archives seem uncooperative
As Ted said: "As always, thanks for the hosting!" We all are very grateful for what you do, Ed! On Wed, Jul 29, 2020 at 10:31 AM Ted Roche wrote: > Yep, all my broken links re-check as good. Thanks! > > On Wed, Jul 29, 2020 at 9:32 AM Ed Leafe wrote: > > > On Jul 28, 2020, at 19:20, Ted Roche wrote: > > > > > > No rush. Archival blog posts aren't going anywhere. Glad you found the > > > problem. As always, thanks for the hosting! > > > > Looks like a corrupted index. Should be fine now. > > > > -- Ed Leafe > > > > > > > > > > > > > > [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/cacbzhxxu2yln6xbjgqubsloym3ce2d4ke2nccmv2bavfkco...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
X# and .NET Core
Hi all VFPers, Well have not posted much lately about X# here due to some other issues I have to attend to, but good progress are made with support for the VFP dialect. As per the message regarding .NET Core, I would also like to share progress with X# regarding .NET Core support. Attached the link and posting by Robert today. Hope it is of interest to (most) some. Johan Nel George, South Africa. https://www.xsharp.info/forum/public-product/2069-xsharp-builds-on-net-core I would like to share some progress that I made today. I have changed the X# build system to support building for .Net Core. Consider an app that has one PRG file and a XSPROJ file. The contents of the XSProj file looks like this: Exe netcoreapp5.0 true vo As you can see we are compiling for .Net Core 5.0 and for the VO dialect. I have included the XSharp assemblies needed to open a DBF file. The only "strange" thing in here is the package references to the System.Text.Encoding.CodePages package, because by default .Net Core does not have support for Codepage 1252 which I am using. Unlike traditional project files there are no items included. By default .Net Core includes all source code items in the folder. The code looks like this: USING System.Text FUNCTION Start() AS VOID FIELD CUSTNUM, LASTNAME, FIRSTNAME Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) ? "Hello from X#" ? "OS :",OS(TRUE) ? "Framework:", System.Environment.Version:ToString() ? "Xsharp : version", Version(), "dialect", RuntimeState.Dialect:ToString() ? "Datetime :", DateTime() ? "Program :", ExecName(TRUE) ? "Workdir :", WorkDir() ? "Curdir :", System.IO.Directory.GetCurrentDirectory() ? "Opening, Indexing and listing a DBF with .Net Core" ? USE Customer INDEX ON LASTNAME TO LASTNAME DO WHILE ! EOF() ? Str(CUSTNUM,2) , LASTNAME, FIRSTNAME SKIP ENDDO ? "Press any key" Console.ReadLine() RETURN As you can see I am calling a function in the Encoding class to link the package that has the codepage support. The rest is a normal mixture of Xbase code and .Net code. To compile and run the program I type dotnet run on the command line. The result is this: Hello from X# OS : Windows 10 Enterprise (x64) ( Version 10.0, Build 18363 ) Framework: 5.0.0 Xsharp : version XSharp 2.5.2.0 dialect VO Datetime : 29-07-2020 16:10:58 Program : C:\test\bin\Debug\netcoreapp5.0\test.dll Workdir : C:\test\bin\Debug\netcoreapp5.0\ Curdir : C:\test Opening, Indexing and listing a DBF with .Net Core 6 Baker James 2 Borne Maria 15 Chandler Walter 3 Cooper Elizabeth 12 Cusumano Karen 5 Dougherty Janet . . 14 Walsh Gloria 19 Zimmerman Carla Press any key As you can see the runtime, RDD system and Macro compiler all work on .Net Core 5.0 ! You can deploy this app with all support DLLs in one single Exe and 2 small DLLs by calling: dotnet publish --self-contained true -r win-x64 -p:PublishSingleFile=true -p:PublishTrimmed=true This creates the following files, which make up the whole program: 29-07-2020 16:1328.955.153 test.exe 28-05-2020 08:26 500.608 hostfxr.dll 28-05-2020 08:26 506.248 hostpolicy.dll Even the XSharp DLLs are included in test,exe. The total size is 29 Mb. You can also prepare an image for Linux by replacing win-x64 with linux-x64 and then the output is: 29-07-2020 16:1644.552.454 test 28-05-2020 07:54 563.728 libhostfxr.so 28-05-2020 07:54 532.408 libhostpolicy.so A self contained .Net app for Linux in 44 Mb ! I hope you find this interesting. Robert And yes this will be included in the next build. Not with the VS project system, that will take a bit longer. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/f8eb4057-a7e1-10fd-ec95-4d0fb1e45...@xsinet.co.za ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: X# and .NET Core
No SCAN/ENDSCAN support yet? On 7/29/2020 11:56 AM, Johan Nel wrote: Hi all VFPers, Well have not posted much lately about X# here due to some other issues I have to attend to, but good progress are made with support for the VFP dialect. As per the message regarding .NET Core, I would also like to share progress with X# regarding .NET Core support. Attached the link and posting by Robert today. Hope it is of interest to (most) some. Johan Nel George, South Africa. https://www.xsharp.info/forum/public-product/2069-xsharp-builds-on-net-core I would like to share some progress that I made today. I have changed the X# build system to support building for .Net Core. Consider an app that has one PRG file and a XSPROJ file. The contents of the XSProj file looks like this: Exe netcoreapp5.0 true vo Version="4.7.1" /> As you can see we are compiling for .Net Core 5.0 and for the VO dialect. I have included the XSharp assemblies needed to open a DBF file. The only "strange" thing in here is the package references to the System.Text.Encoding.CodePages package, because by default .Net Core does not have support for Codepage 1252 which I am using. Unlike traditional project files there are no items included. By default .Net Core includes all source code items in the folder. The code looks like this: USING System.Text FUNCTION Start() AS VOID FIELD CUSTNUM, LASTNAME, FIRSTNAME Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) ? "Hello from X#" ? "OS :",OS(TRUE) ? "Framework:", System.Environment.Version:ToString() ? "Xsharp : version", Version(), "dialect", RuntimeState.Dialect:ToString() ? "Datetime :", DateTime() ? "Program :", ExecName(TRUE) ? "Workdir :", WorkDir() ? "Curdir :", System.IO.Directory.GetCurrentDirectory() ? "Opening, Indexing and listing a DBF with .Net Core" ? USE Customer INDEX ON LASTNAME TO LASTNAME DO WHILE ! EOF() ? Str(CUSTNUM,2) , LASTNAME, FIRSTNAME SKIP ENDDO ? "Press any key" Console.ReadLine() RETURN As you can see I am calling a function in the Encoding class to link the package that has the codepage support. The rest is a normal mixture of Xbase code and .Net code. To compile and run the program I type dotnet run on the command line. The result is this: Hello from X# OS : Windows 10 Enterprise (x64) ( Version 10.0, Build 18363 ) Framework: 5.0.0 Xsharp : version XSharp 2.5.2.0 dialect VO Datetime : 29-07-2020 16:10:58 Program : C:\test\bin\Debug\netcoreapp5.0\test.dll Workdir : C:\test\bin\Debug\netcoreapp5.0\ Curdir : C:\test Opening, Indexing and listing a DBF with .Net Core 6 Baker James 2 Borne Maria 15 Chandler Walter 3 Cooper Elizabeth 12 Cusumano Karen 5 Dougherty Janet . . 14 Walsh Gloria 19 Zimmerman Carla Press any key As you can see the runtime, RDD system and Macro compiler all work on .Net Core 5.0 ! You can deploy this app with all support DLLs in one single Exe and 2 small DLLs by calling: dotnet publish --self-contained true -r win-x64 -p:PublishSingleFile=true -p:PublishTrimmed=true This creates the following files, which make up the whole program: 29-07-2020 16:13 28.955.153 test.exe 28-05-2020 08:26 500.608 hostfxr.dll 28-05-2020 08:26 506.248 hostpolicy.dll Even the XSharp DLLs are included in test,exe. The total size is 29 Mb. You can also prepare an image for Linux by replacing win-x64 with linux-x64 and then the output is: 29-07-2020 16:16 44.552.454 test 28-05-2020 07:54 563.728 libhostfxr.so 28-05-2020 07:54 532.408 libhostpolicy.so A self contained .Net app for Linux in 44 Mb ! I hope you find this interesting. Robert And yes this will be included in the next build. Not with the VS project system, that will take a bit longer. [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/f064ecd7-4a2e-15f7-a09d-05d93844e...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: X# and .NET Core
Yes, Scan/EndScan now supported in X#. - Matt Slay On 2020-07-29 11:00 AM, MB Software Solutions, LLC wrote: No SCAN/ENDSCAN support yet? On 7/29/2020 11:56 AM, Johan Nel wrote: Hi all VFPers, Well have not posted much lately about X# here due to some other issues I have to attend to, but good progress are made with support for the VFP dialect. As per the message regarding .NET Core, I would also like to share progress with X# regarding .NET Core support. Attached the link and posting by Robert today. Hope it is of interest to (most) some. Johan Nel George, South Africa. https://www.xsharp.info/forum/public-product/2069-xsharp-builds-on-net-core I would like to share some progress that I made today. I have changed the X# build system to support building for .Net Core. Consider an app that has one PRG file and a XSPROJ file. The contents of the XSProj file looks like this: Exe netcoreapp5.0 true vo Version="4.7.1" /> As you can see we are compiling for .Net Core 5.0 and for the VO dialect. I have included the XSharp assemblies needed to open a DBF file. The only "strange" thing in here is the package references to the System.Text.Encoding.CodePages package, because by default .Net Core does not have support for Codepage 1252 which I am using. Unlike traditional project files there are no items included. By default .Net Core includes all source code items in the folder. The code looks like this: USING System.Text FUNCTION Start() AS VOID FIELD CUSTNUM, LASTNAME, FIRSTNAME Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) ? "Hello from X#" ? "OS :",OS(TRUE) ? "Framework:", System.Environment.Version:ToString() ? "Xsharp : version", Version(), "dialect", RuntimeState.Dialect:ToString() ? "Datetime :", DateTime() ? "Program :", ExecName(TRUE) ? "Workdir :", WorkDir() ? "Curdir :", System.IO.Directory.GetCurrentDirectory() ? "Opening, Indexing and listing a DBF with .Net Core" ? USE Customer INDEX ON LASTNAME TO LASTNAME DO WHILE ! EOF() ? Str(CUSTNUM,2) , LASTNAME, FIRSTNAME SKIP ENDDO ? "Press any key" Console.ReadLine() RETURN As you can see I am calling a function in the Encoding class to link the package that has the codepage support. The rest is a normal mixture of Xbase code and .Net code. To compile and run the program I type dotnet run on the command line. The result is this: Hello from X# OS : Windows 10 Enterprise (x64) ( Version 10.0, Build 18363 ) Framework: 5.0.0 Xsharp : version XSharp 2.5.2.0 dialect VO Datetime : 29-07-2020 16:10:58 Program : C:\test\bin\Debug\netcoreapp5.0\test.dll Workdir : C:\test\bin\Debug\netcoreapp5.0\ Curdir : C:\test Opening, Indexing and listing a DBF with .Net Core 6 Baker James 2 Borne Maria 15 Chandler Walter 3 Cooper Elizabeth 12 Cusumano Karen 5 Dougherty Janet . . 14 Walsh Gloria 19 Zimmerman Carla Press any key As you can see the runtime, RDD system and Macro compiler all work on .Net Core 5.0 ! You can deploy this app with all support DLLs in one single Exe and 2 small DLLs by calling: dotnet publish --self-contained true -r win-x64 -p:PublishSingleFile=true -p:PublishTrimmed=true This creates the following files, which make up the whole program: 29-07-2020 16:13 28.955.153 test.exe 28-05-2020 08:26 500.608 hostfxr.dll 28-05-2020 08:26 506.248 hostpolicy.dll Even the XSharp DLLs are included in test,exe. The total size is 29 Mb. You can also prepare an image for Linux by replacing win-x64 with linux-x64 and then the output is: 29-07-2020 16:16 44.552.454 test 28-05-2020 07:54 563.728 libhostfxr.so 28-05-2020 07:54 532.408 libhostpolicy.so A self contained .Net app for Linux in 44 Mb ! I hope you find this interesting. Robert And yes this will be included in the next build. Not with the VS project system, that will take a bit longer. [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/7537c540-63b3-537d-7681-c615fd6fd...@jordanmachine.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
