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.
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.
According to MSDN documentation,
public static Assembly LoadFrom(string assemblyFile)
throws BadImageFormatException if
assemblyFile is not a valid assembly.
-or-
Version 2.0 or later of the common language runtime is currently loaded
and assemblyFile was compiled with a later version.
Actually, there is one extra case - loading assembly that is built for x86 from assembly that runs in x64 mode. Maybe it is included in "not a valid assembly" statement, I don't know. But this is reasonable cause of exception.
Ok, but in .NET 4.5 it doesn't! I have a .NET 4.5 WPF app, that loads different appliations for some reason. It is building for Any CPU and I'm starting it on x64 Win 7. I've been testing it on one executable, that is built for .NET 4.0 x86, and it worked fine. But when I switched my app to .NET 4.0 it began to crash on Assembly.Load method!
So, my question is, am I missing something? If not, then how did they do that - loading x86 assembly from x64 process in .NET 4.5? I'm lacking some understanding at this point.
Update
Thanks to Hans Passant, I've figured out my mistake. Actually the behavior of Assembly.Load is no different. It turned out, I didn't notice Prefer 32-bit option in project settings (or Prefer32Bit tag in .csproj file). That's why my process in .NET 4.5 ran in a 32-bit mode. This setting was true when I created WPF .NET 4.5 project. Then, when I swithced to .NET 4.0 it became inactive because there was no such an option in .NET 4.0. And when I switched back to .NET 4.5 it became false, which is so, I guess, for compatibility purpose.
Let's clear one assumption off the table quickly, there is no possible way to have different behavior on a machine that has .NET 4.5 installed. Targeting 4.0 makes no difference at runtime. The only thing that does is select a different set of reference assemblies, they prevent you from accidentally using a class that's available on .NET 4.5 but not on .NET 4.0.
There is no way to have both 4.0 and 4.5 installed on the same machine. .NET 4.5 is not a side-by-side version of the .NET framework, like 3.5 and 4.0 are side-by-side. Installing 4.5 replaces an installed 4.0 version. The CLR, the jitter, all the runtime assemblies plus the C# compiler.
It is best here to focus on the Platform target setting of your EXE project, that's the one that selects the bitness of the process. The kind of mistakes you can make is forgetting that the setting can be different for the Debug vs the Release build. And assuming that the "Active solution platform" combobox in Build + Configuration Manager has any effect. It doesn't, only the Project + Properties, Build tab, Platform target setting matters. This is a very awkward trap that many programmers have fallen into.
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 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.
I've thrown together some code to tinker with the new .Net 4.0/VS 2010 pieces, but I can't seem to find a build of my logging framework of choice (log4net) for 4.0, and I'm getting reference errors with the 2.0 version. Is there a 4.0 version available somewhere? I'm not asking for new features, just a version that's already been rebuilt against the new assemblies. Anyone know where I can find a build of 1.2.10 built for the 4.0 framework?
log4net has a known issue of referencing a System.Web component which is not part of the .NET Framework 4 Client Profile and the VS2010 by default sets project target to be the lightweighted Client Profile.
The solution is to change the target to .NET Framework 4:
Right click project -> properties -> Application.
Change:
.NET Framework 4 Client Profile
to be:
.NET Framework 4
... and that should work, i.e. you can use log4net again...