I have a project using Reactive Extensions and ReactiveUI. I upgraded to the pre release version and I have the following line of code
OAPHCreationHelperMixin.ObservableToProperty(observable,
Function(x) x.Value
Visual studio tells me there is an error here on the method ObservableToPropertyin that the following assembly is missing
Error 9
C:\Users\phelan\workspace\WeinMeasEval\WeinMeasEval\Global\ObservableBinding.vb
Reference required to assembly
'System.Reactive.Interfaces,
Version=2.0.20823.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35'
containing the type 'System.Reactive.Concurrency.IScheduler'. Add one to your project.
Now I click the link which suggests it will add the reference and then nothing
happens. If I look in my project references I see that the assembly is indeed
in the assembly list and it is the correct version 2.0.20823.0 and if I look on
the path the DLL is indeed there.
Any ideas?
This is now fixed, check out ReactiveUI 4.0 Preview 5
It turns out that at this date reactive UI is not built yet for .NET 4.5 as the developer is having some build issues.
As a work around I build it myself by pulling the repository from Git and referring to the core library directly from within my .NET 4.5 project.
This seems to work at the moment. YMMV
Do you have Target Framework set to full .net or to Client Profile (in project settings)?
Related
I'm working on a project that targeting .NET 4.0 Framework. I added a reference to a third party dll file and call its methods in my code and have no error. But when I build the project it gave me The type or namespace error with blue underline on the methods of the dll. Using .NET Reflector I checked dll .NET Version of mscorlib.dll it is 4.0.0.0. My application Target .NET Version is 4.0 then Why I'm getting this error.
What I have done.
Remove all references to the library. Clean the project. Restart the project. again add the references. Not good in English please guide me. Stuck in it last 4 days.
Check if you have privileges to access the dll file. Then try running Visual Studio as administrator. If it does not help try to build the solution as 64x/86x not Any CPU.
I am upgrading a solution to Visual Studio 2012 (and 2013, but that's a side issue)
I am encountering the following error (many times) when compiling the test projects:
Error 345 The type 'System.Action'
exists in both 'c:\Users\neil\Documents\Visual Studio 2013\Referenced
Assemblies\Third Party Dlls\Moq\Moq.dll' and 'c:\Program Files
(x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Core.dll' .....
We are using Moq 4.0000, and the solution is using .Net 3.5 in all projects. It looks like the .Net framework now has a System.Func<....> implementation (previously only defined in Moq?) Oddly we haven't had this problem with VS2008, also using .Net 3.5.
Does anyone know how to resolve this?
Action and Func with many parameters were added only with .NET 4.0. Was it initially a .NET 2.0 project? In that case, you can try to remove the System.Core.dll from the references and try to see if the project compiles. Despite the name, it is unessential and was added only with .NET 3.5. The cleanest solution would be to upadate your library, Moq, with an updated one that fixes the clash in .NET 4.0. If that is not an option, follow Pratick advice to use assembly extern aliases.
I am attempting to convert the Microsoft.Health C# class library that is installed as part of the HealthVault SDK, using instructions provided here. After following these instructions, I get the following error when attempting to load the project into Visual Studio 2013.
"The project is targeting frameworks hat are either not installed or
are included as part of future updates to Visual Studio. See
http://go.microsoft.com/fwlink/?LinkId=287985"
Visiting the link takes me to .NET SDKs and Downloads. Once there, I have no clue on what needs to be done.
I do realize that one will have to leverage the Portable Class Library Contrib project to fill in some missing bits, especially code related to System.Security. This, I will deal with later.
Any one run into a similar problem?
Maybe so late but for those who have the same problem.
I had the same error in a project which was working perfect before updating VS2013 and finally after 3 hours looking for the source of the error I found that the error is about TargetFrameworkProfile.
In my case I sloved it like so:
Right click in the unloaded project in your solution and click Edit.
Find the TargetFrameworkProfile tag and set it as below:
<TargetFrameworkProfile>Profile78</TargetFrameworkProfile>
At a guess, this is because you need to specify the TargetFrameworkVersion and TargetFrameworkProfile properties in the project file. Compare the .csproj you are trying to create to a newly created PCL project file, and make sure that everything that's not specific to your project matches.
I ran into the same issue and got it resolved by installing the latest Visual Studio Update
I'm currently trying to convert a WiX 3.5 custom actions project in Visual Studio 2008 to WiX 3.7 and Visual Studio 2012 and I'm getting the following exception:
The type or namespace name 'MyNamespace' could not be found (are you
missing a using directive or an assembly reference?)
The dll is definitely referenced and Visual Studio 2012 has no problem seeing the namespace. Everything under the namespace even pops up in Intellisense, but when I build it I'm getting this exception.
Anyone have an idea of what's going on here?
Additional Info:
The namespace I'm referencing is a .Net 2.0 library and the custom actions project is a .Net 2.0 project.
EDIT:
After further investigation, I'm getting this warning, which I'm guessing is the root of the problem:
The primary reference "MyNamespace, Version=8.5.1.20, Culture=neutral,
PublicKeyToken=f593502af6ee46ae, processorArchitecture=MSIL" could not
be resolved because it has an indirect dependency on the .NET
Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0"
than the version "2.0.0.0" in the current target framework.
Why is it trying to use mscorelib 4.0 when this is a 2.0 project?
So it turned out that the dll being reference, while compiled to target the .Net 2.0 framework, was being compiled with the 4.0 compiler. Switching the project to compile with the 3.5 compiler solved the problem.
This may be completely unrelated but I had a similar issue yesterday. I had accidentally copied a class file (.cs) from one solution into another solution. Clearly, I hadn't added the references to the other solutions.
In our case, while the referenced dll was targeting .Net 4.0, it had its own reference to a .Net 4.5.2 dll. The referenced 4.0 framework target led us to believe that 4.5 or 4.5.1 were sufficient to handle things, but they weren't—the referencing project had to be 4.5.2 to handle the dll and all its references.
This was clearly an error on the part of the dll maker.
In a Visual Studio 2012 C# console application, I downgrade ".NET Framework Target" from 4.5 to 4.0. Win 7 Pro with both Frameworks installed.
I then reference an assembly, which, through warnings complains the following:
The primary reference "System.Threading.Tasks.Dataflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "System.Threading.Tasks.Dataflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" or retarget your application to a framework version which contains "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
If I try to compile at this point, I error, becuase types and namespaces from referenced assembly aren't available, as if the assembly was not referenced at all.
The "Add Reference" dialog doesn't have any System.Runtime choice, but if I manually brose to
C:\Windows\Microsoft.NET\Framework\v4.0.30319\
and reference the System.Runtime assembly found there, warnings go away and I am able to compile.
Questions:
Is such forcing of the System.Runtime version a potential issue down the road (deployment).
If VS Project properties are seto to target Framework 4.0 (doesn't that relate to targeting the 4.0 SystemRuntime/CLR), why isn't the refferenced DLL picking that up and why manually adding the reference to my project fixes that issue?
Even though the library System.Runtime is inside the C:\Windows\Microsoft.NET\Framework\v4.0.30319\ directory, it is not part of the .NET 4.0 framework. .NET 4.5 is an in-place update of 4.0 and is installed in the same folder with the same version number.
Here is a screenshot that proofs that the library does not exist on a play .NET 4.0 installation:
You can also validate this by browsing to the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework directory where you find the original assemblies for all installed framework versions. You will find the System.Runtime.dll as part of the .NETCore\v4.5 and .NETPortable\v4.5 subdirectories.
The reason that you can add the library to your project is that the runtime did not change between 4.0 and 4.5, so Visual Studio doesn't know or even care that the library you added manually is installed by 4.5. In this case the targetting in Visual Studio is only a filter that avoids that you accidentally add a 4.5 assembly to a project that targets 4.0.
Additional information:
Rick Strahl has a very good blog post on the topic with a more detailed analysis:
http://www.west-wind.com/weblog/posts/2012/Mar/13/NET-45-is-an-inplace-replacement-for-NET-40
Is such forcing of the System.Runtime version a potential issue
Yes, this just won't work. It works on your machine because you have 4.5 installed. Your program will crash and burn on a client machine that only has 4.0. Never add a reference from the Framework directory. It is rather sad that they are still around, they get too many programmers in trouble, but backwards compat is sacred.
The build system can only tell you that you have a problem when you use the reference assemblies. The ones shown in the Add Reference dialog, they are stored in c:\program files\reference assemblies and are not the same as the runtime assemblies. You know that works, you did get the warning. Which, in a somewhat clumsy way, told you that you program won't work on a machine that has 4.0. Don't ignore that warning, you really do have to target 4.5 to use that assembly. Hard requirement you cannot avoid.
why isn't the refferenced DLL picking that up
Because it refuses to build a program that cannot run. Feature, not a bug.