.NET phobia (only for the elite coders, ahaha)

[258456]

So i made an app in c# the other day cuz i was starting to get into c#, but i was so upset with myself. It was so easy to make an email spammer it was ridiculous. I also made an app that connected to my c++ server app and put the welcome message in a messagebox and this all took me like 5 or 6 lines of code. I felt cheated. Like it was cool, but it was so high level i was really upset with myself. Does anyone feel the same?

That's why i returned to coding c++ win32 api windowed apps. Cuz it's so low level i like it. I feel like i control everything that happens. But i would love it if there was some way to physically place buttons and drag them to the position you wanted it instead of having to guess the coordinates. Other than that i love the winapi.

[Jason]

So i made an app in c# the other day cuz i was starting to get into c#, but i was so upset with myself. It was so easy to make an email spammer it was ridiculous. I also made an app that connected to my c++ server app and put the welcome message in a messagebox and this all took me like 5 or 6 lines of code. I felt cheated. Like it was cool, but it was so high level i was really upset with myself. Does anyone feel the same?

That's why i returned to coding c++ win32 api windowed apps. Cuz it's so low level i like it. I feel like i control everything that happens. But i would love it if there was some way to physically place buttons and drag them to the position you wanted it instead of having to guess the coordinates. Other than that i love the winapi.

No way. There's a reason C# is becoming something of an industry-standard these days and that's because of RAD (Rapid Application Development). Sure, you can't access memory directly (In the general sense, you can access unmanaged memory directly but it's a pain), or do all sorts of pointer magic and cool low-level operations, but you can always write a native C++ library and use PInvoke to do the low-level stuff for you. C/C++ is still needed when you need to do something that requires low-level functionality, or where absolute efficiency is paramount, but for real-world application development, building a multi-step form in C/C++ is just not practical given the normal business constraints: Time and Money. No business-manager is going to be happy when you spend 100 hours building your whole application in C/C++, only to find out that if you'd just sucked it up and written it in C# it could have been achieved in 20, or even 10 hours.

There are a time and a place for all languages; I think people SHOULD learn C/C++ at some point in their life (or another low-level language similar) if only to really learn what goes on 'behind-the-scenes' in a higher level language, but clinging to C/C++ for everything isn't practical. Now that I grasp at least the basics of C/C++ I have no qualms about doing the majority of my coding in C#; why should I have to write everything myself when it already exists? If I had to, I could write the functionality myself, but I don't see the point when Microsoft has done it all for me in the .NET framework.

Even in C++ you find that you use all sorts of prebuilt libraries (hint 'Windows.h', 'stdio.h', 'stdlib.h'). Just think of the .NET Framework as a much bigger and more complete package.

[258456]

No way. There's a reason C# is becoming something of an industry-standard these days and that's because of RAD (Rapid Application Development). Sure, you can't access memory directly (In the general sense, you can access unmanaged memory directly but it's a pain), or do all sorts of pointer magic and cool low-level operations, but you can always write a native C++ library and use PInvoke to do the low-level stuff for you. C/C++ is still needed when you need to do something that requires low-level functionality, or where absolute efficiency is paramount, but for real-world application development, building a multi-step form in C/C++ is just not practical given the normal business constraints: Time and Money. No business-manager is going to be happy when you spend 100 hours building your whole application in C/C++, only to find out that if you'd just sucked it up and written it in C# it could have been achieved in 20, or even 10 hours.

There are a time and a place for all languages; I think people SHOULD learn C/C++ at some point in their life (or another low-level language similar) if only to really learn what goes on 'behind-the-scenes' in a higher level language, but clinging to C/C++ for everything isn't practical. Now that I grasp at least the basics of C/C++ I have no qualms about doing the majority of my coding in C#; why should I have to write everything myself when it already exists? If I had to, I could write the functionality myself, but I don't see the point when Microsoft has done it all for me in the .NET framework.

Even in C++ you find that you use all sorts of prebuilt libraries (hint 'Windows.h', 'stdio.h', 'stdlib.h'). Just think of the .NET Framework as a much bigger and more complete package.

Ya for sure bro. I totally agree with you. Just because it's really high level doesn't mean it's any less professional. It's just that i got bothered that stuff was so easy. And i think i will start doing pinvoke to call c++ functions. I never knew about that. Could you show me how to use pInvoke? Thanks Jason.

[Jason]

Ya for sure bro. I totally agree with you. Just because it's really high level doesn't mean it's any less professional. It's just that i got bothered that stuff was so easy. And i think i will start doing pinvoke to call c++ functions. I never knew about that. Could you show me how to use pInvoke? Thanks Jason.

Well it'll take some work both in C++ and C# to get it working correctly.

In C++ you'll have to mark the methods you want to export at "dllexport", and then use the extern "C" declaration to stop name mangling by the compiler:

#ifndef DLLEXPORT
    #define DLLEXPORT extern "C" __declspec(dllexport)
#endif

DLLEXPORT void Derp(int i) { }

So your function will be exported with the name "Derp". However, if you're declaring any methods as stdcall rather than cdecl, you'll need to be aware that VC++ will mangle the names regardless. It will be in the format <originalname>@<numberofbytesofarguments>

So if i declared Derp as:

DLLEXPORT __stdcall void Derp(int i)

The exported name would be "Derp@4"
The easiest way to get the correct name is to just use a PE explorer and look at the 'exported functions' table.

Now, name in hand, you can go to C#.

using System.Runtime.InteropServices;

[DllImport(@"pathtoyourdll",<optionalarguments such as calling convention can go here>)]
public static extern void Derp(int x);

Now, with a stdcall it gets a little bit more tricky because of the name mangling. I don't have an IDE so i can't verify this right now but it should go along the lines of:

[DllImport(@"pathofdll", EntryPoint = "Derp@4", CallingConvention = CallingConvention.StdCall)]
public static extern void Derp(int i);

You can specify the entry point explicitly for all PInvokes, but I don't usually bother unless the name has a special symbol in it.

[258456]

omg that's a real pain.

[Jason]

omg that's a real pain.

Not when you get used to it. It's pretty much how all dependencies have to work (from the C++ side of things), mark the function as external so that it goes into the EAT of the PE so it can be found by external programs. Pretty quick and easy with PInvoke.

[258456]

Not when you get used to it. It's pretty much how all dependencies have to work (from the C++ side of things), mark the function as external so that it goes into the EAT of the PE so it can be found by external programs. Pretty quick and easy with PInvoke.

I guess so, well thanks for the info. Atleast it's possible to do it. Thanks Jason.

---------- Post added at 08:00 PM ---------- Previous post was at 06:47 PM ----------

EDIT:

Also, i added my dll as a reference in my c# project, but does that still mean that i have to add the dll with my app let's say if someone needs the program?

[Jason]

I guess so, well thanks for the info. Atleast it's possible to do it. Thanks Jason.

---------- Post added at 08:00 PM ---------- Previous post was at 06:47 PM ----------

EDIT:

Also, i added my dll as a reference in my c# project, but does that still mean that i have to add the dll with my app let's say if someone needs the program?

You don't add native dlls as references. Although the references ask for a DLL, they mean a .NET dll to import functions from, not a native C++ dll. You can use ILMerge to merge your dll with the exe though.

[258456]

You don't add native dlls as references. Although the references ask for a DLL, they mean a .NET dll to import functions from, not a native C++ dll. You can use ILMerge to merge your dll with the exe though.

And is ILMerge a separate program? or a class in c#?

[[MPGH]master131]

It's a seperate program...

[Jason]

And is ILMerge a separate program? or a class in c#?

ILMerge is a microsoft command line tool to merge .NET assemblies. I'm not 100% sure if you can merge native .dlls with a .NET dll, but I haven't tried. You should already have ILMerge on your computer, just do a search for it.