We Keep Coding

What is involved in creating SDK style project?

I have an old .Net Class Library project project with some old ADO .Net code to run SQL queries but also has some third party libraries that have been upgraded over time.
I think its time to upgrade this to Entity Framework so was considering moving this from .Net 4.7 to .Net 6 at the same time too.
It seems i have to upgrade the project to an SDK version but with it being a large project could i upgrade this to an SDK version using .Net 4.7 so I could replace existing projects with the newer version of the class library and the introduce .Net 6 at a later date?
I dont want to do a large upgrade but prefer to take it in smaller chunks but after researching around i cant find a good enough answer to see if i should focus on an upgrade or a rewrite (we want to leave a rewrite as a last resort)?

So firstly, we should probably clear up some understandings. .Net 4.7 is actually .NET Framework, and .Net 6 is what evolved from .NET Core, now referred to simply as .NET. (Further, .NET [Core] skipped versions number in 4.x to try to reduce this confusion)
.NET Framework and .NET are different. .NET Framework is Windows only; .NET is cross-platform. Not all the libraries you may have used with .NET Framework may be available for .NET [6].
I don't think it would necessarily require a rewrite, but you're going to need to do some research into what targets the libraries you're using are targeted at in their TargetFrameworks attribute. For example, here's one from a library I use:
<TargetFrameworks>net462;netstandard2.0;netstandard2.1;net6.0;net7.0</TargetFrameworks>
net462 is indicating it can target .NET Framework 4.6.2 specifically.
net6.0 and net7.0 are similar, but for .NET 6.0 and .NET 7.0 respectfully.
netstandard2.0 and netstandard2.1 are probably the more useful ones for you at this point. They refer to standardization between various versions, meaning it can potentially target both .NET Framework and .NET, which is what you're looking for here to not have to rewrite. You can read more about .NET Standard here.
Regarding EntityFramework specifically, it looks like you may be possible as a stepping stone, though its target would be .NET Framework 4.5 rather than 4.7, so mileage may vary. It supports .NET Standard 2.1, though which should make it viable for later .NET versions (6+). I'd recommend getting your application into .NET (5+ at least) as soon as you're able, though, and switching to EntityFrameworkCore when you get the chance.

What are the consequences of upgrading my .NET analyzer's target framework to .NET 5.0?

I have been writing an analyzer and using .NET Standard 2.0 so that I could target .NET Framework 4.7.2, which I was using in the VSIX version of the analyzer. Soon however I chose to drop it as supporting it was not beneficial. Ever since I have wanted to upgrade the supported framework to .NET 5.0 to also get the new language features along the path.
How would that affect the end users that would include the analyzer to their projects through the released NuGet package? Should I also keep supporting the older framework versions?

You can't use anything other than .NET Standard 2.0, because VS runs under .Net Framework 4.* and the csc Roslyn compiler runs under .Net 5/6. The common ground is .NET Standard 2.0, nothing else will work.
This is still the case with VS 2022, it is still a .Net Framework application, the only difference is that it's now a 64-bit process, which means that your analyzer needs to be Any CPU to work in both.

Multiple versions of .NET on the same server

So I've always known it's okay to run multiple versions of the .NET framework on a single computer (client or server alike). This question, though a bit old, talks about this.
A while back, however, I was tasked with creating a new ASP.NET application, and I was trying to decide whether to use the full .NET framework or .NET Core, and I came across this article from Microsoft. The article states that if I need side-by-side installations of the framework, I should use .NET Core. Here's the full quote:
To install applications with dependencies on different versions of
.NET, we recommend .NET Core. .NET Core offers side-by-side
installation of different versions of the .NET Core runtime on the
same machine. This side-by-side installation allows multiple services
on the same server, each of them on its own version of .NET Core.
But I thought side-by-side installations of the Framework were already possible without .NET Core? What am I missing?
The reason I ask is that I currently have an old ASP.NET application that uses the .NET Framework 2.0, and I am now working on one that uses .NET Core. I ran into some issues that got me considering switching the .NET Core app to the full .NET Framework 4.6, but that Microsoft article got me a bit confused.
The question is: will I be able to run both apps (.NET framework 2.0 and 4.6) on the same Windows 2008 R2 server without issues? If so, then what is that article referring to?
One last thing: both my apps (old and new) use Crystal Reports. There's a possibility that the new app might need a newer version of Crystal Reports than the old app. Will I be able to run different versions of Crystal Reports like this on the same server? Is this the situation in which I would require .NET Core like the Microsoft article says?
Thank you

Side-by-side installations of the framework are not only possible, they are a fact. NET 1.0, 2.0 and everything past 4.0 all have separate installations. However:
.NET 3.0 and 3.5 both use the 2.0 runtime and are therefore not truly separate.
Similarly, .NET 4.5 and all versions above all use the 4.0 runtime and are therefore not separate from each other. To further complicate things, when you install a later version, the base 4.0 runtime is actually upgraded.
Last but not least, which framework version gets picked to run your application has changed with .NET 4.0. The rules for this are rather complicated and depend on both the versions installed and the application configuration; see this article for a full discussion.
To your question, then:
Will I be able to run both apps (.NET framework 2.0 and 4.6) on the
same Windows 2008 R2 server without issues?
If .NET Framework 2.0 and 4.6 are both installed, then yes. Assuming no special configuration settings, the 2.0 application will run on the 2.0 framework, but it can also be configured to use the 4.6 framework (which will present itself as the 4.0 runtime).
If so, then what is that article referring to?
The article is referring to the fact that the full .NET Framework has gradually abandoned the idea of perfectly separate side-by-side installations by having no separations between minor version (and sometimes even major versions), while .NET Core has doubled down on the idea by allowing self-contained deployment. That is to say, not only can a .NET Core 1.0 and a .NET Core 2.0 application coexist without any risk of sharing dependencies the way a .NET Framework 2.0 and 3.5 application would, even two .NET Core 1.0 applications can exist together without sharing dependencies, something which is not possible for full .NET Framework applications. If (say) a patch is installed for .NET 2.0, it will affect all .NET 2.0, 3.0 and 3.5 applications, at least on the binary level. You cannot choose to have some applications affected by the patch and not others (although configuration switches are usually added for behavior that breaks compatibility).
One last thing: both my apps (old and new) use Crystal Reports.
There's a possibility that the new app might need a newer version of
Crystal Reports than the old app. Will I be able to run different
versions of Crystal Reports like this on the same server? Is this the
situation in which I would require .NET Core like the Microsoft
article says?
This is independent of the framework and depends on how Crystal Reports itself handles versioning. According to the manufacturer, the answer is yes, for major releases but not minor updates:
Side-by-side installation of different major release version of
Crystal Reports designer is supported since Crystal Reports 9,
because each major release version installs the software in different
directory.
You do not require .NET Core to make side-by-side installation of different assembly versions possible. What's more, even if you used a self-contained deployment of your .NET Core application, it would likely still refer to the shared installation of Crystal Reports on the machine, not to a self-contained deployment of Crystal Reports (I don't think such a thing exists; I'm not even sure Crystal Reports is currently supported on .NET Core).
Last but not least: note that some versions of .NET are no longer officially supported. The policies on what versions are supported (and where) are fairy complex, depending as they do on whether the Framework was part of the OS or not, but detailed here. .NET 4.6 has some very nasty JIT compiler bugs (fixed in 4.6.1), so you really don't want to be using it anyway, official support or no. If your server does not yet have any version of .NET past 2.0 installed, you may as well jump directly to the latest supported version for your OS (as of writing, 4.8).

Is it guaranteed for two (or more) versions of the .NET Framework to be installed side by side?

Based on many articles I have read, I came to the conclusion that it is not guaranteed for a .NET Framework to be 100% backward compatible with the previous versions. So my question is: is it guaranteed for two (or more) versions of the .NET Framework to be installed side by side without any problems (is this documented somewhere by Microsoft)?
For example, can .NET 1.1 be installed side by side with .NET 4.5, or will I have to re-compile my project to work on .NET 4.5?

There's a difference between the Framework version and the runtime version. You can have different runtimes operate side-by-side without interfering if your application is properly marked with the expected runtime in its configuration file.
Programs written for a particular runtime (e.g. 1.1, 2.0, 4.0) can run independently against their given framework with no side effects from the other frameworks. That being said, you must modify your config file to ensure that a .NET 2.0 application runs with the .NET 2.0 CLR when the 4.0 CLR is installed on the machine
The CLR's are affected by the version of the Framework installed on the machine. For example, 4.0 and 4.5 both run with the 4.0 CLR and having 4.5 installed introduces some incompatibilities. That being said, these issues are usually very specific and most applications will not be affected by them.
Here's Microsoft's page on compatibility between Framework versions.

Your question seems to be in two parts:
Are .NET Frameworks backward compatible?
Can you install more than one .NET Framework at the same time on the same computer?
Yes you can install multiple versions of the ".NET Framework" at the same time without problems. Whether or not an app runs as expected is a different story as explained in the MSDN doco.
MSDN:
You can load multiple versions of the .NET Framework on a single computer at the same time. This means that you can install the .NET Framework without having uninstall previous versions Tell me more
...and
In general, you should not uninstall any versions of the .NET Framework that are installed on your computer. There are two reasons for this:
If an application that you use depends on a specific version of the .NET Framework, that application may break if that version is removed.
Some versions of the .NET Framework are in-place updates to earlier versions. For example, the .NET Framework 3.5 is an in-place update to version 2.0, and the .NET Framework 4.5.2 is an in-place update to versions 4, 4.5, and 4.5.1. Golly, tell me more
Backward Compatibility
Though newer versions of the framework are generally backward compatible (with respect to contracts) there may be unforseen behavioural changes visible at runtime.
As MSDN states:
The .NET Framework 4.5 and its point releases are backward-compatible with apps that were built with earlier versions of the .NET Framework. In other words, apps and components built with previous versions will work without modification on the .NET Framework 4.5
...however:
In practice, this compatibility can be broken by seemingly inconsequential changes in the .NET Framework and changes in programming techniques. For example, performance improvements in the .NET Framework 4 can expose a race condition that did not occur on earlier versions. More
So an app without appropriate config may be upscaled to use later versions of libraries leading to undesirable results. Sadly nothing can be done for a 4.0 app if .NET 4.5 is installed because the actual CLR was changed. More...
As Rick Strahl writes:
Note that this in-place replacement is very different from the side by side installs of .NET 2.0 and 3.0/3.5 which all ran on the 2.0 version of the CLR. The two 3.x versions were basically library enhancements on top of the core .NET 2.0 runtime. Both versions ran under the .NET 2.0 runtime which wasn’t changed (other than for security patches and bug fixes) for the whole 3.x cycle. The 4.5 update instead completely replaces the .NET 4.0 runtime and leaves the actual version number set at v4.0.30319. More...

So far, we only see the following frameworks can be run side by side,
.NET 1.x (already obsolete, so don't want to comment more)
.NET 2.0/3.0/3.5 as a whole
.NET 4.0/4.5/4.5.1/4.6 as a whole
.NET Core
And you can see there is no guarantee from Microsoft whether a new version can be installed side by side or be an in-place upgrade of the previous version, and it really depends on what feature sets the new version brings.
We might observe some general rules (such as the frameworks with the same CLR version should be in-place upgrade), but that's still not something guaranteed by Microsoft, and can be broken by a future framework release.

Build .NET-Applications always for lowest possible framework-version?

I'm new in the .NET-world.
I just built my first application with .NET-versionn 4.0 and am wondering if its a wise choice to lower the target-framework as much as possible (to 3.0 maybe) if it still works then.
Whats best-practice when it comes to choosing the appropriate .NET-version?

If you are targeting Windows desktop users, you can be pretty confident they have at least .NET 2.0 and probably higher. It is unlikely they will have .NET 4 though. Unless you know the audience (eg. a business customer), choosing .NET 4 will likely limit your reach at this point.
.NET 4 introduces the first real platform change in a while in that it is built on the CLR (Common Language Runtime) version 4. Before that, .NET 2.0, 3.0, and 3.5 all ran on version 2 of the CLR.
The only difference between .NET 2.0, 3.0, and 3.5 are the in the framework (the libraries). Most of the libraries are unchanged but new libraries where added with each version. It depends what libraries you use. If you include all the libraries you need in your application then you can run anything that .NET 3.5 can do on .NET 2.0.
If you need a legal way of distributing .NET 3.5 era libraries to a .NET 2.0 audience, one option is shipping some assemblies from the Mono Project.
For example, you might find that the only .NET 3.5 assembly you need is System.Core.dll. If you include the Mono version of System.Core.dll with your application, it will run just fine on .NET 2.0 and up even though you are using ".NET 3.5" features (like LINQ for example).
If you are using ASP.NET then it really does not matter what they have as you are just feeding them HTML.
EDIT: I was not aware that Windows Presentation Foundation (WPF) required a service to be running. I have used Mono to add .NET 3.5 features to .NET 2.0 apps but I have not used WPF.
You cannot get the WPF assemblies from anywhere but Microsoft though so you cannot redistribute those anyway. Mono projects tend to use GTK# for the GUI although Windows Forms is also available cross-platform.

Choosing the framework version to support is mainly a question of your target user group.
If you are developing a tool for a
corporate environment, you might be
limited by the framework version that
the default configuration of the
corporation supports (which sometimes
might be a version or two behind the
latest version) - or you are lucky
and the IT department is willing to
upgrade their platform to the latest
version.
If you are targeting home users you
should consider that not everyone is
already having the latest framework
version installed, and not every user
is willing to download and install a
new version just to use your tool. So
you need to consider if you can allow
to ignore such users or not.
Of course, you can always include the latest version with your setup, but don't forget that the framework installation requires administrative rights.