According to Microsoft: "The Immediate window is used at design time to debug and evaluate expressions, execute statements, print variable values, and so forth."
Notice it says "at design time". I have read other statements on the web to this effect as well.
However, when anybody asks why they get the "The expression cannot be evaluated while in design mode." error, everybody always states that it only works in debug mode.
I can understand some things will not work in design mode when they reference items like textbox box values. But I really don't understand why I have to set a breakpoint, run my application, and wait for it to get to the breakpoint, just to find out what 1 + 1 is.
I admit to frustration as I'm coming from Visual Basic 6.0. There I can print 1 + 1 and get 2 while in design mode. I can also call public functions and get answers while in design mode.
All of this comes from my looking for answers to type converting. Since I couldn't find an answer on the web, I decided the quickest and easiest way was to just test some statements REAL QUICK in the immediate window to see which one worked.
Is .NET a step backwards when using the immediate window?
I understand your frustration. Fortunately the development of Roslyn (Microsoft's open source C# compiler) allowed to have a so called "Interactive Windows" in Visual Studio. You need to install Roslyn, and after some easy setup steps you can evaluate C# expressions in that window:
https://github.com/dotnet/roslyn/wiki/Interactive-Window
It's very different from Immediate Window since REPL loop can be somewhat isolated, but it seems like that you can even interact with your project to some extent: Can the C# interactive window interact with my code?
This dates back even to 2011-2012, and it's default part of Visual Studio 2015 CTP1 since the end of 2015: View -> Other Windows -> C# Interactive
In short, it depends on the context of your application, that is, which solution you currently have selected in the Solution Explorer and its project type. e.g. Web Projects, will not evaluate immediate expressions at design time because it needs to setup that environment, however, library and console type projects will.
MSDN states:
"When establishing the context for design time expression evaluation,
Visual Studio references the currently selected project in Solution
Explorer. If no project is selected in Solution Explorer, Visual
Studio attempts to evaluate the function against the startup project.
If the function cannot be evaluated in the current context, you will
receive an error message. If you are attempting to evaluate a function
in a project that is not the startup project for the solution and you
receive an error, try selecting the project in Solution Explorer and
attempt the evaluation again."
However, if you are in a web project you will need to hit a breakpoint in order evaluate expressions in the Immediate Window.
This may be covered in other answers
To me, I can do whatever you mentioned in the immediate window in Visual Studio 2008, like finding out the sum of 1+1 or finding out the length of "sdfd". Length, etc. can be done from the immediate window. So it's not a step backward in .NET.
Related
I'm debugging something (in Visual Studio 2017 and 2019) where, somewhere, a number's changing between an old version of code and a new version. It'd be useful to be able to recursively dump the values of fields in an object from the debugger for comparison. Especially where the dump is large and can be run through diff rather than compared by eye. Ozcode looked promising, but the trial is doing nothing. I suspect Ozcode only works for C#/.NET apps and I'm in C++ native.
I can navigate manually through the objects in the debugger and explore all the field values so clearly VS has access. I can query the values of the fields in the top level of an object in the Immediate Window by typing something of the form
?MyObject
I've seen mention of the possibility of running a loop in the Immediate Window- doesn't work here. Nor does using other suggestions of commands to dump to JSON using .NET assemblies, because I'm not in .NET
Using the Package Manager Console as a hacky way in, I can run PowerShell scripts that get at the debugger and iteratively dump fields to text to as deep a level as I want. It's easier than adding exploratory code and the scripts can be created and run while stopped at a breakpoint which makes it easier to explore what's going on, but it'd be so much easier if there were an extension adding a dump option to the context menu of an object in the debugger. I don't see anything obvious when searching. Does anyone know of such a thing?
I have an error which is occurring only very late in my code (after it's been running for ~20 minutes) and so trying to pinpoint exactly where it is is tricky because I have a lot of recursive function calls and if I go too far the important variable values may have been changed. Is there a way I can set a kind of save point where all the variables have their values saved and which I can jump back to after I've done some exploring rather than having the run the whole thing again from the beginning?
I found this and just wanted to point out that Roger Lipscombe's comment is what I was also looking for:
Precisely: IntelliTrace https://learn.microsoft.com/en-us/visualstudio/debugger/intellitrace?view=vs-2022
and
Historical Debugging (which is part of IntelliTrace) https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2015/debugger/historical-debugging?view=vs-2015&redirectedfrom=MSDN
Only available on the enterprise version of Visual Studio
I have a workaround for this kind of issue: Using the Data Breakpoint, at least, it could output and save the value manually, and it also can help you check that what value was applied to your code line, I just get this idea from this case I met before:
Visual Studio. Debug. How to save to a file all the values a variable has had during the duration of a run?
If IntelliTrace tool is helpful for you like Roger Lipscombe's suggestion, one idea is that you could use IntelliTrace Standalone Collector tool without the VS in one machine:
https://msdn.microsoft.com/en-us/library/hh398365.aspx
I would like to debug a same C# console project from two different instances of Visual Studio to increase my productivity, as the edit-and-continue mode is not always enough, to say the least.
I have no problem opening the solution twice, and debugging different projects concurrently, but when I try debugging the same project twice, it expectedly fails as it cannot replace the executables in the bin folders.
The possibility to debug twice from the same instance of the IDE as explained here is very welcome, but not good enough for me as I want to be able to completely edit my code when needed.
Is there any simple way to achieve this? Thanks!
Instead of clicking Debug or hitting F5, open a command prompt and start the number of instances you want from there. Now start as few or as many Visual Studio instances you want and go to the debug -> Attach... window.
In the Attach to process window, find the instance youw ant to debug and choose attach. This will allow you to attach to as many instances of your applciation as you'd want.
Now, if you want to be able to edit these application son the fly and spin up new instances, that isn't possible because, as you've found out, the executable will eb in use. Short of creating multuiple copies of your output directory and always starting a copy, never the original, you have no way to achieve that.
Just as a note for whoever stumbles upon this page, as it's ranked very high on Google:
If you want to debug two instances of the same program in Visual Studio, this is as simple as opening up two instances of visual studio and pressing f5 in each instance. This works remarkably well, although you want to wait until one program is up and running before you start the second - otherwise you may get conflicts in your bin folder (which is what it seems OP didn't do.)
I am new to using Microsoft development tools but have been using Visual Studio 2010, .NET 4 and C# for the past few weeks. I ran into a problem yesterday creating a new project the same way I have been doing it successfully from the start: right-click on the project in the Solution Explorer → Add Reference, which used to bring up this dialog:
Old Dialog Box http://img514.imageshack.us/img514/8978/oldaddreferencedialogue.jpg
After a couple of weeks of no new projects I went to create one yesterday and got a new Add Reference dialog. And trying to add the same dll I have been adding for weeks now resulted in the error seen here:
New Dialog http://img692.imageshack.us/img692/2074/newaddreferencedialogue.png
So, after a painful day trying to determine the cause, it looks to me like it has something to do with the new dialog choking on the # I had in my reference path. When I removed the # everything works as expected. Considering Microsoft has two .NET languages with # in the name, I am surprised that this issue keeps biting people (I have heard of this problem over the years, but I have never done much with Microsoft tools until recently, so of course I did not recall it.)
Questions from a Visual Studio newbie:
Is it common knowledge to not use # in paths?
How/why did I get this new Add Reference dialog when my colleagues, using the same VS version, still have the old dialog that handles # in paths just fine?
My opinion is that if you use weird characters in paths, you get what you deserve. :)
I know there are bugs about '#' character in paths in the core VS product, in addition to whatever may be in the Pro Power Tools extension. There is a surprising amount of code that goes to/from URIs and filenames, and '#' characters (and everything thereafter) get dropped when roundtripping via a System.Uri.
In general, I think it's safe to assume that when creating filenames/paths, there will be 10,000 tools of various quality trying to parse the filenames, and a (large) subset of those tools will fail on 'weird' characters. Just avoid weird characters whenever possible. You gotta choose your battles. In an ideal world, tools would be robust to these kinds of issues. In the real world, it's better to name a path "CSharp" rather than "C#" and move on with more important things in life.
The second dialog is the one from the VS2010 productivity power tools pack - I havent used it myself so dont know of any problems with it. Have you recently installed this?
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.