.NET 5 vs Framework question

[Shaggy Hiker]

I have a tiny program targeting framework 4.8. This is working fine in testing, but it is a little console application that gets deployed to a server. There's a different question about that, which I might as well add to this. The goal is to replace an existing console app that also targets FW 4.8. Since that existing app has been running for years on the server in question, there's little question that FW 4.8 is available, yet when I replaced the existing console app with the new one, I got a message saying that FW 4.8 needed to be installed on the system before the app would run. I can't reboot that system, so installing 4.8 is a bit difficult. It shouldn't be necessary anyways, since a program that uses 4.8 has been there for years, and runs.

So, the first question is: Can anybody explain how it is possible that 4.8 could be required, or not available, in that situation? In other words, why am I getting the message that it is required when it clearly must be there?

However, I was inclined to re-write in .NET 5, which would remove any question about the FW. This was done quite easily, but I ran into an issue.

I wrote the FW and .NET 5 versions on the same computer and tested them both on that same computer. The FW version runs fine, the .NET 5 version almost runs fine. However, one of the steps is the reading of a CSV file. I'm doing this using the OLEDb provider. Clearly, this exists, since the FW version works fine, but the .NET 5 version gives me an error when it runs saying "The Microsoft.Jet.OLEDB.4.0 provider is not registered on the local machine." Well, the connection string for both the FW and .NET 5 versions have that as the provider, one works fine, the other does not.

What is going on there?

A final question, just to be complete, would be this: I had some question as to whether or not this thing was going to work on the deployment computer, so I moved the .NET 5 version over there and tried running it. I wasn't clear whether it would fail or not, but it would write some stuff to a database before it ever got to the OLEDB.4.0 thing, which SHOULD be on the deployment computer, but then again, it MUST be on the development system, as well. It wouldn't matter, though. For this test, it was enough to see what got written to the DB, which happened before any failure (the failure would write to the DB, as well).

On the development system, a console window comes up, and goes away when the process completes. On the deployment computer, the console pops up just long enough for me to register that roughly two lines of text show up, though I can't read them before the window goes away. That's fine, too, because I don't need a console window popping up. However, nothing writes to the DB, which is the very first step in the program. Therefore, I'd say the console window flashing on the screen so briefly, indicates that the program is exiting immediately, and not actually doing ANYTHING, including executing that first line, which would write to the DB.

Any suggestions as to why that might be?

[peterst]

The "lines" you see when you run .NET 5 app on the server are saying that you need to install the runtime. You could check that by running the app from command prompt as it will not close immediately.

To create app with all libraries required to run, you have to edit your vbproj/csproj (Sdk style) and add in the first PropertyGroup node (where output type, target framework and other project settings are set):

<PublishReadyToRun>true</PublishReadyToRun>

To reduce the number of libraries in the output dir, you can publish the app trimmed so you need to add also:

<PublishTrimmed>true</PublishTrimmed>

And you need to publish your app. You can do that with following command line:

dotnet publish -r win-x64 -c Release

Edit:
You can publish via command line the ready to run version without editing the project file:

dotnet publish -p:PublishReadyToRun=true

[peterst]

I would start new console app that just writes something to screen and waits for user input, something like:

Console.WriteLine(".....")
...
...
...
 
Console.WriteLine("Press Enter to exit...");
Console.ReadLine()

[Shaggy Hiker]

The "lines" you see when you run .NET 5 app on the server are saying that you need to install the runtime.

Just to clarify, it is the FW version that says the runtime must be installed, and the runtime it is requesting is one that is used by an app that has been running there for years.

Are you also saying that a .NET 5 app is NOT published in such a fashion that it is ready to run? I can't say I have much experience with .NET 5, but that surprises me. I thought that, so long as I included the contents of bin\release, then it would have all it needed.

[peterst]

If .NET 5 "flashes" with few lines of messages, it says there is no runtime (similar to .NET Framework). This is the result of my test on (very) old Win7 machine where .NET Core/5/6 runtime was never installed:

A fatal error occurred. The required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [F:\tests\].
If this is a framework-dependent application, install the runtime in the global location [C:\Program Files\dotnet] or use the DO
TNET_ROOT environment variable to specify the runtime location or register the runtime location in [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x64\InstallLocation].

The .NET runtime can be found at:
- https://aka.ms/dotnet-core-applaunch..._version=6.0.5

[kareninstructor]

That is odd, seems like if there is a reference for FW 4.8 it should work although I've only used 6.0 and that was a one-off solution.

Is the Core project compiled for Prefer 32-bit ? And was this done with VS2019 or VS2022 which I have not tried yet and heard it's 64-bit only which could be an issue.

(Stabbing in the dark here)

[Shaggy Hiker]

Those are good suggestions. VS2019 was used for both FW and 5.0 versions. I thought you were onto something with the prefer 32-bit, but after a quick check, both the long standing and new FW apps have the same settings regarding targets (Any CPU) and prefer 32-bit. In fact, the only difference I could find in that level of settings is that the old one was built with Option Infer OFF, while the new one had it ON. That certainly shouldn't have any impact.


As for the runtime for 5.0. I hadn't heard that, and it's something of a dealbreaker. I can't readily reboot that system, so installing something that requires a reboot is not simple to do.

That should be fine, because the old and the new FW apps use 4.8, so I can just walk away from the 5.0 version...except that I can't run the FW version because of being told that 4.8 is not available....when it certainly must be.

[Shaggy Hiker]

I dropped back to FW 4.6, and it appears to be running fine. I couldn't go very far back, as I forget when Async/Await was added to the framework. 4.6 seemed reasonable, and so far it does appear to be.

I'm still curious as to why 4.8 was not allowed when it clearly WAS already present. I'm also curious as to why the development system said that OLE4.0 was not installed when the FW version had no issues with it.

[peterst]

...
As for the runtime for 5.0. I hadn't heard that, and it's something of a dealbreaker. I can't readily reboot that system, so installing something that requires a reboot is not simple to do.

That should be fine, because the old and the new FW apps use 4.8, so I can just walk away from the 5.0 version...except that I can't run the FW version because of being told that 4.8 is not available....when it certainly must be.

Similar to .NET Framework, newer .NET Core/5/6 require runtime to be installed if you deploy your small not ready to run apps. From .NET Core 3+ there is option to create ready to run binaries with all runtime libraries included so final binary directory is about 140MB. But there is another option to trim the output binaries to only dependent DLLs and reduce the size.

So your options with .NET 5+ are two: install .NET 5/6 runtime or build using ready to run option. You can test on your machines where you don't have Visual Studio or .NET 5+ installed to avoid messing with production server tests. Just start with new simple console project to see how to produce these ready to run builds.

Legacy .NET Framework projects may have some problems to run with .NET 5+, but it is good to move to the latest versions for new development as .NET is constantly updated, new features are added, performance is greatly improved. Another (and for me bigger) problem are NuGet libraries where authors slowly but steadily stop supporting .NET Framework versions and you don't want to get stuck in the past like the people in the neighbour subforum.

[Shaggy Hiker]

That's a good answer. The thing that has kept me from moving to .NET 5/6 has been that there was a significant change in the way that dynamically loading dlls work. The major project that I have worked on for about a decade, loads most dlls dynamically as plugins. I can write a pugin for that system in .NET 5 (I have yet to download VS2022, so .NET 6 isn't happening, yet), but I can't load it because of the change in the way the behavior works. To be clear, I have not looked into this in any detail for a complex reason I won't go into. Most likely, I should move the whole project to .NET 6 and be done with it, but there's good reason to wait a while.

In any case, the point is that I am well behind the curve on .NET 5/6, and will remain there for a few more months, at least. Apparently, the system I am putting that program on is also behind the curve. Fortunately, dropping back to FW 4.6 worked.

[kareninstructor]

On a side note, forget .NET Core 5, it's a stepping stone to .NET Core 6 which is long term support.

In my workplace .NET Core 5 is only used for me teaching mainframe developers Razor pages (long reason why) and waiting for VS2022 to arrive (it takes forever in state government to get 10 copies of Visual Studio or most software for that matter).

[Niya]

Are you also saying that a .NET 5 app is NOT published in such a fashion that it is ready to run? I can't say I have much experience with .NET 5, but that surprises me. I thought that, so long as I included the contents of bin\release, then it would have all it needed.

You could still XCOPY deploy .Net 5 and 6 apps via bin/release but I recommend publishing it instead. You have options like trimming and single file deployments that are only available through publishing. For example, if you wanted this to run on Linux, the only way is to publish.

[Shaggy Hiker]

This one is not published, for complicated, and possibly invalid, reasons. It runs in only one place, and the one place it is running makes me queasy. I'm still mulling where it would be best to have it located, but for now, the old one is there, so the new one is there.