But what's our problem with the .NET Framework? We can think of a few. As a matter of fact, we will list them, report-style.
Source code security
The .NET Framework is not very secure when it comes to protecting your source code. Sensitive data and routines such as password generation, license validation, etc can be easily, and I mean easily, modified with 3rd party tools that a computer novice can get started with. Why is this so? Because Microsoft did not add an option to natively compile your source code. Instead, Visual Studio converts your source code to a weak Intermediate Language form. I call it weak because it can be easily, and again, I do mean, easily, converted back to C# or VB code. So, with that in mind, we can see how hackers/crackers and even competitors can easily decompile your code, and modify or steal your algorithms and data.
.NET Framework as a dependency
The .NET Framework is big. Very big, if you normally distribute 5mb software installers like us and therefore, is a liability. Why? Imagine distributing an application you developed in VB or C# which is about 1mb in size. Not a problem right? No. If you used the .NET Framework, you just supersized your setup file by about fifty times. That's right, the .NET Framework ranges from 50mb to 200mb depending on its version and machine architecture. Imagine asking people to download that!
Of course, most computers around the world have .NET Framework installed by default. However, the problem is that they are usually different versions. For example, Windows XP users may find themselves with no .NET Framework by default. Windows 7 users may find themselves having .NET 2.0 and 3.0, but not 4.0 or 4.5. Windows 10 users may have .NET 4.6 or 4.5, but not 2.0, 3.0 or 3.5. As you may have infered, there are in total, around seven different versions of the framework, and they are all scattered around the world on computers that run differing versions of Windows.
This problem exists because, for some reason, versions of Windows only include the latest versions of the framework at that time. This is good in a forward thinking context, but very bad as they do not support programs compiled against older versions of .NET. This leads to the downloading and installing of a 100mb runtime, for every new user that uses software made on older versions of .NET: and trust me installing the framework is not a quick process.
Installing the .NET Framework may be quick initially. However after the framework is installed, you may see a process called mscorsvw.exe running in the background, eating away at your CPU. This is because it is preparing and also natively compiling the entire runtime! Besides downloading the framework, and installing it, the framework will also need to compile itself! The total process can take from five minutes to an hour depending on the computer's specifications.
So why Microsoft? Why won't you just make a native compiler that complement's .NET's application development productivity? Why won't you just make it possible that can statically link desktop applications against the .NET libraries so that it does not have to be shipped with it. Why won't you include support for previous versions of .NET on newer versions of Windows? If you did those things, VB/C# would definitely be the #1 development languages of choice for programmers around the world!
So in conclusion, we do not recommend you to develop on the .NET Framework if you intend to target end users. Although development on the .NET Framework is easy, rapid and effective, the framework itself possess liabilities that, in our opinion, outweigh all those perks. Stick to Delphi, C++ Builder or even Visual Basic 6. Those programming languages have a lot of support from the online community and builds native programs that you can easily ship on a floppy disk or two.