I have external .net library compiled with .net framework 4 (it's provider moved recently to .net 4)
My code currently runs on .net framework 3.5
How to use that external library in my application ?
Moving whole application to .net 4 needs time and testing, so maybe in a future i will do that, but now, what are the possibilities ?
There are no possibilities, the CLR version that comes with .NET 3.5 cannot load 4.0 assemblies. The metadata format was changed. You have to force your app to use the .NET 4.0 CLR version. Do so by recompiling it with VS2010, targeting 4.0, or by using a .config file that contains the <requestedRuntime> element to ask for "v4.0".
Compatibility for .NET 4.0 is excellent btw.
While you cannot load the .Net DLL directly, you can wrap it in a COM interface, and load that COM interface in your .Net 3.5 process.
See Using a .NET 4 Based DLL From a .NET 2 Based Application
For more background information, Microsoft originally added In-Process Side-by-Side in .Net 4 to better support the scenario where an application loads add-ins via COM, and the add-ins were written with various versions of .Net. The ability to load .Net 4 DLLs in a .Net 3.5 process is just a nice side effect of that.
Related
We have a large & complex system running under .Net 4.0. We want to start introducing code written for .Net 4.5, but can't (yet) assume that .Net 4.5 is installed on all the developer machines, build machines and test labs. So I'm looking for a way to compile certain projects in MSBuild using assemblies which are available on disk, on machines which have only .Net 4.0 installed.
Per the documentation it seems possible. The 4.5 reference assemblies are available in the msbuild environment, and I've been experimenting with the TargetFrameworkVersion, FrameworkPathOverride and TargetFrameworkMoniker attributes, but so far without success.
Any hints, suggestions or working samples would be most helpful.
To build a .NET Framework 4.5 application, you must also have the .NET Framework 4.5 reference assemblies.
Installation
The .NET Framework 4.5 replaces the common language runtime (CLR), targets, tasks, and tools of the .NET Framework 4 without renaming them. Essentially, it creates a modified and improved .NET Framework 4.
In an attempt to oversimplify my issue, I'll try to keep it short:
I'm using the pro version of Unity, and I have 2 DLLs:
A .NET 3.5 assembly (acting as a COM client)
A .NET 4.0 assembly (with an interface exposed via COM)
The 3.5 uses COM to work with the 4.0. Using the 3.5 assembly in a Windows app works fine, it loads the 4.0 dll using SxS via Type.GetTypeFromCLSID() or Type.GetTypeFromProgID() (which I've confirmed with SxStrace), and can use it's functionality just fine. (The windows app mentions it's dependency on the 4.0 DLL via a manifest, I'm not registering the COM DLL.)
I'm trying to use the .NET 4.0 DLL in Unity. Obviously I can't use it directly, since the current flavor of Mono that Unity uses only supports up to 3.5, thus I created the 3.5 assembly to be my middleman. I'm able to use the 3.5 assembly fine in unity, but either of the Type methods I mentioned before throw NotImplementedException(s), as apparently they aren't supported by Unity (or rather, Mono), so I'm at a loss.
Any ideas?
Although this question was made 1 year ago..sadly the middleman tactic still wont work, it is not possible to use .NET 4.0 dlls within Unity3D since Mono is just not supporting the dependencies.
You could try to remove any 4.0 dependencies from the dll and compile it as 3.5, if that is possible for you.
I have an app that I've upgraded from 3.5 to 4.0. But not all my 3rd party assemblies are built on .net 4.0. How is it that I'm still able to reference those assemblies without any problems? For instance, if another assembly references system.dll 2.0, and my upgraded project references system.dll 4.0 how does .net handle this?
Obviosly this wasn't a problem upgrading between 2.0 and 3.5 because they use the same BCL and CLR versions, but 4.0 uses a completely different BCL and CLR right?
Here's an example. I have an app built using WF (Windows Workflow) in v3.5. I've upgraded the app to v4.0, but I wasn't required to implement all the breaking changes in the new version of workflow. It still using the old 3.5 version of WF.
.NET 4.0 can reference .NET 2.0 assemblies, but the reverse is not true.
.NET 4.0 assemblies support everything that 2.0 had, but adds in things like optional parameters, dynamic types, and etc...
So, since 2.0 doesn't have anything that 4.0 doesn't, 4.0 can easily support 2.0.
BCL and CLR are different but not completely different. Basically they worked hard to not break backwards compatibility.
You could also force your 3rd party assemblies to run under 3.5, as described in this post.
Do Silverlight 4 applications require that they target .NET 4.
With the delay in .NET 4 and Visual Studio 2010; can I still get the advantages of Silverlight 4 running against the .NET 3.5 framework?
Silverlight does not require any version of .NET (or, put another way, it includes its own sorta-kinda version of .NET; at any rate, it doesn't need any version of the full .NET runtime). It is a completely independent runtime.
Presently .Net 4.0 is not supported on Azure.
This thread indicates that you will not be able to use .Net 4.0 with VS 2010 until it is supported in the cloud.
http://social.msdn.microsoft.com
I'd like a way to start developing Azure applications locally utilizing the new features of .Net 4.0. I am fine with not being able to deploy these applications until Azure officially supports it.
From within the VS IDE; I tried replacing .Net 3.5 application references with newer .Net 4.0 references and Visual Studio crashes.
Does anyone have any suggestions?
Thanks,
Paul
An update to this old thread. .Net 4.0 has been supported since Azure SDK 1.2
Some features from .NET 4.0 can be added to your application through other means. For example, the recently-released Reactive Extensions for .NET 3.5 SP1 includes a back ported release of Parallel Extensions. And the Managed Extensibility Framework contains the Lazy class and Tuple struct. As long as you set "Copy Local" to true on any libraries that you add, your application should run (and deploy) successfully.
Obviously, these aren't all the features that are new in .NET 4.0, and not all of them will can be ported back to .NET 3.5 like these can.