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.
Related
I am running Visual Studio on a Windows 11 VM with Parallels on an M1 Mac. Visual studio works perfectly when creating a new project but when I try to open an already created project with a different .Net Framework version than 4.7.2, I cannot open the Designer for the forms in the project.
I tried changing it to 4.7.2 from properties and manually changing in .csproj but this will generate other errors and eventually cause problems to other people opening the project (as it is shared with GIT).
Running the project will not cause problems, the app builds perfectly.
How could I try to solve this problem?
The full error is: Timed out while connecting to named pipe.
Thank you.
When I build a C# program (this has been going on for several different solutions/projects I have been working on) in Visual Studio 2017, the new, updated code will build and run in debug mode (and run correctly).
However, the application that Visual Studio has been outputting when I build/debug them has been remaining with the original, first version of code that I saved. When I choose the options to rebuild, it will update the time stamp on the application and .pdb files, but the application will perform the way it did in earlier code versions, not the most recent code version that was running problem when I ran debug mode immediately after pressing Ctrl + F5.
These are C# Console Apps with the .NET Framework 4.6.1, if that makes any difference. I checked the output folder, and it is indeed the desired folder and the one I have been looking in... so why is the time stamp updating on the application (.exe file) that it outputs, but not the code itself? What am I missing?
When I run into strange things like this in Visual Studio, the first thing that usually works is to clean the project and rebuild. If that doesn't work, I'll close Visual Studio, re-launch, then clean and rebuild again. If that doesn't work, I would start looking into any extensions you have installed that might be getting in the way of your build process.
Further, you can look into logging the extensions activity to help troubleshoot if there are issue there. See the following article:
https://blogs.msdn.microsoft.com/visualstudio/2010/02/24/troubleshooting-extensions-with-the-activity-log/
You may have already tried this, but since it wasn't mentioned I thought I'd provide it for others in a similar situation.
Two possible reasons:
(1) Your project was not recompiled during debugging. Please enable Edit and Continue under TOOLS->Options->Debugging.
(2) Visual Studio has a concept of incremental build. If you have a solution with two or much more projects and if you change source code in only one of the two projects, the "Build" command will compile only the modified project. But the "Rebuild" command, on the other hand, it will recompile all projects in this solution.
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.
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.
We have a solution on VS 2013 that contains a shared code project type (https://github.com/firstfloorsoftware/mui).
We made some minor changes in this code and it has being part of our solution for a while.
Now I want to open this project in VS 2015. Although I had a minor problem with the shared project that seems to be fixed: https://github.com/firstfloorsoftware/mui/issues/48
I still cannot get rid of the more than 5000 errors on this project. I can run it successfully, but have no idea the reason for so many errors.
One thing I noticed is VS 2015 uses a standard C# project in the solution explorer instead of a special icon indicating a shared project.
How to reproduce the problem:
1 - Download the Modern UI project from github;
2 - Open it on VS 2015;
3 - Make the fix I mentioned here: https://github.com/firstfloorsoftware/mui/issues/48
4 - Reload the shared project after fixing the project file
5 - Notice the number of errors on the error list.
Any ideas?
Igor.
It seems the issue is related to missing files during VS 2015 setup due to the choices I did during setup.
All I did was creating a new Project and choose Windows 8 template. Then the VS 2015 setup is launch and the missing packages are properly installed.
After doing that, I could open my VS 2013 Project in VS 2015 like a charm.
Igor.