Are all the additions to C# for version 4 (dynamic, code contracts etc) expected to run on the current .NET CLR, or is there a planned .NET upgrade as well?
C# 4 will require the .NET 4.0 CLR.
Well, .NET 4.0 will require CLR 4.0; however, it is a little harder to answer what parts of C# 4.0 will work on .NET 2.0/3.x. We can hope that VS2010 will still be multi-targeting(I don't have the CTP "on me" so to speak, so I can't check...). But some of the language features don't seem hugely tied to the runtime (named parameters, some of the COM changes such as "ref") - so I can't think of a good reason why they wouldn't be available when talking to .NET 2.0/3.x. I haven't checked, though.
However, as with C# 3.0, some of the features are tied to the runtime - in particular dynamic.
I need to dig out the CTP and have another play, methinks...
You don't have to wait for 4.0 to use Code Contracts as it runs on .NET 3.5, the download link for the academic preview release is here.
Related
Unity uses Mono in order to achieve multi-platform compatibility.
Because of that it wouldn't make sense to use .NET 4.0 or higher, since Mono does not support them either.
However Mono does support 3.5, in fact it supports most of its features , so I wonder, why does Unity still use version of .NET that is almost a decade old.
I understand that most if not all developers prefer stability and familiarity over cutting edge. I would just like to know what are possible reasons for this decision. Especially since later .NET versions introduced several very nice features.
Compatibility reference for Unity.
According to this site it has to do with the support of other computers. Most computers will be able to run .NET 2.0 but not 3.5. It also runs C# 4, I believe, 5, but definitely not C# 6. For some reason, they're kind of behind on things. I think its because there's little benefit of doing upgrading everything.
.net 2.0 and it's subset is there for apiCompatiblilty that being said it's for using of 3rd party libraries but you can use .net 3.5 features in your code as you have stated that mono supports it for example system.linq, although there is some limitations on it for example some namespaces are not available for example :
system.data , also linq has some constraints on mobile platforms http://forum.unity3d.com/threads/to-linq-or-not-to-linq.223887/
I use C# with the .NET 1.1 Framework for a Windows application. We have a requirement to upgrade it to .NET 3.5.
Is it possible to upgrade the code directly to 3.5 (or)
Should we follow 1.1 to 2.0 to 3.5?
Which method is more suitable?
Simply convert one of your projects to .NET 3.5 and see what happens. I would even suggest to use 4.5 since that will make your code more future proof. Start from the UI project and work your way down.
Usually your code will work. There are quite some adjustments made in the framework, so if you happen to use some deprecated feature, you need to rewrite your code. Usually the compiler sill suggest you what to do or read.
You would probably want to use new features introduced since .NET 1.1, like generic lists, etc. This will need a further review than just converting your code.
This would be a real pain to try to duplicate, so I'm hoping someone has a quick answer...
Suppose I have a .NET 4.0 application, with a reference to a .NET 2.0 library (SharpZipLib in this case). This of course works fine on a normal machine with .NET 2.0 and 4.0 installed.
If the server running this application has only .NET 4.0 and not 2.0 (or 3.0/3.5 etc.), what do I need to do to allow the .NET 2.0 library to run properly?
From what I've read, it looks like I may be able to put in a config setting for supportedRuntime, but I'm not quite understanding what exactly that does.
Will a config setting work, or would only .NET 4.0 libraries function in this environment?
(This is a hypothetical environment - I don't plan on ever having my own servers with 4.0 and not 2.0, but if someone is crazy enough to do it, I want to be able to support them).
Thanks
The CLR can load older assemblies in the .net 4.0 framework.
Here's a good read:
http://msdn.microsoft.com/en-us/magazine/ee819091.aspx
EDIT: updated quote from article. Particularly notice the bold
The .NET Framework 4 runtime—and all future runtimes—will be able to
run in-process with one another. While we did not back-port this
functionality to older runtimes (1.0 through 3.5), we did make sure
that 4 and beyond will be able to run in-process with any single older
runtime. In other words, you will be able to load 4, 5 and 2.0 in
the same process, but you will not be able to load 1.1 and 2.0 in the
same process. .NET Frameworks 2.0 through 3.5 all run on the 2.0
runtime and so have no conflicts with one another, as shown in Figure
2.
From http://neilblackburn.blogspot.com/2009/10/net-framework-40-backward-compatibility.html (and, transitively, http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2009/08/03/installing-net-framework-v4-0-and-running-net-2-0-3-0-3-5-3-5sp1-applications.aspx):
Now, I knew that you can’t just take a 3.5 Service Pack 1 application
and run it on the V4.0 CLR. It needs a V2.0 CLR or reconfiguring with
a <supportedRuntimes/> tag in order to bend the application to run on
the V4.0 CLR and that bending might be something that you don’t want
to do.
From the link in bryanmac's answer (In-Process Side-by-Side):
This means that if an application is recompiled to run against the .NET Framework 4 runtime and still has dependent assemblies built against .NET 2.0, those dependents will load on the .NET 4 runtime as well.
That can mean, however, that there may be bugs due to being run on a different runtime.
If you have the source to SharpZipLib you could just rebuild it as .NET 4.0
Can I add a reference to System.Core.dll (.net 3.5) to a .net 2.0 application and use it
I am trying to use the TimeZoneInfo class which is available in .net 3.5 only, by referencing System.Core.dll
Alternatively, is their an alternate for TimeZoneInfo in .net 2.0
(or a customised class)
No you really should not. You must install 3.5 on the target machine or you will run into unpredictable behavior in the running program. The 3.5 framework including System.Core.dll depend on several bug fixes / features that were added to CLR 2.0 SP1 (this is a part of 3.5 framework). If you run against an unpatched CLR you will be essentially running untested code and will likely hit several bugs.
Scott Hanselman wrote a blog post describing how to run an early version of MVC on the 2.0 framework. He noted that the dependencies on System.Core will probably be OK as long as you are very careful not to call any routines that depend on CLR features specific to 3.0+ (for example, LINQtoSQL).
He rightly plastered the blog post with disclaimers that it is not supported, it very well might not work for you, but he got it to work and if you can, then yay for you.
I'm not sure if you can do this with System.Core.dll, but we have done this before with the Linq2Sql dlls for a .net 2.0 application. .net 3.5 uses the same version of the CLR with new assemblies built upon the .net 2.0 runtime. If you can get all of the dependencies, it might work. As I said, this worked for us with Linq2Sql dlls, but is not guaranteed for all scenarios. (For example, you probably wont be able to get WPF to run on Windows 2000, but you might be able to get Linq to Objects to work)
.net 3.5 runs on .net 2.0 runtime. So you should be able to use it... But referencing a single dll would lead to unexpected behaviour as you don't know all the dependencies system.core.dll have.... I would recommend not to do that...
You can do this, currently doing the same thing for a tool for work - also to utilize the TimeZoneInfo stuff. As long as thats all you're using you shouldn't run into any issues (at least I haven't).
However I'm not entirely sure of the legalities of bundling System.Core with your app. From what I know you're not allowed to.
I ended up utilizing the one from Mono for the tool that uses it.
Why I can use Object Initializers in Visual Studio 2008 Windows projects, etc targeted to .NET 2.0 but cannot - in ASP.NET projects targeted to .NET 2.0 ?
I understand that this is C# 3.0 features, but don't - why this possible to use in .NET 2.0 projects.
Probably because the ASP.Net stuff targeting the 2.0 framework assumes it will run in a mode where it may have to compile some code on the fly. Since it is running in 2.0 mode it will get the 2.0 compiler at that stage (thus anything relying on the 3.0 compiler will fail)
When targeting the 2.0 codebase from a 'normal' project the compilation is done then and there so relying on 3.0 compiler functionality is fine.
When you target the .NET 2.0 runtime, you are also targeting the C# 2.0 compiler. That version of the compiler does not understand the 3.0 features.
Here's an existing question that deals with using C# 3.0 features in .NET 2.0 projects. It explains which C# 3.0 features are available, which aren't and how to use them.
In order to help you with any specific difficulty, we'll need specific details.
The best source of information on advanced featured in C# and how they have evolved from C# 1.0 through 3.0 is Jon Skeet's book. He is here on SO quite often and may even offer some additional insight. However, you really should have the book.
A normal ASP.NET Website compiles on the fly, which means it will use the compiler available to that virtual directory on your web server. If it's set to ASP.NET 2.0, it will use the 2.0 compiler (not the 3.0 compiler targeted to .NET 2.0).
I assume when you convert your website to a web application you WILL be able to target 3.0 and still use some of the 3.0 features. I suggest trying that, I would, but I don't have the time at the moment. Let us know if it works ;-)