We Keep Coding

.Net 4.8 Support for Windows 10 ends in 26 days?

I am trying to find out when (or approximately when) .Net Framework 4.8 will go out of support.
Microsoft's site says:
.NET Framework is a component of the Windows OS. Components receive the same support as their parent product or platform. For more information, please visit the .NET Framework Lifecycle FAQ.
The .NET Framework Lifecycle FAQ lists the versions of Windows that support .Net Framework 4.8:
Windows 10 versions: 1607, 1703, 1709, 1803, 1809, 1903
The longest supported listed version is done on 12/8/2020 (Source)
1909 is NOT listed
Windows Server version 1803, 1903
The longest supported listed version is done on 12/8/2020 (Source)
1909 is NOT listed
Windows Server 2008 R2 SP1, 2012/R2, 2016, 2019
The longest supported listed version is done on 01/09/2024 (Source)
So it seems that for Windows 10 (what I use to develop on), .Net Framework 4.8 goes out of support in less than a month. If I install one of the newer versions (like 1909) it is not a supported OS for .Net Framework 4.8 (at least according to the FAQ.)
It seems that I have several more years to run .Net Framework on a server, but, unless I want to actually do my development work on a Windows Server 2019 box, I will be out of support in 26 days. And if I target a Windows 10 box to run my client applications on, I am also done in 26 days.
Am I right or am I missing something? Is it all over in 26 days (except for Windows Server)?

From what I understand, since Microsoft will not be releasing any new versions of .Net Framework, they have committed to supporting 4.8 indefinitely:
.NET Framework 4.8 is the last version of .NET Framework, and no further versions will be released. However, .NET Framework will continue to be serviced with monthly security and reliability bug fixes. Additionally, it will continue to be included with Windows, with no plans to remove it. You don't need to migrate your .NET Framework apps, but for new development, use .NET 5.0 or later.

Running C# v.<latest> on a Win 7 w/ .NET 4.0

We are writing an application that has to run on Windows 7... and we can't install a new version of the .NET framework on those client machines. As the developer, I want to use all the fancy new C# 6.0 language features, and if I understand correctly, the language and the framework have been decoupled.
I just need clarification: If I target C# 6.0 in my application, will the code still run correctly on a Win7 client with .NET 4.0 as the highest framework version?

Yes, you can use a C# 6 compiler while targeting an older version of .NET. The way this usually works is that you have a newer version of Visual Studio and target it at a specific .NET version. For C# 6, this means VS2015. You will be able to use any new C# features, as long as they don't rely on .NET libraries. In particular cases, such as if you want to use async stuff, there are backward compatibility libraries available.
You could also use csc.exe (C# compiler) directly, and bypass Visual Studio.

Filedialog CustomPlaces confusion

I faced a strange behavior using the following code:
FileDialog openFileDialog1;
// ...
openFileDialog1.CustomPlaces.Add(#"C:\whatever\");
This compiles with no errors using .NET framework 2.0.
The code runs well under Windows 7.
But under Windows XP I get the following error at runtime:
System.MissingMethodException: Method not found: 'System.Windows.Forms.FileDialogCustomPlacesCollection System.Windows.Forms.FilaDialog.get_CustomPlaces()'.
Trying to figure out the problem tells me:
Visual Studio 2005 help don't know about the CustomPlaces property of FileDialog
MSDN says that this property exists only since framework 3.5 - and "On Windows XP, this property does not have any effect."
Visual Studio 2005 intellisense offers me the exsistence of the property (so I thought using this property is fine)
That obviously doesn't fit toghether.
I still want to use the code, so I'm trying to figure out how a do check before calling it:
if (...) {
openFileDialog1.CustomPlaces.Add(#"C:\whatever\");
}
My question is:
Is CustomPlaces not supported by .NET 2.0 or is is not supported by Windows XP?
How do I handle this correctly?
1) Do I have to check for the Windows version:
if (Environment.OSVersion.Version.Major >= 6) ...
2) Or do I have to check for the framework version:
if (Environment.Version.Major >= 4) ...
3) Or both, or else !?

It seems you have answered your own question in your post. The MSDN documentation clearly states that the FileDialog.CustomPlaces property exists only from .Net Framework 3.5 onwards. If your application is running on .Net Framework 2.0, then no, it's not supported. (Actually, looking at the .NET 4.5 MSDN documentation for the property, it seems it's supported as of .Net Framework 2.0 SP1.)
If you are using Visual Studio 2010 or higher, I would ensure that you retarget your project to compile with the .Net Framework 2.0 (RTM) if that's what framework your application will be running against. I noticed that you specifically mentioned VS 2005. If you are using VS 2005, I don't believe that has any re-targeting capabilities (if memory serves me correctly); VS2005 by default compiles against .NET Framework 2.0. Here's where things get interesting: an installation of .NET Framework 3.5 has .NET Framework 2.0 SP1 and .NET Framework 3.0 SP1 as installation pre-requisites. So, if your machine has only .NET Framework 2.0 and you want to install .NET Framework 3.5, then your .NET Framework 2.0 will be upgraded to .NET Framework 2.0 SP1 (and additionally, .NET Framework 3.0 SP1 will also be installed).
So what does this mean for you? Well, if you compile your program on a machine on which .NET Framework 2.0 SP1 or higher is installed, your program will compile just fine. Furthermore, if you run the program on a machine running .NET Framework 2.0 SP1 or higher, it will also run just fine. However, if you take this same program and run it on a machine which contains only the vanilla .NET Framework 2.0, you will get the error you see above because that method/property is not supported in the libraries included with the .NET Framework 2.0.
The other side of the story is the part of the MSDN documentation that says that while FileDialog.CustomPlaces exists from .Net Framework 2.0 SP1 and onwards, and that while that version of the Framework may be installed on Windows XP, that on Windows XP calling the property has no effect (i.e. it's a null-op, not supported by the OS). So no error should occur, but you will also see that whatever you tried to add to the CustomPlaces collection would not show up when you run the application on Windows XP. Again, looking at the updated documentation as of .Net Framework 4.5.x (see the link above), it clearly states that the lowest supported client operating system platform supported is Windows Vista SP2. So in all likelihood, you're out of luck when it comes to Windows XP.
If you want to do an OS version check, I would advise you to do the following check:
if (Environment.OSVersion.Version.Major > 5 &&
Environment.OSVersion.Version.Minor >= 0 &&
Environment.OSVersion.ServicePack == "Service Pack 2")
{
// Add CustomPlace here...
}
Note that the check above will not allow you to add the FileDialog.CustomPlaces for Windows Server 2008 (even though it is supported—because through .NET, you're not able to check the ProductTypeID property). Furthermore, FileDialog.CustomPlaces is not supported on the Server Core mode of Windows until Windows Server 2008 R2 SP1 (but the code above will allow you to attempt to add the custom place, but like Windows XP, it will fail silently). In order to make a determination for these versions of Windows, you'll need to use a bit of PInvoke to access the Win32 API's GetVersionEx method and OSVERSIONINFOEX structure located in kernel32.dll as shown here and/or here.
However, generally speaking, it's not a good idea to do operating system version checks. They are notoriously difficult (especially with older operating systems). What you really need to do is to perform a .NET Framework version check. Your application apparently requires, at a minimum, .NET Framework 2.0 SP1. If you have an installer for your program, I would build in this check to your installer and optionally provide the ability to install the .NET Framework 2.0 SP1 as part of the installation of your program.
If you're not using an installer to distribute your program, then you should perform a .NET Framework version check in your application prior to attempting to add the FileSystemCustomPlace to the CustomPlaces collection to prevent the error from occurring; however, doing so will require your users with versions of Windows Vista and later to run the application with elevated permissions. Aaron Stebner has a great blog post on how to determine the .NET Framework installations that are available on your machine with example code. There is also a C# implementation of this code provided by a CodeProject.com user here.

Compatible with both dotnet 3.5 and dotnet 4.0

Originally it is set to use .Net3.5 for compatibility with win7. (Actually using WPF)
However when it comes to users in win8 which supports only the .Net4.0,
it is required for users to download and install .Net3.5,
which results in a terrible user experience.
Here comes my question:
How to make a software compatible with multiple .Net versions?
Actually I tried to use .Net 2.0 for the software and it goes well with both win7 and win8. However when it comes to .Net 3.5, the backward compatibility seems to be awful. However I really need some features available in 3.5, or WPF.
I don't mind if I have to build multiple binary releases, provided a auto-selection mechanism is available.
P.S. I've found a similar question at Make same app compatible for Net3.5 & 4.0#stackoverflow but got no help after reading it.
Edit
I'm using both winform and WPF. I'm using WPF for a better looking UI, however, as is nutoriously know, the webbrowser in WPF cannot render in a WPF app. So I use a winform webbrowser.

If you're making an normal WPF desktop application, just move your target framework to .Net 4 and be done with it. .Net 4 is fully supported on Windows 7 as well as Windows 8. If you don't want to have the users download an install .Net 4, include it in your setup distribution.

Make sure you don't use types that are not included in the lowest version you target!
.NET 2, 3 and 3.5 all share the same CLR, which should have the same effect on your code and expected outcome. 3.0 and 3.5 has different types as well, so watch out for that.
.NET 4.0 has a different CLR and your code might not act 100% in the same way as with the CLR 2.0.
But, why not ship with the redistributable 4.0 framework. It works on XP sp3, Vista sp1 , 7 and 8. Distributing .NET 4.0 redistributable with application

Running a c# project on windows 7

If I compile a simple(no additional libraries or assemblies) c# application, can I assume it will run on any new windows 7 machine natively or do I have to worry about end users having .Net or other libraries installed?

Windows 7 includes the .NET Framework 3.5.1 as an OS component.
This means you will get:
.NET Framework 2.0 SP2
3.0 SP2
3.5 SP1
some post 3.5 SP1 bug fixes
However, if you're using newer versions of .NET, and if you're using libraries that don't get shipped with the above, then you still need to consider packaging these up in an MSI/installer.
This page on Wikipedia has a good summary:
http://en.wikipedia.org/wiki/.NET_Framework#Versions
If this is anything more than a "quick and dirty" app, or unless you work in an area where you know exactly what the target machines look like (i.e. a corporate environment with a locked down OS image) then I'd suggest you look at building an installer and deal with pulling down the pre-requisites as appropriate. (WiX is my recommended way of doing that).
http://wix.sourceforge.net/
And WiX questions are tagged here on SO...
https://stackoverflow.com/tags/wix/

Windows 7 comes preinstalled with .NET 3.5.1 which includes 3.5 SP1, so unless you need features of .NET 4 it should work just fine.

Windows 7 ships with .Net 3.5, so, if you this .net version or lower, your application should be able to run on any Windows 7 installation

You need the appropriate .Net framework installed to match what your C# program was written with. If you don't have the correct framework, download it from microsoft.com.