Windows API and .net Languages

Question

People have always told me that if I am making some kind of application that needs to use some Windows APIs to perform any process level task, I should use VC ++, and not some other .net language.

Is there any truth to this?

Is it possible to do everything that can be done using VC ++ in other .net languages?

Are all .net languages ​​the same when comparing their features?

Answer 1

If you need to work well with native code, C ++ will probably make life easier. However, there is nothing wrong with using P / Invoke to call the Win32 API from C #, VB.NET, F #, etc.

Not all .NET languages ​​are the same in terms of features, although C # and VB.NET are pretty much equivalent in functionality. I know that there are some things that C ++ / CLI provides that are not displayed by C # or VB.NET. I do not know if the opposite is true. (I do not know what C ++ / CLI is, as for lambda expressions, extension methods, etc.)

Answer 2

For most tasks where class libraries don't provide help, using P / Invoke is usually great. There are many rough APIs that benefit from a simple C ++ / CLI shell. It's usually best to do minimal code in C ++ / CLI code - effectively massage what ever ugliness is lower for consumption in C #, VB.NET, etc.

Answer 3

When I started programming in .Net, I used C ++ / CLI, since I came from a minimal Win32 C ++ background. I found that I am having headaches because I do not understand the fine lines and boundaries between C ++ / CLI and Win32 C ++. It is not as simple as it seems, they interfere between them. When I found out about P / Invoke and made my life a lot easier, I finally began to develop my skills. P / Invoke is just fine, and you don’t need C ++ / CLI to do this. In my opinion, you either use Win32 C ++ completely for low-level materials, or .Net for high-level materials, and I really do not recommend ever trying to interact with Win32 C ++ with C ++ / CLI, unless you absolutely need to . Even then its probably just to make a Win32 DLL with what you need and P / call the DLL from .Net or vice versa. Always remember to choose the right tool for the job.