I just upgraded to visual studio 2010 and installed the code contracts msi. When I try to use it I get a compiler error that the system.diagnostics.contracts.contract dll exists in both the v3.5 and v4 framework. Anyone know what I should do to resolve this? Thanks.
If you're upgrading a .NET 3.5 project that uses contracts to .NET 4.0, make sure you remove your reference to the Microsoft.Contracts assembly.
The Microsoft.Contracts assembly provides code contracts for use in .NET 2.0 or 3.5 projects, but is provided by default with .NET 4.0 in mscorlib, so you don't need it. They both share the System.Diagnostics.Contracts namespace, so by having references to both at the same time, the compiler isn't able to figure out which one you're trying to use.
I solved it by first installing it, thou that did not actually solve it.
Then removed the references and then I changed the project versions to 4.5 and after that, it worked.
Related
I am working in Visual Studio 2019, and .net Core 2.1.1.
I am currently working on trying to get Identity Server 4's WsFederation integrated. In the latest instructions I could find, he mentions adding System.IdentityModel to the app through the project.json. Project.json seems to be deprecated now in .net core projects, and I am having a hell of a time figuring out how to add a freaking .net assembly to my project. Do I really need to just copy the file into the project and reference, cause that just seems wrong.
Instructions I am using:
https://www.scottbrady91.com/Identity-Server/IdentityServer-4-SharePoint-Integration-using-WS-Federation
Seems to all come back to the project type. I had created the project with AspnetCore and so I couldn't reference any .net framework assemblies, because you can't go back once you have made that choice. However, if you create the project specifically under the .net framework, you can move forward into the core frameworks, and hosting libraries of core. Which then allowed me to pull in the System.IdentityModel assemblies I needed to continue forward.
I was trying to use ReactiveUI in a WPF application that makes use of Prism. I installed the packages with NuGet, but simply adding the references led to the exception specified in the title during the initialization of the ModuleCatalog.
Edit:
As Pierre Arnaud pointed out, the problem is Microsoft.Bcl.Async not being able to resolve System.Core version 2.0.5.0.
We moved to Visual Studio 2012 since i first posted this question. The same problem persists and i can't even install the fix suggested by Pierre since i have installed .Net 4.5 now. The project is still targeting .Net 4.0.
Please install KB2468871, which solves the issue related to Microsoft.Bcl.Async not being able to resolve System.Core version 2.0.5.0.
See also Issue 8 in the async targeting pack knowledge base.
Here are the direct download links for the fixes, for the x86 and x64 environments:
http://download.microsoft.com/download/2/B/F/2BF4D7D1-E781-4EE0-9E4F-FDD44A2F8934/NDP40-KB2468871-v2-x86.exe
http://download.microsoft.com/download/2/B/F/2BF4D7D1-E781-4EE0-9E4F-FDD44A2F8934/NDP40-KB2468871-v2-x64.exe
This isn't happening for me. Is it possible that NuGet has added the SL5 DLLs as a reference to your project?
I will try to explain this as clear as I can
I want to fully understand how MSBuild multitargeting works.
I have read several articles from Microsoft and I think I understand the basic but I want to be sure I am not missing anything.
According to Microsoft:
By using Visual Studio, you can compile an application to run on any one of several versions of the .NET Framework. For example, you can compile an application to run on the .NET Framework version 2.0, and compile the same application to run on the .NET Framework version 4. The ability to compile to more than one framework is named multitargeting.
Visual Studio runs under the most current version of the .NET Framework that is installed on the development computer.
http://msdn.microsoft.com/en-us/library/ee395432.aspx
So do this mean that Visual Studio always calls MSBuild from the latest framework installed? assuming Visual Studio 2010 is installed, it will always call: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe when building any project targettting any .Net Framework version right???
If yes, then the ability to target old .Net Framewrok versions is based on the ToolsVersion and/or TargetFrameworkVersion properties right???
If yes again, it would mean that just installing the latest framework (and also the older frameworks but not installing visual studio) in my Continuous Integration box, I could point to build always any solution to: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe and just specify the ToolsVersion argument (if required, since each project can have its own target version specified in the TargetFrameworkVersion which it would cause to target an older .Net Framework version).
Following this I think my CI box would be building like Visual Studio does. Am I right? What am I missing? Is there a way to be completely sure?
I did a quick test, and I think it works :p the projects are being built according to the .Net Framework specified but like I said I want to be sure I am not missing anything.
Any thoughts?
BTW:
The simple reason to want to do that is because I have several custom MSBuild scripts that are reusable accross projects, but some of the functionality in these scripts require MSBuild 4.0 and also I have several MSBuild tasks built on top of the framework 4.0 so if I have for example a solution targetting the Framework 2.0 and I try to build it using: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\MsBuild.exe I get MSBuild errors trying to load my custom targets
Yes, you've got it mostly correct. Calling MSBuild from the 4.0 directory will do the correct thing against previous versions. They only thing I wanted to add was that 3.5 must be on the box to actually build projects targeting 2.0, 3.0 and 3.5.
This page here: http://msdn.microsoft.com/en-us/library/bb822049.aspx calls out the what versions Windows comes with what version of the framework pre-installed.
For someone who's been down this road, please share your breadcrumbs.
I have old VS2005 solution. Most of the parts are c# but I have one c++ managed project. Dev machine: Windows XP. Target framework version: 2.0
I moved the project to the Windows 7 64 BIT, VS 2010, did the project conversion. First thing I noticed were build errors - projects depending on one what is in c++ complained that project referenced has target 4.0 and I want to use it in project that (properly) targets 2.0.
OK, so I used some tips and set my project target to .NET 2.0. NOW: VS2010 complains that it cannot load the project because I need to install framework 2.0. OK, so I try to install it, and nothing - since installer detects .NET 2.0 as a part of the operating system.
WTF?
Admins, please create WTF tag for me here :)
It is not the .NET version that's the problem. The C++ build system currently does not directly support building for pre-.NET 4.0 targets. It requires VS2008 to be installed so it can use its tool chain. Sounds like you don't have it.
This blog post explains the workaround. You can upvote this feedback article if you're unhappy with that. No idea if this is slated to be fixed in SP1, this is not drawing a lot of votes.
I just starting to use Visual Studio 2010 and .NET 4.0. I created a new WPF project a DLL built for .NET 2.0. When I build the project, I get a bunch of warnings like this one:
The referenced assembly
"MicroFour StrataFrame Business...processorArchitecture=MSIL"
could not be resolved because it has a dependency on
"System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client".
Please remove references to assemblies not in the targeted framework
or consider retargeting your project.
When I reference a project I created that targets 3.5, it can't find any of the namespaces (during compile), though they show up in the object browser and intellisense correctly shows them.
Is there something I'm missing that needs to be done to reference an older .NET assembly?
There is very little point in targeting the client profile for .NET 4.0. The download is 41MB, the full version is 48MB, only 15% bigger. Unfortunately it is the default in VS2010, just change it with Project + Properties, Application tab, Target framework combo.
The client profile does make a lot of sense if you target 3.5, the full install is ~350 MB. The huge difference is explained by the prerequisites, .NET 4.0 requires at least XP SP3 or Vista SP1. But 3.5 installs on any version of Windows > 2000. The 3.5 installer thus contains lots of the required updates for unmanaged Windows components used by .NET. The web installer lessens that blow considerably btw.
Your 2.0 assembly has a reference to System.Web. The reference is being automatically forwarded to your target framework, 4.0. So it is attempting to use System.Web, version 4.0.0.0. The problem is with 4.0 (actually this started with 3.5), there is now the notion of a client profile. The client profile has a smaller set of reference assemblies, anything web/server related has been removed. This is to make the .NET framework a smaller/simpler download for end users.
With VS 2010 and .NET 4, the client profile is being pushed a lot harder, MS really wants us to use it. So your .NET 4 project is targeting the client profile by default. Your referenced assembly wants System.Web, so in that case you need to switch to the full profile.