We have recently upgraded an MFC solution from Visual Studio 2005 to Visual Studio 2013 (Update 4), at last. I think the solution originates in Visual Studio 6 and was upgraded to VS2003, then VS2005. It is a Multibyte (i.e. non Unicode) solution.
We haven't had many problems, so far. In fact it seemed like we had sorted pretty much everything out.
One of the errors we were getting was in the rc file, where the compiler said it couldn't find "l.esp\afxres.rc". Upon investigating the issue, we found that in VS2013 (I guess 2012 and 2010 too) the path is "l.esn\afxres.rc" so we changed it, and it all worked fine again.
Now, after "finishing" the port, we've continued the development, and we've found that, every time we make a change to the resources (add new controls, change the properties of existing ones) the path returns to the old one ("l.esp\afxres.rc"). It changes it when saving the resource file (make change, click save, it's already changed).
I guess there is some property, or something, that it's still telling the IDE it is a Visual Studio 2005 project, but I can't find it. I've tried removing the UpgradeFromVC71 property page, but to no avail.
Any ideas?
Ok, I've found it! Leaving an answer for future reference.
It's in the Resource include files. Go to Resource View, right click on the .rc file and select "Rsource Include Files". There are the offending includes. Change the path, and done!
https://support.microsoft.com/en-us/kb/198536 (old, but good enough)
Related
I don't know when this started, but I discovered that Visual Studio 2013 Update 5 aborts when attempting to open properties for a project within a solution. It seems to only happen when we have more than one project in the solution.
I've been able to reproduce it in two circumstances:
The first project is C++ and the second project is Fortran. Right-clicking on the first project and selecting Properties crashes Visual Studio without a crash dump or any kind of pop-up notification. Visual Studio just ceases to exist. Right-clicking on the Fortran project brings up the property sheet without any problem.
The second circumstance is with two projects, both C++. In this case, I'm able to open properties successfully for the first project, but not for the second one.
In every case I've tried where there's a one-to-one solution and project, it's working fine. A colleague who's working with VS 2013 Update 4 verified that the crash occurs for him as well.
We don't know when this started, but historically, we've opened these property sheets many, many times. However, it's probably been a few months since I've worked on a mixed-language process, and same with my colleague.
I've turned on logging and there was a complaint in the log about two versions of the Desktop SDK having the same internal ID. I removed one of those altogether, but that didn't seem to affect anything. It's also not clear if that error has any relationship to the crash.
I've also done a repair on Visual Studio, and that did not correct the problem.
I've also tried deleting the .suo and .user files. Again, no luck.
I've done quite a bit of googling but haven't found anything that matches this specific problem.
Any ideas?
Thank you,
Doug
I have VS 2008, 2010, and 2012 installed.
Initially, VS2013 Team Explorer was installed (Shell only). I uninstalled that.
Now, the Visual Studio Version Selector shows an empty list when executing a .sln file. Nothing shows.
How can I repopulate this list? Where is it stored? Registry? I tried to find entries, but since it doesn't actually have any items in the list, I couldn't search for a specific string.
I just encountered the same issue after installing Visual Studio 2015 parallel to an existing 2013 installation. In my case it turned out that that the problem was related to the solution file itself: It seems that the version selector does not like BOMs etc. (don't know how the solution got crippled, though). Make sure that the solution starts with
Microsoft Visual Studio Solution File, Format Version 12.00
and has no space, non-printable character etc. before that. After saving the file, the effect should be immediately visible with the correct icon returning.
I just ran into a similar problem where this dialog started popping up after a recent Windows Update (Win10) on 1/6/2018. That update caused all sorts of havoc in terms of broken file associations.
I tried searching for solutions and trying a few things but everything was overly complicated and messy.
My solution was to run the Visual Studio (2013) repair.
After the repair, I did receive a warning (from vs installer) about update 3 failing to update but I restarted the computer and sln files can now open without needing that version dialog. Everything seems to be compiling and running fine as well.
Just ran into this situation for VS2017 then I realized I have unfinished updates for Visual Studio when checking Visual Studio Installer.
The installer displayed a hint that I should restart my computer to complete the update and after doing so, the version selector works again.
I have:
Visual Studio 2010 Premium Version 10.0.40219.1 SP1Rel
Resharper 6.1
One other minor Extension I got off of Extension Manager
The team is using Team Foundation Server 2010.
I haven't been able to figure exactly what things triggers this, but I constantly have to re-set my solution Startup Project configuration. I think it's whenever I restart my computer and after some "Get Latest" retrievals. Here's a screenshot of the source directory structure in Source Control Explorer (not Solution Explorer):
Any ideas why I would have to re-set those properties sometimes?
This setting 'lives' in the *.suo file. It is certainly wrong to insert this file into Source Control. In the picture you 're providing, there doesn't seem to exist one - but keep in mind that's a hidden file: so it makes sense to check if you actually have one checked in along with your other sources.If yes, it absolutely makes sense that this gets changed with every GetLatest & you should probably remove it from your repository.If not, having this issue only makes sense when you map your source every time in a clean folder like #leppie says.Check also here & here for similar posts.
EDIT
OP commented below that his *.suo file was in fact not checked in - so the above passage is not really helpful. Another SO post seems to have been the case instead. Following the instructions there, OP got his issue resolved.
I've been developing a project for a while, and we have started a "documentation" folder in the Visual Studio 2008 solution so that we can keep the developer documentation (and a few other useful files) in there (it's one of Visual Studio's solution folders, rather than a project). We're also using the AnkhSVN plugin so these files get copied to Subversion.
However, every time I save any of the files, Visual Studio automatically removes it from the solution, so I have to add it back in,and then close Word again without saving.
I'd have thought this was a fairly easy problem to solve, but the past three weeks (and reading many spurious results on Google for almost every search query I can think of that might be relevant) seem to have proved me wrong.
Does anyone have any ideas how to stop this behaviour?
I don't know if this still happens with VS2013, but for VS2010 here is a detailed explanation on the cause and a work-around:
Word files disappear from "Solution Items" in VS2010
Are you sure the files are removed and not just hidden? I had a similar thing with non-code files.
Showing and Hiding Hidden Files in Visual Studio 2008
I have a command line app that uses a certain assembly. The assembly is sitting in the root of the project, and set to "Copy Always."
I add a reference to that assembly, and Visual Studio 2010 is happy -- Intellisense highlights everything correctly, and no errors are reported.
But as soon as I actually build, I get compilation errors like I haven't added the reference, and Intellisense suddenly gives me red squigglies as if the reference was never added.
But the reference is still there.
If I delete the reference and then re-add it, Visual Studio gets happy again, and the red squigglies go away. Then I build, and the same thing happens again.
So, Visual Studio agrees that the reference is there. Until I build. Then it claims its not. Even though it is.
And this only happens with a specific DLL (NLog, if it matters). Another DLL (HtmlAgilityPack) works fine, and it's set up and configured the exact same way.
With a little search I found a problem with the .NET client profile. Try looking at that link and see if it resolves the issue.
There's also some posts on it at the microsoft connect website if you're interested in further reading.