I've just migrated my solution from Visual Studio 2010 to 2015. It consists of 3 DLL projects (all C#) and a web application project (VB.Net).
Despite compiling correct and being able to run/debug the code, Visual Studio 2015 keeps complaining that...
BC32207 The project currently contains references to more than one version of 'xxx.dll', a direct reference to version 2.0.5987.24747 and an indirect reference to version 2.0.5987.24748. Change the direct reference to use version 2.0.5987.24748 (or higher) of xxx.dll.
This doesn't just happen with the one dll, but can happen with any of the 3... there doesn't appear to be any pattern to which one it complains about.
I can continue working, but it's very distracting having lots of "errors" (highlighted with red wavey-underline) in the code which aren't actually errors.
Without locking the version number down, how can I stop Visual Studio picking up on the multiple references?
For the record, I have cleaned the solution when in Release mode but I still get it after compiling in Debug mode.
Related
I'm working with Visual Studio 2017, enterprise version. I'm working on a C# project, depending on several NuGet packages.
One of my references is mentioned being missing (there's a yellow triangle above the icon in the solution explorer). When I double-click on it, in order to see its contents in the object browser, I get following error message:
This project cannot be viewed in the object browser because it is unavailable or not yet built.
Please ensure that the project is available and built.
You might think: "just restore the package (it's a NuGet package) and off you go", but the problem is that the message makes no sense:
In another project, I am using the exact same NuGet package as a reference, there everything is fine, and when I do a file/directory compare between that other project and my current one, WinMerge mentions both being equal. (Not only WinMerge, I also did a checksum comparison)
So my question is: what's the source of Visual Studio's This project cannot be viewed in the object browser because it is unavailable or not yet built. error message? What's the source of the yellow triangle in Visual Studio's solution explorer (for NuGet packages)?
Edit (added: Visual Studio version)
For your information, I'm working with Visual Studio enterprise 2017, version 15.9.36.
In the meantime I've found a workaround: I remove the references from the project and add them again, and it seems to work. Apparently there's some instability in Visual Studio reference handling.
I use the Microsoft Recommended way of structuring my solutions:
https://msdn.microsoft.com/en-us/library/bb668992.aspx
Typically I work off the main branch, and occasionally I open a older release. When I'm working I often have the Main branch open in one VS window, and an older release open in the other, something like this:
Visual Studio Window 1 - Main Solution(Solution containing: Web Site with several other Main Class Libraries)
Visual Studio Window 2 - Release 2.0.0(Solution containing: 2.0.0 Web Site with several other Version 2.0.0 Class Libraries)
Often times when I have both windows open, Visual Studio becomes confused between the two of them. For example, I build the 2.0.0 version of my website and then attempt to build the main site, the main site build will fail referencing a missing object that clearly exists within the project but not in the older version(2.0.0):
(Reference exists in Main branch, but not in 2.0.0)
My work around to this issue is to close both Visual Studio windows and then reopen only the main branch, rebuild, and everything works correctly.
It appears as though Visual Studio is confusing the two projects. Is there a way to get around this issue without closing both windows?
Update 1
I've tested this on VS 2017 and it doesn't seem to be occurring, I've also changed my folder schema since I first encountered this behavior.
In short: I need to open an application originally built in Visual Studio 2008 (version 9) in Visual Studio 2013 without upgrading the project since the overall project architecture must remain the same for when I check it back into source control.
Details: I need to open a Visual Studio solution (.sln) inside Visual Studio 2013. The solution in question was originally developed in Visual Studio 2008, so when I try to open said solution in Visual Studio 2013, I am shown a prompt with the projects within the solution checkmarked, with the message:
These projects are either or supported or need project behavior impacting modifications to open in this version of Visual Studio. Projects no displayed either require no changes or will automatically be modified such that behavior is not impacted. Visual Studio will automatically make functional changes to the following projects in order to open them. You will not be able to open these projects in the version of Visual Studio in which they were originally created.*
My attempt at a fix was to just upgrade the solution and hope for the best. This is successful, but after building and attempting to run the main project, I see the following build error:
The type 'Microsoft.Web.Services3.WebServicesClientProtocol' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. *
I then tried both commenting out the references to this assembly and adding in the missing reference. Okay, so then I rebuilt the solution and attempted to run. Same error, but for a different assembly. Repeat fix, same error for different assembly. This pattern continues and continues, and at this point I realize this is unacceptable anyway, because when I make a change to this solution, I need to check it back into source control. When others open it, they may be opening it in VS2008, and therefore this “upgraded” version is inconsistent with the version the business uses. I need to open the solution originally build in VS2008 in VS 2013 (can't work around this, needs to be VS2013). If it helps, I'm using 64 bit Visual Studio 2013 Ultimate.
Any help or guidance will be greatly appreciated!
As several of the commenters have already helpfully pointed out, this is not possible. Round-tripping (i.e., opening and manipulating project files created by an older version of Visual Studio in a newer version of Visual Studio) was not supported until Visual Studio 11. The only way to open a Visual Studio 2008 project/solution in a later version of Visual Studio will be to convert it.
As far as interoperability with previous versions is concerned, you have two options:
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then edit the code files. Once you're satisfied with your edits, commit only the modified source files, not the project infrastructure files. Your fellow developers, stuck on VS 2008, won't notice any difference.
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then rename the project file (e.g., by appending a -vs2013 suffix to it). Commit this to your code repository. You will now have two project files in your root directory, one for each version of Visual Studio that your team works with. From here on, you just open the project file corresponding to the version of VS that you have installed.
I used approach #1 for a good part of last year, where I spent most of my time developing a C++ application in VS 2010 on a desktop machine, but also wanted to work on it on my notebook running VS 2013. Of course, in my case, it took a trivial amount of time for the automatic conversion to upgrade my project file after pulling from source control. I didn't have to do any tweaking thereafter to get the project to build. It sounds like your case is different, so option #2 might be a better choice.
I re-factored some functionality from an ASP.Net Project into a library project. Everything seemed to work fine but on my co-workers computer Visual Studio does not always find the assembly reference after a rebuild.
She writes some lines of code and sometimes the error list gets filled missing references. After a rebuild it is fine again and she can continue. It only occurs on her PC, I could not replicate it anywhere else.
I have already checked the Build Order and the Target Framework (Every Project uses .Net 4.5)
I opened my WinRT (I'm using MVVMLight) project in Visual Studio 2013 this morning, and found out that all kind of types even system ones are not recognized saying Cannot resolve symbol 'bool' for example, note that the solution builds, executes and works all fine !
C# :
Even XAML :
I tried many things, closed and reopened the solution, cleared Resharper caches, I even restarted Visual Studio and the PC, but still the same problem, any solution to this problem ?
Update 1 : I tried to Suspend/Resume Resharper from Tools>Options and even delete files from AppData\Local\JetBrains\ReSharper\v8.0\SolutionCaches, and now Visual Studio causes errors too :
Update 2 : I uninstalled/re-installed visual studio, and I still have the same problems
If you have any Xamarin extensions for Visual Studio installed, it is a root of the problem. There are some compatibility problems.
As a possible workaround, you may try a workaround, mentioned in this ticket:
Select 'true' for 'Use msbuild to obtain project references' in
Project Properties (Click on project name in Solution Explorer | Hit
F4) for each project in the solution.
At least, it works for me.
If you can build the solution, but ReSharper marks your code in red - you can write the request here and you will likely get a help.
If you can't build your project then it is not ReSharper's problem. Then we need to find out why your build is broken.
It seems that your project to assembly references are broken.
To understand what's happening here with references during the build, go to Tools -> Options -> Projects and Solutions -> Build/Debug and set the verbosity to diagnostic. Then try to build your project and investigate the output windows in VS (or you can use MSBuild.exe from the command line instead). What you need to find in this large text block is "Resolve Assembly references" or "Expand SDK references" task. These tasks should obtain the valid paths to the assemblies your project depends on. Later on csc.exe should be executed with all these paths as parameters.
You can check whether the paths are correct, do they indicate to the existing binaries or not.
You can also create a new WinRT project template and check if it can build. If it cannot even for the clean project template then it is obviously a system problem, I suppose your platform sdk's are corrupted.
Hope this will help.