We Keep Coding

C# application host version detection when no .NET runtime is installed

I have an application that relies on .NET 6 runtime. If I don't have any .NET runtimes installed on my machine, not only the one my application needs but also without other versions of .net runtime, I could see some messages prompted when execute it.
Does anyone have any insight about how the detection work or who gives the prompted information? Is it done by the OS?
Thanks!

Windows 10 and 11 comes pre-installed with .NET Framework.
A .NET 6 application can be released as a self-contained application that includes the required runtimes to run (if it is not on the machine) as suggested here; https://stackoverflow.com/a/72630528/1165173
https://learn.microsoft.com/en-us/dotnet/core/install/how-to-detect-installed-versions?pivots=os-windows

c# Web App - Encoding' does not contain a definition for 'UTF8

IIS Website on Server 2016.
using System.Text
string x = "abcdefg";
byte[] y = Encoding.UTF8.GetBytes(x);
Results in:
Compiler Error Message: CS0117: 'Encoding' does not contain a definition for 'UTF8'
It isn't complaining that "Encoding" is undefined, but that .UTF8 in the Encoding class is undefined.
Works fine on my own desktop running IIS Express in Visual Studio, but when deployed to Server, gives the above error message.
My local dev machine has: .NET Framework 4.7.2
Server has only Microsoft .NET Runtime 5.0.9 and Microsoft ASP.NET Core 5.0.9. In fact, the server does not have any version of .NET Framework installed, yet all other web apps (mine and others) are working fine.
Can I install and run .NET Framework 4.7 alongside .NET Runtime 5? And should it be necessary in the first place? Does .NET Runtime 5 not include Encoding.UTF8?
Thanks.
EDIT: There is nothing wrong with this code. This is a question of framework dependencies or interrelations.

Reinstalling the .NET Framework on the server ultimately fixed this.

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.

Handle missing .NET Framework (0xc0000135) crash better?

When attempting to launch a C#/.NET application on a Windows XP installation without the correct .NET Framework installed, the app simply crashes with the message:
---------------------------
ThisApp.exe - Application Error
---------------------------
The application failed to initialize properly (0xc0000135).
Click on OK to terminate the application.
---------------------------
OK
---------------------------
Which is honestly pretty meaningless to a Joe User, especially since the error code could refer to things other than .NET Framework not being present.
Is it somehow possible to crash with a more meaningful message? (Something like "This application requires .NET Framework 3.0 to run. Please download it at http://www.example.com/")
Edit:
Alright, I did some further testing and found out something quite interesting.
On a clean Windows XP SP3 install (with no .NET Framework installed), the app will always crash with the above message, regardless what .NET Framework version it's targeting, except .NET 4.5 and .NET 4.5.1, which show an even worse message:
---------------------------
path\to\ThisApp.exe
---------------------------
path\to\ThisApp.exe is not a valid Win32 application.
---------------------------
OK
---------------------------
Now the interesting thing with Windows Vista and further is that these actually take the ThisApp.exe.config file into consideration when launching the app.
On a clean Windows Vista SP2 install (with .NET 3.5 installed by default), targeting .NET 4.0 and above with .exe.config causes the following message to appear:
---------------------------
ThisApp.exe - .NET Framework Initialization Error
---------------------------
To run this application, you first must install one of the following versions of the .NET Framework:
v4.0
Contact your application publisher for instructions about obtaining the appropriate version of the .NET Framework.
---------------------------
OK
---------------------------
Now without .exe.config, this shows up instead:
---------------------------
ThisApp.exe - .NET Framework Initialization Error
---------------------------
To run this application, you first must install one of the following versions of the .NET Framework:
v4.0.30319
Contact your application publisher for instructions about obtaining the appropriate version of the .NET Framework.
---------------------------
OK
---------------------------
A very minor change, I know, but I'm going somewhere with this. It's interesting to note that the version number (v4.0 or v4.0.30319) stays the same even when targeting .NET 4.5 and 4.5.1.
Now on a clean Windows 7 SP1 install (with .NET 4.0 Client Profile installed by default), targeting .NET 4.0 (Full) and above with .exe.config causes the message that was mentioned here to appear:
---------------------------
ThisApp.exe - .NET Framework Initialization Error
---------------------------
To run this application, you first must install one of the following versions of the .NET Framework:
.NETFramework,Version=v4.0
Would you like to download and install .NETFramework,Version=v4.0 now?
---------------------------
Yes No
---------------------------
Now this message is more like it. The version also changes to v4.5 and v4.5.1 when targeting .NET 4.5 and 4.5.1 respectively.
However, without .exe.config, the app launches normally, even when targeting .NET 4.0 (full) and higher (even 4.5). I imagine that if I was actually using any features of .NET 4.0 full or 4.5 and higher, the app would crash eventually, but I still think it's pretty interesting. Hypothetically, you would be able to check for the correct version of .NET inside the app itself.
I have not been able to test on Windows 8/8.1, but I imagine it's the same as Windows 7.
Either way, this is not a solved problem, at least not on Windows XP, which still has a large installed base.
Also, please stop telling me to use an installer. I know. That is not what this question is about.

Which is honestly pretty meaningless to a Joe User,
Joe user only should start programs that have been installed. It is the responsibility of the installer to handle prerequisites.
Is it somehow possible to crash with a more meaningful message?
No, becaused you do not crash. Not in .NET. When .NET was created, microsoft made the files backward compatible. It is the native initialization code in the executable that blows - not something in your .NET code. Without runtime, the .NET code can not run.
Funny enough, this is a solved problem. You are using a totally outdated version of .NET as this has been fixed in the latest versions (.NET 4.0 upward) with a more meaningful dialog.
http://blogs.msdn.com/b/dotnet/archive/2012/03/07/optimizing-the-net-framework-deployment-experience-for-users-and-developers.aspx
has a reference. Depending on windows version that leads directly to a download/install dialog.
.NET 3.0 is quite ancient.

ASP.NET MVC 3 - Operation could destabilize the runtime

I've a MVC3.0 (.Net 4.0) application which runs perfectly fine on Windows 7 development machine (with VS2010). The same application also runs fine on one of the Windows 8 Server with IIS 7.
However, the very same application throws the exception below on other Windows 8 Server with IIS7.
Operation could destabilize the runtime.
Stack Trace:
[VerificationException: Operation could destabilize the runtime.]
System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Please, could someone help me to understand what is causing this issue?
Is it .NET Framework 4.0? (I verified both servers have .Net
Framework 4.0 installed)
Is it IIS and MVC 3.0 Issue? (Do we need to install MVC 3.0 separately for IIS to run?)
How do we setup the web app to run on FULL TRUST in IIS 7?
Or completely something else (tried registering the iis with spnet_regiis.exe -ir did not help either)
Is it necessary to install this http://www.microsoft.com/en-us/download/details.aspx?id=1491 on web server?
Any help will be appreciated.

The VerificationException is thrown when the JIT compiler find mismatching type information in the assemblies or invalid IL instructions. For example, mismatching methods signatures (or return types) between callers and called method (when a method's signature is changed and the dependent assemblies are not recompiled).
To solve the problem you can use peverify to check the assemblies:
peverify MyCompany.WebAppMainAssembly.dll
It will tell what member is causing the conflict. Something like found <method sig>, expected <expected signature>. Now you know what assembly caused the problem. Reinstall it in the GAC if necessary. MVC, EF and Unity have msi installers, or install by hand...
BTW, to run the peverify open the Visual Studio Command Prompt or look for in C:\Program Files (x86)\Microsoft SDKs\Windows\<winver>\Bin (this path can change a bit).

The issue might be related to this hotfix: http://support.microsoft.com/kb/2748645
Based on your explanation of the issue and the tests you've already done, this framework bug sounds like it is the most likely culprit. Even though you are targeting .Net 4.0, .Net 4.5 replaces .Net 4.0 once installed.
Your Windows 7 machine with VS2010 probably does not have .Net 4.5, and therefore is uneffected by the bug.
The working Windows 8 server (which normally comes with .Net 4.5) may have been updated, and therefore already has this hotfix
So the non-working Windows 8 server probably has not been updated with this hotfix yet. (Running the normal Windows updates will eventually get this update as well)
You may want to compare the installed updates on both servers to ensure the environments match.
If you are going to be developing for machines that have .Net 4.5 installed, you want to consider switching to VS2012 or manually installing .Net 4.5 to mirror the changes. But be careful if you also target machines without .Net 4.5, there are other breaking changes...
Visual C# Breaking Changes in Visual Studio 2012
Application Compatibility in the .NET Framework 4.5