You don't need to be an 'investor' to invest in Singletrack: 6 days left: 95% of target - Find out more
.. possibly a bit too niche a problem even for STW.
We are using VS2015 for development. Recently we have created a new solution with a couple of projects in, it uses Entity Framework V6 and a MySQL backend (don't ask!). It's a REST api written in C#.
When debugging and stepping through the code there are certain methods that following a Linq statement will no longer show you the values of the variables, no hoverover. If you try and watch the variables in the watch window you get "The name ' ' does not exist in the current context", but it is in scope, it's clearly in scope as you are in the method where it's declared.
We've tried re-setting local settings (the main answer that comes up online), we've checked and it's compiled in debug mode. We've tried various settings through the Options > Debugging settings, thing is it works for some and not for others, so it looks like a bug. Also, I tried the new RC of update 1 and that didn't work either.
Anyone seen anything like this as well?
Yes it's a straw and yes I'm grasping!
I doubt your first sentence is accurate, but I'm not on anything so modern, or using the technologies you are, so I'm out.
More of an eclipse man myself.
That said, because it works for some and not others - is everybody running it as Admin?
Not that this will help, but we're using VS2015 to target C# projects running under Mono 2.8 and we've never seen any issues with the debugger resolving variables following a Linq statement.
Does it behave differently for variables in local and class scope? If in local scope, are the variables implicitly typed? In closures?
TBH, if people are getting different behaviour, it sounds like a bug.
Cheers for the replies all.
Sorry I meant it works on some local variables and not others as opposed to on some machines and not others, it seems to consistently fail. I believe it works on class level variables but not local variables, and yes the local variables are all var declarations as opposed to implicitly typed.
It just seems odd that I'm not finding anyone else online seeing this problem but perhaps it's just a difficult problem to describe in a google search!
Have you tried Stack Overflow?
Is there some delayed execution confusion going on? If you force the linq statements to enumerate does it help?
Edit: having re-read it, that doesn't see right.
Take it you've tried it with clean source from your source code control? I.e. Without all the temporary files that get created, just the sln and project files.
Try running as admin
Check you don't have something fishy going on with your build dependencies eg are you copying the assembly to your debug environment, but then building it afterwards, so the debugger symbols are out of date.
Failing those, is it a humongously long method, with a lot of non-trivial linq? In which case I have seen this before, and the answer was to refactor into smaller functions.
Is there some delayed execution confusion going on? If you force the linq statements to enumerate does it help?
I was thinking it might be this. If it is I think a .ToString on the variable would force the execution and let you to view the contents.
Deleting the IntelliSense database and letting it rebuild has solved these sort of problems for me in the past (may already have been achieved by deleting local data though?).
VS2015 is somewhat temperamental IMHO.
Cheers for all the answers gents.
We have tried stackoverflow for solutions, but it's difficult to phase the question into a search term as there are loads of elements to it.
We all run a admin, we have removed local files suo etc. Will give the deletion of the intellisense file a shot as I'm not sure if is remove as part of the settings reset - potentially not. Methods aren't too long as we'd all kick each other for overly long or complex Linq or methods.
Yeah, I suspect it is a bug in 2015. Will try a couple of the above suggestions such as forcing the execution.