What can be the issues if I build a solution where all the projets are under targetFrameworkVersion=2.0 but one with targetFrameworkVersion=3.5 and
None of the 3.5 features are used
Some of the 3.5 features are used but the classes calling the 3.5 code are never instanciated
Some of the 3.5 features are used in some classes, the classes are instanciated but the code in 3.5 never called
the 3.5 code is called
It depends on what you mean by "features". There are compile-time features like the var keyword and lambda expressions and there are run-time features like LINQ or WCF that require libraries in the .NET 3.x runtime.
I assume you're using Visual Studio 2008, which will handle all the compile-time features. If all you're using is the compile-time features, then everything will work fine in all cases. I do this rather often on my current project.
If you're using run-time features then I believe this is how it will shake out:
Things will just work.
I think this will just work also.
It depends on when static functions are JITted and if you have any 3.5 library referencing code in static functions.
Probably MissingMethodException when a function containing a 3.5 library feature is called.
Rather than worry about all of this, if you're planning on using run-time features, I would simply add a key to the App.config that the 3.5 runtime is required and it'll check on startup and bomb if it isn't present. Then you don't need to figure out all these permutations and your application will be more stable.
First of all, you need to be aware that what you are targeting is actually .NET 2.0 SP1.
How are your projects related? Do you have projects that are built under .NET 2.0 which reference the .NET 3.5 project (or vice versa)?
Related
I've inherited an app. The app has to use .NET 2.0. However, I would like to make use of a feature introduce in C# 4.0 (optional arguments). I understand that a framework is separate from a language. However, what I'm not sure of is, can I use this C# feature in the context of .NET 2.0?
The code compiles. I wasn't sure if this was legitimate, or if I just got lucky :).
Thank you for your insights.
Optional arguments/parameters have been supported in CLR since CLR 1.0. This is due to CLR support for VB.net.
This is why your code compiles. Other new 4.0 features may not work the same.
Other post-C# 2.0 features that will compile into a .NET 2.0 application include named arguments, lambda expressions, auto properties, & extension methods.
I have a .net 4.0 project in which I'd like to reference .net 2.0 assemblies. As I understood from this article, .net 2.0 assemblies will be loaded in 4.0 run time and backward compatibility is not assured. Is there a way to force process side by side for this case and to load 2.0 runtime?
In process side-by-side versioning is only supported for code that runs independently without having to share data. In particular for native code that loads the CLR to execute managed code. It is a solution for the CLR versioning problem, once an unmanaged program like Explorer loads the CLR, say to support a shell extension written in .NET then the CLR version is selected by whatever version that extension asked for. Which works poorly if another extension then needs a later version of the CLR. .NET 4's side-by-side versioning feature solves that, each extension gets its own CLR. No sharing of data is required, these extensions don't know about each other.
Clearly this isn't a solution for what you are trying to do. Microsoft made a lot of effort to make .NET 4.0 as compatible as possible with previous .NET releases and loading .NET 2.0 assemblies is certainly well supported. Up to a point, they did use the opportunity to fix several old bugs whose fixes could be breaking to old code. Technically it is possible that your 2.0 code relied on the behavior of such a bug, it is however not very likely. You just need to re-test your code.
I have a dll which is based on .net 3.5 -- it uses internally for example Linq, but the exposed API is straightforward, no fancy stuff. Since C# generics are resolved at compile time I assume that for calling party all it counts is API (all public parts).
However when I try to use this dll from net2.0 project I get info, that the dll cannot be referenced because the dll or one of its dependencies requires a later version of .net framework.
I can install any .net version I want on target computer (when entire app is installed), but I cannot change .net version for the project itself.
So: how to solve this? When adding a C dll to this project I had no such problems, so are C# dlls self-contained or not?
C# dlls need to have the .Net runtime to run as they are not compiled down to machine code. In this case the dll says it requires Net 3.5 so all your project will have to use 3.5 or higher.
To keep your project as Net 2.0 you would need to build another executable to contain the 3.5 DLL and communicate across separate processes.
The C DLL worked as it is compiled down to native code and does not require the .Net framework. (or at least not version higher than 2.0)
I've been using System.Core and the new System.Web.Extensions (for example) from 3.5 in an ASP.NET 2.0 app (using VS2005) for a while now with no problems. Similar to what Scott Hanselman blogged about here. So yes, it's possible.
.NET 3.5 still runs on the same CLR as .NET 2.0. So at runtime it's all the same. (Assuming you've tracked down any dependencies and copied those 3.5 DLLs to your bin folder as well.)
The only real limitation is what C# language features you can use at development time. Such as 'var', extension methods, or LINQ query syntax.
If you are using linq to objects, then you can use Linq Bridge:
http://www.albahari.com/nutshell/linqbridge.aspx
this is a Linq to objects implementation for .net 2.0.
You will still have to compile using vs2008 but you can compile with .net 2.0 as a target platform in that case.
(This is because the C# 3 compiler understands linq clauses even if you target .net 2.0, it will simply resolve the calls to linqbridge instead of the .NET 3.5 libraries in this case)
If you're using .NET 3.5 libraries then your application's requirements should be such that any consumer of it's API's should also be using .NET 3.5.
The only way you can bypass this is if you package all the dependencies of your application along with it. This means libraries your application uses which depend on the .NET 3.0 and 3.5 frameworks.
However, I'm not sure of the legality of ripping out chunks of the .NET frameworks and packaging them with an app. I'd read the EULA before doing anything like this. IMO, it's not worth the hassle; just install 3.5, ask your users to install 3.5 and be done with it or use only 2.0 features and libraries. At the very least, hacking around like this will only cause you more pain with deployment if there are framework updates in the future.
In either case, your app will work on .NET 2.0 as 3.0 and 3.5 are just extra libraries on top of the 2.0 runtime and libraries (as Craig mentioned) as long as all your dependencies are there.
C# DLLs are not self-contained. If your 3.5 DLL needs LINQ, it depends on system assemblies from the 3.5 (3.0 to be exact) framework, therefore the entire application depends on this version.
You could load the 3.5 assembly dynamically and use reflection to get access to the functions you need. This requires some overhead, of course.
Nothing pretty but there are ways to get the code happily working together (in the order of preference):
1) Upgrade both projects to 3.5
If I understand you correctly then your .net FW 2.0 Program will have dependency on 3.5 Library, which means for every functionality of the Program to work, it now requires FW 3.5. Since you state to have the code and authority to recompile the the Program AND install whatever FW on deployment, then you can upgrade it to 3.5. Sounds simple, but since you did not do this, then I guess you have good reasons (like other programs being higher up the call chain which you cannot upgrade to 3.5/recompile.)
2) Go around the FW2.0 compiler
Build the Program when referencing the 2.0 version of Library (or dummy, just providing the public API).
Build the 3.5 version of Library separately without Program (hence removing the need to reference the wrong FW assembly) and deploy the 3.5 version instead of the 2.0 version.
Since 2.0 and 3.5 use the same CLR runtime then fooling the compiler is enough. As long as the deployment maching has FW 3.5 installed, everything should be fine.
Note: everything is fine even if you have just .net 2.0 present on deployment machine and the user does not call .net 3.5 classes. If he does, there will be crash ;)
3) downgrade Library to 2.0
if you use only some classes of the .net FW then you could remain using the 2.0 compiler by adding those missing future assemblies to project. (this is the solution from Hanselman link shared by Craig). As already noted, you'll lose 3.5 compiler's syntactic sugar like vars.
Choose whichever suits your situation best.
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.
This should be fine seeing as the CLR hasn't actually changed?
The boxes running the C# 2.0 code have had .NET 3.5 rolled out.
The background is that we have a windows service (.NET 2.0 exe built with VS2005, deployed to ~150 servers) that dynamically loads assemblies (almost like plug-ins) to complete various work items asked of it. Whenever we roll out a new version of the bus logic, we just drop the assemblies on an FTP server and the windows service knows how to check for, grab and store the latest versions. New assemblies are now built using VS2008 and targetting .NET 2.0, we know that works ok. However we'd like to start taking advantage of C# 3.0 language features such as LINQ and targetting the assemblies against .NET 3.5 without having to build and deploy a new version of the windows service.
C#3 and .Net 3.5 adds new assemblies, but the IL is unchanged.
This means that with .Net 2 assemblies you can compile and use C#3, as long as you don't use Linq or anything else that references System.Linq or System.Core
yield, var, lambda syntax, anon types and initialisers are all compiler cleverness. The IL they produce is cross-compatible.
If you can reference the new assemblies for 3.5 it should all just work.
There is no new version of ASP.Net - it should still be 2.0.50727 - but you should still compile for 3.5
yield, var, lambda syntax, anon types
and initialisers are all compiler
cleverness. The IL they produce is
cross-compatible.
Minor nit-picking point, but yield was a 2.0 feature anyway.
This is interesting stuff. I was looking at LinqBridge yesterday after someone on this forum suggested it to me and they are doing a similar thing.
I find it strange that Microsoft named the frameworks 2.0, 3.0 and 3.5 when they all compile down to produce the same IL required by the 2.0 CLR. I would have thought adding versions onto 2.0 would have made more sense altho I suppose it also is hard to get people to get their head around the fact that there are different versions of runtimes, compilers and languages.