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?