Does anyone know how to have GoLand constantly inspecting errors in code? Right now it inspects ONLY the open files and shows the status on the top-right corner like this:
But in VS Code, it constantly checks all errors of the working module.
GoLand does offer manual inspection but it's not as efficient and often checks irrelevant modules too (when I set it current module then it can't detect any errors)
As mentioned in Goland issue GO-4618:
They might be limiting the contents of the Problems tool window to just the current editor for performance and usability reasons.
GO 9494 is following the issue: "Customize Problems View reporting scope"
There should be a way to customize the Problems View window to support the following scopes:
Current File
Current File's Package (I'd default to this)
All Opened Files Packages
Whole Project (IDEA-68854)
Still in progress (oct. 2021) though.
Related
I am working on a app built with MSVC 2019. In the past, I was able to view structure members in the "Variables" window while debugging (by clicking on the '+' sign). This week that stopped working: the Variables window just shows an address in hex). I've not (knowingly) changed any build settings but the problem persists. No changes to source code.
Any ideas about what I'm doing wrong?
I've tried:
Delete Debug subdir & rebuild all
Checked: Settings->C/C->General->Debug Information Format: Using /Zi, but tried all other options.
Checked: Settings->C/C++->Enable Browse Information: YES
Checked: Varibles: Hexidecimal display NOT checked.
Details:
Include file dir specified by Settings->C/C++->Preprocessor->Additional include directories:
Compiled with MSVC v2019
Dell Optiplex Win10/64
UPDATE 03/25/2021
So far, this problem only happens when I build an SSL/TLS app. I've tried several SSL packages with same result (GitHub OpenSSL, FireDaemon, Shining Light, etc.). I include ssl.h from each package.
Members of structures defined within my app are shown correctly
You should uncheck Hexadecimal Display option under Locals Window.
I found the problem. According to
https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes, many data structures have been made 'opaque' in v1.1.0 and structure members are no longer accessible.
Great day for code purists but it makes debugging hard for the rest of us poor souls.
IMHO, It does not appear to be possible to work around this.
I am trying out GoLand and hear that the debugger is supposedly awesome, but I can’t find any documentation explaining how to set it up (GoLand is in preview stage, so that’s not really surprising). My use case: I am writing a REST API to which I send requests using curl. Could someone please tell me, step by step, how to get started with the debugger ?
[edit 1] (moved from comment) When I click Run/Debug (or Run/Run), a window is displayed, asking me to edit configurations. I am given a choice of several kinds of configurations, I try to choose "Go application" but the Debug button never is grayed and I can't get it to become clickable. I am very new to GoLand, I may be missing something obvious, but I can’t find whatever settings are missing.
[edit 2] It turns out that my workspace did not conform to the Go specifications : my code was not in a directory named src. Now that it is the case, I can click Run/Debug and GoLand seems to be doing the right thing, except it doesn’t stop at breakpoints or otherwise behave like a debugger, my code just runs.
[edit 3] Tried again, and it works. Sort of. I have no idea why it works now, even though it didn’t previously and I didn’t change anything. Now breakpoints work at some lines, and not at others. Or the debugger stops at the breakpoint, but I wait forever for the list of variables to be loaded. Well, it is a preview, after all...
[edit 4] I was notified just today that a new version of GoLand was available. I upgraded, and debugging is working well for me now.
GoLand will not enable the debug action (although run is available) if your code does not reside inside src. There is no warning about this, so it might be really a pain to solve this.
Additionally, depending on your project’s structure it might be possible, that debugging is still not working. In that case, it might help to remove all run configurations and create a new one. There’s is a bug report about this behavior.
PS: Although the OP mentions the first part in an edit of the question, but it think it’s worth mentioning in an answer.
Things changed in goland since #Jamillo Santos added his reply.
To start with, there's no more "Go Application".
The easiest way is to locate the file containing the main() function.
There should be a small triangle pointing to it, like in the attached screenshot:
When you click on the small green triangle, you get a menu with Run/Debug options.
Each will create a go build configuration.
You can edit that go build configuration and add the program arguments for your application.
For example, if your program have a command line argument of --arg=value you can add it like this:
I was facing this same issue and I solved by using the "Go Application" configuration (at the Run/Debug Configurations window), instead of the "Go Single File" configuration.
So, go to the upper right corner of the Gogland and "Edit configurations".
Then, add a new configuration using the "Go Application" profile.
After saving, you should be able to debug your code. o/
An easy way to enable this configuration is to use the #user1793301 method and right click on the file you want to run and select "Debug 'go run .go'".
POSSIBLE EXPLANATION
NOTICE: I did not look any further details about it.
Fact: "Go Application" configuration does build the binary executable before running it.
Fact: I could see looking at the console output (inside of the Goglang) is that the IDE uses the DLV as debugging tool.
Fact: I found a dlv debug at the DLV documentation and it seems to compile and debug the code.
Hypothesis: The guys from Jetbrains did not implement it. Or at least not YET.
On version 2019.1.1 there's no more Go Application. Use Go Build instead. Here I am debugging a single script file, but if you have a server app or smth, just point to the main app file:
Notice that in the Files field you have to specify the actual file path. You can put more files (if you want to have more starting points) by separating them with a pipe |. For each file you want to be able to debug, you need to specify the full path.
Again, if you are debugging a server app or something else, that has a single starting point, you only need the startup file specified in the config. :)
I had this exact problem.
Deleted and recreated the Debug run configuration. Debugging then worked perfectly.
I followed the following procedure to start my golang server in debug mode. (You might want to use some other method than creating a makefile for starting your server maybe)
Create a makefile
Define your server/worker startup command in the file
Run it by creating a new configuration for Makefile
Go to Run -> Attach to process -> choose your running server
This will attach the debugger to your process.
Note:
You might need to restart your server for this to work.
The IDE will ask you to install gops, do install it. Without installing gops you won't see any running process.
I right click on project (main.go inside) and choose "Debug ..." and it work
I often get blue question marks on files in my VS2012 Solution Explorer when opening a solution bound to Perforce through P4VS.
Looks like something is having trouble to "synchronize" with the depot/workspace/whatnot. Hitting "Refresh View" always solves the issue but I'm growing tired on doing this everyday:
This is my VS version:
Microsoft Visual Studio Professional 2012
Version 11.0.61030.00 Update 4
And P4VS:
2014.1.85.4506
This is persistent across P4VS versions for a few months now, and seems to be affecting sometimes individual files, sometimes entire projects, with no apparent pattern.
How can I diagnose what's going wrong, be it a server issue, a VS issue, a workspace issue?... The Perforce Source Control output shows nothing special.
Actually it's not entire folders, it's entire projects. It appears that even if refreshing a project "fixes" the issue for one run, re-opening the solution brings it back. Whereas I think that for individual files, refreshing them solves the issue once and for all. I'll play with it a bit more to confirm that.
To help diagnose what is going wrong you should probably turn on logging, and check the preferences that will show everything in the output window. For the P4VS log, go to:
Tools- > Options -> Source Control -> Perforce - Logging
(This is not the same thing as the Visual Studio Activity log.)
There could be a possibility that you are getting disconnected and refresh reconnects you. I am not sure if you have your connection set to use solution-specific settings, since you did not mention the connection dialog coming up.
This "solved" the issue for me, at least for the entire projects that went blue-question-marked:
1) Tools > Options
2) Source Control
3) Perforce - General
4) Tick the option "Treat Solution/Project as directory when
selected"
Not sure why but that's one less annoyance for me every day. Thanks to Perforce support for suggesting that.
The file is probably not marked for version control. I noticed this icon in one file and opened Perforce to check. For whatever reason, this file was not marked for add in Perforce. After marking the file for add and submitting, the blue question mark went away.
I've got an app that uses our DAL and when I run it in debug mode (vs2010) and purposely try to make the app crash (for instance, leave the connection string empty of the DAL), vs2010 opens the code for the DAL at the point in which it crashed. Which is ok, but I'm then able to edit that .cs file and save changes, which I don't want. I've verified this by having the DAL project opened in another instance of vs2010 and when I make the app crash and change the DAL.cs in the app and save it, the DAL in vs2010 tells me that the file has been modified outside the project and asks if I want to reload it.
How can I prevent this from happening? The only reference I am using to DAL in my app is the reference to the DLL, that's all.
The AssemblyName.pdb file links the compiled DLL to the original source.
Visual Studio uses this file to display the source code when debugging.
You can delete this file and get rid of the source link.
This will give you a vastly inferior debugging experience.
Have you tried going to "Tools > Options > Debugging > Edit and Continue" and unchecking "Enable Edit and Continue"?
Make the .cs file(s) read-only. If its read-only, you'll be able to see it, but you won't be able to save changes. (Depending on your Visual Studio settings, you might still be able to edit the file in memory, but that seems irrelevant, since the changes you make won't be persisted to disk.)
If you need more fine-grained control (like where you want to be able to edit the source files, but not your testers), you can use access control lists (ACLs). Ask more questions about that on Server Fault.
Yes, you could disable debugging or turn off the generation of PDB files, but that makes it very difficult to debug the code, which is probably the reason why you're purposely trying to make the app crash.
I have a web project running in Visual Studio 2010 and target .Net framework 4. When I 'Build' the solution it will tell me the build was successful even though there are (known) errors in the code. If I open a page that has an error, the compiler will then pick up on the error and underline it in blue instead of red.
Is there a setting that would drive this kind of behavior? Any ideas on how to fix?
If you have multiple projects in your solution it is possible that one of them is not set to build. In your build output window did you see the name of the web project you are having issues with?
Also, check the build configuration manager to make sure you have it set.
If it's an MVC app, the view files (*.as{p,c}x) will not be compiled unless you explicitly enable it by passing /p:MvcBuildViews=true or enabling that flag in the project file for a given configuration.
I'm having similar (if not identical) problems with compiling an ASP.net 4.0 WebForm. I have a page that is a copy of an existing page in terms of markup, but the code-behind has not been created. As an example, the markup has an ASP:Button with a click event, but the event handler has not been declared in the codebehind yet. When I do a full Build/Rebuild/Clean etc., no errors are found. I open the page, and a compiler error is thrown. As far as I know I haven't made any changes to settings anywhere, just started doing this recently. Additionally, it appears that my break points aren't being caught anymore either. I'm not sure if the two are related, but they did start happening around the same time.