It's been several days since my MS Visual (2013 : 12.0.311001.00 update 4) became kind of nut and behave strangely:
Here are the symptoms
I have a simple hello word project that builds fine.
I insert one mistake into the code (see below).
I build project.
Visual (I'd rather say the compiler) is perfectly find with the new error inserted. It doesn't rebuild nothing and run the previous version of the code.
The mistake is however highlighted in red in Visual editing panel.
here is the code (which is not the guilty here)
include <iostream>
int _tmain(int argc, _TCHAR* argv[])
{
char c;
std::cout << "Please help!!!" << std::endl;
std::cin >> c;
mistake
return 0;
}
mistake above is not detected as a code change
What I've tried:
Uninstall reinstall Visual => same behaviour
Uninstall and reinstal other version of Visual => same behaviour
Tried with a very simple project to make sure that my real project and cmake chain is not responsible for this. This new very simple project is the main above
What other information I can provide :
Already tried the stuffs in Tools>Options> project and solutions > build and run where i set "on run when project are out of date" = "always build". => no change
If i update a header file referenced in my main file, the build process will go just fine. Of course I don't want to have to rememeber all the header files i need to modify to rebuild my project correctly. This no accetable solution.
I have installed no other tool/component that could explain this.
There were no visual or windows update at the same time that could be responsible for this.
This happens also on one of my colleague's a computer (but not all of them). I can see no common radix between him an I that could help the investigation
This happened next to a time shift in my country. Not sure the translation to english is ok but to be precise enough : time reference has been advanced from one hour.
Any help would be very appreciated because I've already spent several days investigating on this and rebuilding all my projects takes so many time it starts to make me crazy.
Ok, so I don't know neither what happened nore what is responsible for this problem but I have a workaround/Fix (not sure this is a fix because I can't locate the problem precisely) to propose.
I told this happened next to a time shift in my country and my recent discovery confirmed that.
What I did to fix my problem is the following :
Switched my time zone from local one to UTC, validate, and then switched it back to my local time zone again, validate again.
And then, it worked.
Strangest thing I have ever faced.
Definitely classified in my "WTF problems" section.
Really hope someday this will help someone.
Related
I'm using premake5 here.
It generates my solution/project files, when this happens, VS2015 asks me if I want to reload the modified projects.
If I hit yes, this proceeds to lock up the IDE for a very long time.
Anywhere from 30 seconds to 1 minute I'd say.
Does anyone know of a way to work around this? This is super irritating.
It happens even for the most trivial of changes(modify one project, which only has 1 file in it).
I realize this is a VS problem, and not directly the fault of premake/cmake(or whatever build system you are using), but it totally sucks.
As you said, it's VS related :) But I think you have some problems with your installation : for small projects, reloading the whole solutions should be pretty fast : my personal projects take less than a second to reload (2 to 4 projects per solution, ~100 files per project)
Anyway in the usual course of development, re-generating your projects should not happen that often, except at the very beginning when you need to configure everything.
When you need to add a few files, just add them through Visual Studio : you won't have to run Premake again, and next time you run it, the files will be included by your script anyway. You can do the same with small configuration changes : update your project directly in VS, check that it works, and when it does, upadte the Premake script. You won't have to run Premake then.
I'm very new to Visual Studio and Universal Windows Apps Development. As a part of the course, I have this codeSHOW project provided.
I've cloned it successfully in VS 2015, but I can't run the project using the .sln file. Error:
Here's the error log: http://pastebin.com/c012Bba4
I have no clue how to fix it, and the issues on github go unanswered so I can't expect much from there.
This is an known issue in Visual Studio 2015.
The problem is with files with the exact same name under different folders in a Shared project, which in your case is "resources.resjson".
The only workarounds are either to make the file names unique and if that is not an option, to duplicate the files in the projects instead of sharing them out of the Shared project.
This is a VS2015 specific bug, the solution loads just fine on VS2013. You can get some insight into what is going wrong. First note that your got two message boxes that announced this error. Barely visible in your screenshot.
The failure.txt file gives more hints, you can see the stack traces of the two AggregateException that are raised when the solution is loaded. You'll see that two tasks are trying to load the same resources.resjon project item. Not correct of course, quacks like a standard concurrency bug.
Nothing actually goes wrong, Visual Studio can handle the exception and declares it "Recoverable", the projects are still loaded correctly. And compile just fine. Only other thing you need is the Bing Maps SDK, you can download the correct version here.
If you have VS2013 then prefer that version, it doesn't have this bug and loads the solution without any complaint. And minimizes the odds that you'll run into other quirky problems. Given the current stability of VS2015, not great, it is the best way to avoid losing time. Otherwise just ignore the mishap and close the message boxes, some future Update will no doubt fix the bug. You can report it at connect.microsoft.com if you wish. Not actually necessary I think, it looks like VS is phoning home.
I am using Visual Studio and a solution with 10 or so projects in (mostly VB, some C#) which have various dependencies set up. Usually when I compile the solution it works fine. Occasionally when I do it I get a build error saying that one of the projects referenced is the wrong version (I think always the same one, possibly may be two that can cause problems). In this case going to the solution explorer and right clicking on the mentioned project and saying "rebuild" followed by another full build makes it work fine.
I assume there is something set up wrong somewhere but I didn't set up the solution myself initially and a quick look through doesn't show anything immediately wrong.
It feels like there is some kind of race condition, that VS is internally setting the version number of the project it needs before that project has been rebuilt and thus gets it wrong or something like that but I'm sure VS should handle all this sort of thing properly.
Can anybody please suggest places that I could check for whether this has been correctly set up...
And I should finally note that since I don't have reliable repro of this I may not be able to respond to questions too quickly. For example the obvious one of "Could you give the exact error message" will have to wait since I didn't think to copy it this morning, it was only after I cleared it up with the above steps that I thought to post here. Similarly any solutions may take a while to confirm.
Edit to add error message:
Indirect reference is being made to assembly ODP version 1.0.3792.16586, which contains '{{CLASSNAME}}'. This Project references a prior version of ODP version 1.0.3791.18659. To use '{{CLASSNAME}}', you must replace the reference to ODP with version 1.0.3792.16586 or higher.
Edit for more apparently relevant details
Since it has been bought up I will clarify that one of the projects is a web project and that it is this one which is generating the above error message.
Further edit
Having looked further there is a copy of ODP.dll in the bin diretory of my web project. Using windows explorer and right clicking, asking for properties and looking at the version it is version 1.0.3791.18659. Having deleted this (actually moved it elsewhere) when doing a build it recreated this file still with that same version number (ie an old version number).
ODP claims to be a project reference too which still makes me think it should just work... :(
Further Further edit
I think now that the problem is that if the ODP project changes then it gets rebuilt but it doesn't necessary cause all the projets that are dependant on it to be rebuilt. So one project might still be built against the old version and one against the new version. If they are then trying to talk between each otehr with objects from ODP then it goes wrong... I need to confirm this but I'm not sure what would need to be done to fix it at the moment. :)
Is the build order correct? I can imagine if you build one project which references the other one, and that one isn't built yet you can have this kind of problem.
Link: http://msdn.microsoft.com/en-us/library/5tdasz7h%28v=VS.80%29.aspx
If you have a website project, are you sure you have set these to be 'project' references rather than 'bin' references - you could be getting some issues this way.
I have a couple of VS 2008 projects (C++) that are linked every time I start a build, even though nothing has changed. i.e. I select "Build Solution", it compiles and links, I select "Build Solution" again, it doesn't compile anything, but links again.
This is quite annoying and I have checked everything that might cause it to link again.
Is there a way to find out why Visual Studio does or skips certain build steps?
Any input is appreciated!
I had some time to revisit the problem and a workmate gave me the tip to use "process monitor" from sysinternals to figure out which file is missing.
Lo and behold it worked! It turns out that Visual Studio insists on linking against a bunch of libs even if the app does not need it. Due to an unfortunate (I guess...) chain of events, one of the default library paths disappeared from Visual Studios global settings, so VS couldn't find this lib anymore ("coredll.lib" in my case).
This didn't affect the final output, because this lib is not needed at all, but it still triggered a relink every time.
There are two possible fixes:
1) Restore the path to this lib in the global Visual Studio settings
2) Use "$(NoInherit)" in AdditionalLibraries to get rid of the unneeded lib.
I used solution #1, because #2 needs to be done for each configuration of each project because can't be done via Property Sheets.
Rebuilding can be caused also by non-existing and unused .h files belonging to the project. Since they are unused, there's no warning nor error about missing files.
Using "Process Monitor" by Sysinternals as mentioned earlier was a great hint towards figuring out the reason.
Bit of a long shot but check the date/time stamp on any dependent DLLs you have. If they are in the future then a rebuild will occur.
Edit: Also have you tried opening the .vcproj files up in an editor to check if anything's unusual? You could also try recreating them from scratch, if that's possible.
Visual Studio seems to be modifying a list of .vsmdi files in my .sln every time sometimes when I run a unit test. This is annoying because my source control client thinks the .sln file needs to be checked in even though I don't want to check it in. Is there any way to keep Visual Studio from munging the .sln file after a test run?
Edit: Found a Microsoft Connect issue discussing this, which sucks because things just sort of disappear from there after a little while and its a terrible bug tracker
I don't believe a solution exists. A good Connect case, that does a better job of documenting the issue and a repro case, is this one. At the very bottom of the page a commenter proposes a workaround, which I've reproduced here. I haven't actually tested this workaround for myself yet, I guess I've gotten numb to discarding the changes caused by this bug :(
From the connect case:
I have been able to repro this problem
by having developer A run tests with
the vsdmi file while developer B check
it out and adds unit tests to the
vsdmi. This typically will cause a new
one to be generated.
The workaround that has worked for me
is to create vsdmi files per dev for
unit testing activities that are not
checked in to SCC and create special
vsdmis for build testing and automated
regression.
Yuck, but it works.
Edit: Oops, was confused about the "list of vsmdi files" thing. Suggestion wouldn't have worked.
That is a question for the ages...I always check if the solution has been checked out for whatever reason before I commit changes.