I have a .Net 2.0 project that depends on many 3rd party .Net dlls (all of which obviously target .Net 2.0).
If I were to migrate my project to VS2010 and target the .Net 4.0 framework, will my app still build? Or will it complain about the .Net 2.0 dll references and I will have to find .Net 4.0 versions of these 3rd party dlls?
Yes it will work. Make sure that you have both the .NET 2 and 4 FW installed on the machines executing the application.
If you need to use older assemblies with 4.0 (Mixed-Mode) you may need to add the following to <yourappname>.config:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
I had to do this when I attempted to load some old 1.1 assemblies into my Ironpython program (.NET 4.0) and got the following error:
"Mixed mode assembly is built against version 'v1.1.4322' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information."
Adding those three lines to my ipyw.exe.config file let me run those assemblies in mixed mode.
Related
I have a .NET project whose target framework is 4.5.1. This project depends on a NuGet library which only has a .NET 4.0 release and this library in turn depends on MVVMLight:
MyProject (4.5.1) --> Depends on MyLibrary (4.0) --> Depends on MVVMLight (4.0)
The MVVMLight NuGet also has a 4.5 version so when it's installed on MyProject it ends up referencing the 4.5 version (as opposed to MyLibrary which was compiled with MVVMLight for .NET 4.0).
This results in the following compilation error:
5>...\Adorners\CircleAdorner.cs(19,18,19,31): error CS0012: The type 'GalaSoft.MvvmLight.ObservableObject' is defined in an assembly that is not referenced. You must add a reference to assembly 'GalaSoft.MvvmLight, Version=4.4.32.18939, Culture=neutral, PublicKeyToken=null'.
The error is from a class CircleAdorner which inherits from a class defined in MyLibrary which in turn inherits from ObservableObject from MVVMLight.
Is this situation "legal"? Is it OK to reference a .NET 4.0 library from a .NET 4.5.1 project? From my understanding it should be OK. However, the catch here is that the .NET 4.0 project expects another dependency which is not satisfied here.
Also, I noticed that the DLL version of GalaSoft.MvvmLight for the .NET 4.5 is 4.4.32.39728 and not 4.4.32.18939. In the project I marked this reference with <SpecificVersion>False</SpecificVersion> but it didn't help.
Yes it is legal for a .NET 4.5.1 project to use a .NET 4.0 assembly. .NET 4.5 is an in place update to .NET 4.0 and is backward compatible.
From NuGet's point of view if the version of project's target framework is less than or equal to the assembly version in the NuGet package then they are considered compatible. So NuGet will allow you to add a NuGet package that targets .NET 4.0 into a project that targets .NET 4.5. What you cannot do is add a NuGet package that only targets .NET 4.5 into a project that targets .NET 4.0 since the assemblies in the NuGet package may use parts of the .NET framework that is not included with .NET 4.0.
When installing a package NuGet will pick the highest version of the .NET framework that the NuGet package contains that is compatible with your project.
With your GalaSoft.MvvmLight version mismatch you should be able to resolve the problem using one of two options:
Update MyLibrary to use the same version of MvvmLight that your project is using.
Add a binding redirect to your project's app.config for GalaSoft.MvvmLight so MyLibrary's reference to it is mapped to the later version. If you are using Visual Studio 2013 and writing a .NET 4.5.1 desktop application you can enable automatic binding redirects instead of updating your app.config.
I got a some projects that need to be built for both .Net 3.5 and .Net 4 in VS2010.
The projects got different configurations and I edited the project file to include
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
or
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
under each configuration.
This has worked fine in C# projects for a long time but now I need to do the same for a VB.Net project.
The strange thing is in VB.Net where the resulting v3.5 assembly got references to both mscorlib 2.0 and mscorlib 4.0
My guess is the mscorlib 4.0 reference comes from the Microsoft.VisualBasic reference.
So my question is how I can get VS2010 to load the .Net 3.5 version of Microsoft.VisualBasic (8.0.0.0) in one project configuration and the .Net 4 version (10.0.0.0) in another?
Some background on why I need to do this: The project work as plugins in another application. The application can run in CLR4 or CLR2 (older versions) but the plugin need to work with both. If I target .Net 3.5 it will load fine in both CLR2 and CLR4 but the debugger in VS2010 will not work in CLR4. i.e. I need to target .Net 4 for the debug version and .Net 3.5 for the release version.
I'm trying to connect F# to SQL but when i build I keep getting this error
Warning 3 The primary reference "FSharp.Data.TypeProviders" could not
be resolved because it has an indirect dependency on the .NET
Framework assembly "FSharp.Core, Version=4.3.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" which has a higher version "4.3.0.0"
than the version "4.0.0.0" in the current target
framework. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets 1360 9 ConsoleApplication33
Where can I find this version FSharp.Core 4.3.0.0? or is there any other solution?
Are you targeting .NET Framework 4.5? If you target .NET Framework 4.5 and create a new project, Visual Studio automatically makes a reference to FSharp.Core 4.3.0.0 which belongs to F# 3.0.
Somehow, you mistakenly added a reference to FSharp.Core version in F# 2.0 and .NET Framework 4.0. Therefore, first check Target Framework in Project Properties and then add FSharp.Core 4.3.0.0 using Reference dialog (notice there are various FSharp.Core versions).
We have an application that was built using .NET 3.5. There is a situation where it will run on a machine which only has .NET 4.0 installed.
If in the application configuration file the <supportedRuntime> element is not defined, or is defined as follows
<startup>
<supportedRuntime version="v2.0.50727"/>
</startup>
will the application crash on start up since .NET 3.5 and CLR v2.0.50727 are not present?
Note I understand that .NET 4.0 APIs are supposed to be compatible with .NET 3.5 ones and that a .NET 3.5 application should run in .NET 4.0. That is not the question. I am specifically asking about the <supportedRuntime> behavior.
Adding Hans Passant's comment as it seems a suitable answer.
The application will crash. To run on .NET 4.0 you need to add another supportedRuntime attribute with version="4.0".
I want to start testing my project using the Microsoft .Net 4.0 Beta version that has already been released. I know that adding a "net-4.0" target framework to NAnt requires updating nant.exe.config file, does anyone know what are the necessary changes?
If you want to use nant to build projects targeting .NET 4.0 you'll have to modify NAnt.exe.config and add the net-4.0 target framework and add a <supportedRuntime ... /> line to the <startup> section.
http://paigecsharp.blogspot.com/2009/08/nant-net-framework-40-configuration.html is a full code for .config file for NAnt.