Using Visual Studio 2019 Professional v16.8.2. Whenever code is modified, automatic re-compile is triggered in the background. This has the effect of marking/unmarking error squiggles, adding/removing items from the Error List window, and Intellisense related to these errors.
To demonstrate, ensure Tools > Options > Text Editor > General > Show error squiggles is enabled and view the Error List window. Take any large C++ or C# project which compiles correctly, and deliberately add a closing brace } somewhere in a method. In one small example for me, this generated 251 errors and related error squiggles, though it is possible to generate thousands of errors this way. Now repeatedly delete and then re-add the closing brace...Visual Studio starts to lag as it tries to mark/unmark, and add/remove all these errors.
When typing fast, pasting code, or just using the IDE as a text editor, this is distracting and incredibly annoying.
Is it possible to configure a delay from last keypress before automatic compilation? Ideally I'd like something like ~2000ms, or even the ability to only re-compile manually.
It's working as intended.
It's a function of the Precompiler and Intellisense. Their whole purpose is to catch compiler errors before you try to compile your code which may take a long time (re: your example of "a large project").
There was an update to VS2019 today as of this posting and I just noticed an option under Tools > Options... > Text Editor > Advanced labeled "Auto cancel long running auxiliary operations on typing" with the following radiobox settings:
Automatically adjust maximum allowed typing latency
Maximum allowed typing latency in milliseconds [textbox]
The first option is the one selected by default. You might try changing the setting to force a maximum allowed time to 2000ms (or whatever suits your needs) and see if that helps.
As a side note: I have the exact opposite problem: the squiggles don't go away even on perfectly normal and well-formed code until I save and/or manually compile. (It's a crap shoot on which one actually works first.)
Related
Situation:
I'm using VS 2017 to build an SSIS package for MS SQL 2017. While building a Data Flow, I add the OLE DB Source and Destination. After mapping the destination, VS correctly identifies a truncation issue and gives me the warning message. (I was trying to put an nvarchar(50) into an nvarchar(10).)
I correct the issue by updating the source to limit the column width to 10 characters. SSIS build and runs fine, but the warning message persists.
Question:
Is there some way to force VS to reevaluate the package for warnings/errors? The only way I've found is to delete and re-add the destination, but that is obviously a pain. (Especially when it means remapping columns.)
Am I missing something obvious?
Not terribly. Slightly less painful might be to select a table above/below the current on in the destination. Click OK and then you get errors everywhere. Go back to the original table and the warnings have gone away.
I suppose closing and re-opening would force the designer to re-evaluate the metadata as well. But no, no button or mouse click to say call the underlying object's ReinitializeMetaData() method. At least, I assume that's the call the designer makes and then evaluates conditions like truncation possibilities
You can right-click on the Connection Manager for the components that are throwing errors and warnings (this works for errors too), set it to "Work Offline", and then do the same thing - right-click on the Connection Manager to remove the checkmark on "Work Offline".
When a Connection Manager changes state from "offline" to "online", all of the components and tasks that use it get re-validated.
I don't remember what version I was working with, but I've seen metadata get "stuck" with the wrong input length, and no amount of reinitializing would clear it. I had to open the Advanced Editor and manually change the length of the input column in order to get the warning to clear.
Essentially, I encounter the same problem as the question below, except that the accepted answer does not resolve it. I have neither warnings nor errors in the Error List:
See complete tooltip error message for Data Flow SSIS element in Visual Studio
Similar to the question noted above I can see a truncated warning message on the Data Flow design surface.
However, no corresponding warning is visible in Visual Studio's Error List view.
How can I view the entire warning?
This is a bit misleading from Visual Studio and could have been handled better. The long and the short of it is that the Error List window lists only messages that are related to build issues.
The warnings and errors that you see in design time are related to the execution flow. In other words, a package can be built correctly but is designed in such a way that it will generate an error. For more reading:
MSDN: Cannot see errors or warnings in SSIS - why ?
SQLServerCentral: Cannot see errors or warnings in SSIS – why ?
You will need to run the package in debug mode and then go to the Progress window. From there, you can see all messages (e.g., information, warnings, errors, etc.). Some messages may be so long that they cannot be seen. For those messages, you can click on them and paste them into your favorite text editor.
Note: when you stop debugging, the Progress window changes its name to Execution Results and the error List window becomes available.
Update
Per Hadi's follow-up comment, I was initially able to re-create the OPs problem by just modifying an existing package to create the warning message. I then built and ran the project with without receiving any error messages.
Now, after having left the office and shutting down Visual Studio, I am unable to recreate the error. The Error List window now populates with the messages. I tried building a new package from scratch without any luck either. My best recommendation at this point would be to, as with all Microsoft products, restart the application if it is not working as it should be.
This text truncation issue/bug is not just tooltips.
It's in SSIS Toolbox (description box at bottom) - no way to see the entire text describing the task/component (if not too big you can increase the width of the pane but that is not really acceptable).
(VS/SSDT 2019)
Many things to try
Try to change the combobox selected value from Build + Intellisense to Build only
Open and close the OLEDB Source by double clicking on it, since you tried to build the package the warnings disappears from the Error List, you must revalidate the component to show them
Try to update the Visual Studio 2017 to the latest release
I have been given a project that is the biggest pile of spaghetti I have ever seen, with 0 unit tests or any obvious naming conventions.
I find it hard to believe there is still no way while running in Debug to have Visual Studio automatically break on the next executing line of solution code.
In this case, I know the code is hitting a specific 5000 line of code file - but there isn't even an easy way to just write a breakpoint to every single line!
Is there any logical reason why in 2017 (or even 2010) this functionality doesn't exist?
Or perhaps it does and I haven't found out how!
Is there any logical reason why in 2017 (or even 2010) this functionality doesn't exist?
Please Put a break point in your code -> debug, then Right click on the text editor in VS, you will see below:
You can use the "Break all" button in the visual studio (Ctrl+Alt+Break is the default shortcut).
You might need to switch between the running threads in order to see highlighted instruction within your code.
Then you can just continue debugging, as usual.
If you do not see any of those two controls, go to View->Toolbars and check both "Debug" and "Debug Location".
What happens in VSC15 is a filename[stale].cpp is created and stepped through instead of the main edited file. This wouldn't be a problem except it not longer allows me to see any of the values of any variable when I mouse over or watch it making live debugging significantly less useful for me.
What used to happen is you'd be stepping through and the yellow cursor would just be some amount of lines off of where it actually was based on the compiled version of the file. I could still see all values so long as they were in memory.
Is there any way to get this functionality back? As it stands now I need to completely restart the app every time I make a change (frequently) if I want to still see any valuable debugging info.
Edit and Continue is also arguably not a solution.. Wish it were.
You should be able to get the behavior you're looking for (make changes to your source but not use Edit and Continue) by disabling the debugger option Debug > Options > Enable Native Edit and Continue.
Having this option disabled won't bring up the "Edits were made that could be applied..." dialog, but will instead silently ignore your edit and not go into any stale code.
I've answered your linked question, so I hope Edit and Continue is a solution :)
-Ramkumar,
Visual Studio Debugger
Is there a good way to debug errors in the Visual Studio Designer?
In our project we have tons of UserControls and many complex forms. For the complex ones, the Designer often throws various exceptions which doesn't help much, and I was wondering if there's some nice way to figure out what has gone wrong.
The language is C#, and we're using Visual Studio 2005.
I've been able to debug some control designer issues by running a second instance of VS, then from your first VS instance do a "Debug -> Attach to Process" and pick "devenv".
The first VS instance is where you'll set your breakpoints. Use the second instance to load up the designer to cause the "designer" code to run.
See Debugging Design-Time Controls (MSDN).
It has been a pain in 2005 and still is in 2015. Breakpoints will often not hit, probably because of the assemblies being shadow copied or something by the designer(?). The best you can do is to break manually by introducing a call to Debugger.Break(). You may wrap it into a compiler conditional as so:
#if DEBUG
System.Diagnostics.Debugger.Break();
#endif
int line_to = break; // <- if a simple breakpoint here does not suffice
I have had this happen many times and it is a real pain.
Firstly I'd suggest attempting to follow the stack trace provided by the designer, though I found that often simply lists a bunch of internals stuff that isn't much use.
If that doesn't work then try compiling and determining the exception from there. You really are flying blind which is the problem. You could then try simply running the code and seeing what exception is raised when you run it, that should give you some more information.
A last-gasp approach could be to remove all the non-generated code from the form and gradually re-introduce it to determine the error.
If you're using custom controls you could manually remove the generated code related to the custom controls as well if the previous method still results in an error. You could then re-introduce this step-by-step in the same way to determine which custom control is causing the problem, then go and debug that separately.
Basically as far as I can tell there's no real way around the problem other than to slog it out a bit!
I discovered why sometimes breakpoints are not hit. In the Attach to Process dialog, "Attach to:" type has to be "Select..."'d.
Once I changed to "Managed 4.0, 4.5", breakpoints for a WinRT application were hit. Source: Designer Debugging in WinRT.
Each one is different and they can sometimes be obscure. As a first step, I would do the following:
Use source control and save often. When a designer error occurs, get a list of all changes to the affected controls that have occurred recently and test each one until you find the culprit
Be sure to check out the initialization routines of the controls involved. Very often these errors will occur because of some error or bad dependency that is called through the default constructor for a control (an error that may only manifest itself in VS)
You can run a second instance of VS and attach it to the first instance of VS (Ctrl+Alt+P). In the first instance set the breakpoints, in the second instance run the designer, and the breakpoint will fire. You can step through the code, but Edit-and-Continue will not work.
For Edit-and-Continue to work, set you control library's debug options to run a VS with the command line argument being the solution filename. Then you can simply set the breakpoints and hit F5. It will debug just like user code! As a side note, you can do this will VS and Office add-ins also.
This worked for me for Visual Studio 2022:
I opened a second Visual Studio instance
In the second instance I clicked Debug -> Attach to Process...
I selected DesignToolsServer from the process list
More details: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/walkthrough-debugging-custom-windows-forms-controls-at-design-time?view=netframeworkdesktop-4.8