A first hand look from the .NET engineering teams
It’s a great way to start a new year: the PYPL index has named C# the language of the year. This index focuses on the leading indicator of learning a language. It’s nice to see that there’s been increased interest in C# over the past year. In the spirit of learning something new, here’s what we suggest you check out if you’re looking to learn a new C# trick.
What new C# skill would you recommend everyone learn? Share your thoughts in the comments.
There are few changes to come in C# to become best. Threading is not so good in C# compare to Java (I worked on both), I would like to see more improvement in it. The best improvement in C# that I can see is Async programming.
Async, and LINQ are really awesome improvement and pay back in longer run from day one.
Language of the year 2011? If you look at the stats, they show the change from Jan 2011 to Jan 2012.
Yes, I believe this about 2011, not 2012.
This would include VB programmers who know that .NET examples will be in C#
>Learn to build (or use) cross-platform libraries
This is so hypocritical. The recent changes are making C# a lot LESS cross-platform.
1) Making Windows Phone games in C#? XNA was discontinued.
2) Making XBox 360 games in C#? XNA was discontinued.
3) Want to make Windows Store games in C#? XNA is not supported.
I'll repeat: MAKING GAMES IN C# IS NO LONGER SUPPORTED BY MICROSOFT. They force you to use C++ now.
4) Making C# browser apps? Silverlight was killed!
5) Making C# browser apps for Mac OS X? Silverlight was killed!
6) Pure .Net is now being forcefully chained to Windows. Looks like the .Net's portablility cros-platform support became an unwanted success for Microsoft.
P.S. Making Windows Runtime components in C#? You cannot even use generics, inheritance, overloading. Pathetic!
@Fduch, I understand that you're unhappy about some issues with libraries. However, the information you state is inaccurate. Making games with C# is possible and indeed commonplace. You can use Process Explorer (from the Sysinternals TechNet site) to look at the .NET appdomains and assemblies loaded by different processes. Doing so, you'll find that many of the games in the Windows Store catalog are using .NET. I just loaded the Solitaire game from the Windows Store and see that it's using the SharpDX libraries. This is an indication that the game was written with C# and is using the DirectX library.
So, to summarize WRITING GAMES WITH C# IS SUPPORTED BY MICROSOFT.
The concept of writing portable class libraries is the ability to use a single binary across multiple platform profiles that have different set of assemblies. I encourage you to read the article I linked to above that describes portable class libraries in more detail.
I have done a lot of research on the "Games in C#" thing, so I thought I would post it for others:
Both Fduch and Brandon Bray are correct. But without the details are they seem to contradict.
Brandon states that making games in C# is supported by Microsoft. That is true. XNA is an easy way to make a C# game. You can post a new XNA game on the Windows Store and it will work fine.
However, you cannot make a Windows Phone 8 or Windows 8 game using XNA. (You can only target version 7.1) The new APIs for these operating systems are not supported in XNA (I believe this is what Fduch was pointing out). However, both Windows Phone 8 and Windows 8 will run XNA apps made with the older APIs.
So to sum up. XNA supports the older API that will still run on Windows 8, but you can't use the newer stuff. Microsoft does not have an offering to make games in C# for the new Windows 8 and Windows Phone 8 APIs.
However, if you don't mind using open source projects there are some things you can do to write a game in C#:
If you want to use XNA's api to make games for the new Windows 8 APIs you can use MonoGame (this is what I use). It is an open source api that implements the XNA API but has plugins for IOS, Android and Windows 8. This is a really good cross platform option. However it does not have much more than 2D support. (Note: I am not affiliated with MonoGame in any way.)
SHARP DX (DirectX)
If you want a Microsoft Supported way to make a game that targets the Windows 8 API your best bet is DirectX. But Direct X is a C++ API. It is also really really hard.
If you are wanting to make a 2D game (like Plants vs Zombies or Angry Birds) then Direct X is overkill. You are far better off going the MonoGame route. I spent several days digging through tutorials and working very hard to understand Direct X. By the end of that time I was rewarded with the ability to draw a single triangle on the screen. (That same amount of time had my game loop going and sprites moving around in MonoGame.)
So I repeat, if you don't already know DirectX and you are making a 2D app, don't go down the DirectX/SharpDX road.
The DirectX 2D route is further hindered by Windows Phone 8 not supporting Direct2D. DirectX has a subset called Direct2D for 2D rendering. However, this subset is not supported on Windows Phone 8. The "replacement" (for now) is the Direct X toolkit.
If you are still all in with the Direct X road, then you can write it in C# using SharpDX. It is a C# wrapper for DirectX that works very well (though I don't know if it supports the Direct X Toolkit).
The short of it (for me) is that Microsoft did not update their APIs for C# game development to support the new stuff in Windows 8 and Windows Phone 8. But MonoGame lets you use the XNA API to do just that. It also allows you to write cross platform games, so it is better anyway. (You get porting to IOS and Android for "Free".)
My game is well underway in MonoGame with no issues so far!
NET is overall good platform, but there are some dark sides that must be fixed.
- Garbage collector. Forces programmers to using bad practices, decreases speed and increases memory conspumtion (when lot of unused objects waits for GC). Should be able to disable GC at object or application level.
- Runtime type check. For most cases, design time type check is enough. Should be able to disable runtime check for some types.
- Assemblies/code generation. Currently generated executables contain IL and metadata, which is not necessary in most cases. Using ngen or jit to generate native code, is problematic and time consuming at client side. Obfuscating IL code is also problematic and expensive. Programmer should be able to determine, when generated executable/assembly must contain final native code, IL, metadata.
Great changes, but also great benefits.
yes it is
Due to some important change
spirit of learning c#