Visual Studio 2019 allows in the .NET 4.0 project Tests.Test_4_0.vbproj to add a reference to the .NET 4.6 assembly Tests.Test_4_6.dll. The editor allows to call methods of class Test1 in the .NET 4.6 assembly. However, when I build the project, I get the error:
C:\temp\Test_4_0.vb(327,35): error BC30002: Type 'Tests.Test_4_6.Test1' is not defined.
Is there some way to call .NET 4.6 functions from .NET 4.0?
Related
Is it even possible for a .Net Core 2.1 console application to reference a .Net Framework 4.6.1 DLL?
I have such a DLL that consumes a WCF service successfully. I now wish to use this DLL from a .Net Core 2.1 console application. But I am getting an exception stating that it cannot load assembly System.ServiceModel. The web.config file in the 4.6.1 DLL has relevant settings for System.ServiceModel.
Many thanks.
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).
I have a .net 3.5 dll and a .net 4.0 dll. The .net 3.5 dll need to call some functions in the .net 4.0 dll. To do this, I made the 4.0 .net dll as a COM server. However, I cannot tlbimp the tlb file exported from the 4.0 dll. Is it possible for a .net dll to call functions from a .net COM server? Thanks.
If possible you should either upgrade the 3.5 to 4.0 or downgrade the 4.0 to 3.5/2.0, so you can properly add the managed reference.
If you can't do that the alternative is to copy the declaration and replace [ComVisible(true)] by [ComImport] - however this may fail with a typecast exception on runtimes earlier than 4.0. I don't know if it works when 3.5 talks to 4.0, you'd have to test.