Microsoft to release the source code for a hefty chunk of the .NET Framework.

[DreamThrall]

WOW.

http://weblogs.asp.net/scottgu/arch...rce-code-for-the-net-framework-libraries.aspx

 

[Raziaar]

Hmm... I don't know what this means exactly. I don't really care though since I'm only just now learning .NET with C#.

 

[No Limit]

Intersting. Does this mean we don't have to install the .net framework just to run these apps anymore?

 

[Raziaar]

Intersting. Does this mean we don't have to install the .net framework just to run these apps anymore?

Of course you still need the framework. That includes all the standard libraries and stuff that the programs draw from, and the CLR and more.

 

[Cole]

Intersting. Does this mean we don't have to install the .net framework just to run these apps anymore?

No. .NET Framework Programs are not natively compiled. They are Just-In-Time compiled. You will always need the .NET Framework or an equivilant to run them.

Just so happens there is an open source equivlant to the .NET Framework. It's called MONO.
MONO is an open source program that basically does what the .NET Framework does. However, it can also do Java and many other languages. Furthermore its cross platform. MONO can even run Java and C# code side by side. It can also convert Java Byte-Code to .NET CLR.

What does this mean?
Nearly all libraries for the .NET Framework will be released. It will allow developers to make there code work better with .NET Framework libraries and allow bugs in these libraries to be fixed much quicker.

Furthermore it means MONO will get a huge reduction in development times when it comes to implementing the libraries Microsoft never released ECMA specifications for. Such as Windows.Forms

Thats one of the major reasons I wrote programs in C#. Because a single build could run on Mac OsX, Unix, Linux, and Windows via MONO.

 

[Iced_Eagle]

Thats one of the major reasons I wrote programs in C#. Because a single build could run on Mac OsX, Unix, Linux, and Windows via MONO.

And I can write programs in C that run natively without the user having to install anything.

Except most people use Windows functions which breaks that main goal of C, portability.

Also, that's really kickass that MS is releasing that Source code!! Should be a fun time for those of you who are .NET programmers. I personally haven't had much experience with them besides just tinkering with the C# language.

 

[Cole]

And I can write programs in C that run natively without the user having to install anything.

Except most people use Windows functions which breaks that main goal of C, portability.

You can write programs without having users install a one time program, is nice. Very nice.

but, from my point of view one minor inconvient download(considering they don't have Vista) is worth it for me:

I just like the ability to have a far better debugger, IDE(Autocomplete in VS2k5 C# is amazing vs any other version), quicker development, and a single cross-platform build.

Of course it's all up to preference. I probably would have stuck to C++ if VS2k5 C++ Express had a resource editor. The nice thing about C# is once you learn about marshaling, you have direct control over memory(creating/deleting/casting/pointers). I was missing that so much when I first moved from C++ to C#.

 

[DreamThrall]

The nice thing about C# is once you learn about marshaling, you have direct control over memory(creating/deleting/casting/pointers). I was missing that so much when I first moved from C++ to C#.

What? One of the biggest advantages of using a CLR language/managed code is that you DON'T have to worry about memory management. Why waste time on that when you could be spending it developing useful features for your app?

http://msdn.microsoft.com/msdnmag/issues/1100/gci/

 

[Raziaar]

What? One of the biggest advantages of using a CLR language/managed code is that you DON'T have to worry about memory management. Why waste time on that when you could be spending it developing useful features for your app?

http://msdn.microsoft.com/msdnmag/issues/1100/gci/

Some people like to be able to control everything. Me for one, I don't know jack crap about manual memory management so I am really starting to enjoy C#.

 

[DreamThrall]

Some people like to be able to control everything.

I know, but if that's the case, what's the point of using C#? Seems to me it would make more sense to use C++.

Me for one, I don't know jack crap about manual memory management so I am really starting to enjoy C#.

Indeed!

 

[Cole]

What? One of the biggest advantages of using a CLR language/managed code is that you DON'T have to worry about memory management. Why waste time on that when you could be spending it developing useful features for your app?

Excellent point. I would agree with it up to a certain extent. I hate having to resize strings manually in C++, and small annoying things like that. C# does an amazing job at covering all that up and letting the GC handle it. Thats why I love C#, it covers up all the small annoyances that I don't really care about. However, there are many things I do care about. (Below)

The GC is not perfect. There are times when speed is an absolute must, and I need to use pointers. So I throw managed buffers into fixed code, and utilize pointers. Things get incredibly complex when all is said and done, I notice I have a huge memory usage. Using fixed statements inside loops and multiple threads leaves the GC in a mess and often causes it to forget about unmanaged data that its suppose to delete(it leaks). Marshalling comes into play here. I'll dump everything into a few statements, and manually control the data. Not only will there be speed improvements, but i've cut memory usage due to this kind of leak from 900 megs to 300megs (300 starcraft maps loaded into memory, cut into each seperate header, and saved into buffers).

Theres also another important aspect, and the main reason why marshalling was created! Working with native dll's. Passing a managed buffer into a native dll? Not good. Passing a fixed buffer has huge downfalls to, as I talked about above. Want to create a pointers that can be passed into native dll's? Wanna turn strings into sbytes(LPCSTR) for native dll's to handle?

The GC is great for handling all the little things that I could care less about, and really makes handling arrays easier. It's geat when speed isn't needed, but functionality is. However, big algorthims spanning multiple threads will screw it up. Handling memory by yourself is an absolute must in this area if you want speed and low memory usage.

One of the biggest advantages of using a CLR language/managed code is that you DON'T have to worry about memory management.

.NET is a very fast framework. When the code is finally compiled, it executes at the speeds of C++. However, you must understand something, your statement is right but this is also true:
One of the biggest disadvantages of using a managed language is that you DON'T have direct control over memory.

Microsoft understands this. This is why the .NET Framework supports both managed and unmanaged code. Furthermore C# integrates them in a well done professional manner. It allows you to focus on rapid development and keeps memory management out of your way. However, the option is always there for you to control memory when you need to. C# gives you the best of both worlds in one awesome package.