I'm coding in Go using IntelliJ IDEA with Go plugin. I am working on a project that uses gocui, which doesn't work in IntelliJ console window. So I run my program from console.
How can I attach this wonderful IntelliJ debugger to the process that runs outside IntelliJ (in my console)? I tried run -> attach to local process, but it showed an empty box.
Unfortunately right now the plugin does not support this feature. You can track the request for it here: https://github.com/go-lang-plugin-org/go-lang-idea-plugin/issues/620
However, be warned that delve does not support attaching to a running process on Windows (in case that's your OS).
You can also track the request here: https://youtrack.jetbrains.com/issue/GO-620 for Gogland.
I'll update this in case I find a way to help you run the app from the IDE instead so that you can debug it easier.
I discovered by accident one trick that allows to run my application in normal console from IntelliJ. Simply run IntelliJ from a console. Then, if I run (or debug) my application, it opens in that console.
Related
I recently wanted to try to again update my IntelliJ IDEA because I had problems before (I still have problems hence this post). I've tried re-installing, fiddling with VM options, all what the internet says, but nothing provides any answers.
It starts when I click the .exe file of IntelliJ. It will briefly pop up in the task manager, use about 20% CPU for about 8 seconds and then disappear. It doesn't open later also. I've also tried to start it from the CLI, but that gives me this:
cli-output
I currently have IntelliJ 2019 since it's the only version that works, all the other versions I tried have the same problem. Does anyone know how I can resolve this (I'm running on Windows 10)?
I had the same issue on my windows 10. To fix it go to %USERPROFILE%\AppData\Roaming\JetBrains\IntelliJIdea2021.2\ folder and try to remove idea64.exe.jdk file, then run IntelliJ again.
P.s. I'm using JetBrains Toolbox, so all files that need to run IntelliJ will be placed into %USERPROFILE%\AppData\Roaming\JetBrains automatically after installation.
Goland shows code analysis has been suspended at the top right.
I have tried Following things:
Restart GOLAND,
Re- installing goland
Memory utilisation is also not heavy.
Nothing seems to work yet, any other things that I can check?
Try this:
Press shift twice and in the context window type Inspect Code Actions
Select it and press Enter
Then from another context menu choose Configure Current File Analysis
Choose All Problems
The explanation is in the parenthesis under the Code analysis has been suspended message.
The (Doing file refresh) part refers to the fact that the IDE is currently scanning the known folders such as the project directory, the Go SDK and GOPATH or GOPATH/pkg/mod (aka GOMODCACHE since Go 1.15) to check for any differences from the last IDE usage to the new session.
This should happen in two scenarios: you are starting a completely new IDE session or you have installed a new dependency.
If this takes too long to finish, please check your settings for what the GOPATH or the project directory is or open an issue on our tracker. Please attach the IDE logs zip file from Help | Collect Logs and Diagnostics Data... from the IDE.
I've googled pretty much but i can't seem to find any information on this..
I've cloned a project from github, it opens and builds no problem. it's also added to my start menu.
I can run the program from my start menu as if it was a "normal" program.
Now I have made some changes to the sources and built it, and the changes seem to be present in the installed version (which I start from start menu) just by themselves.
my question is: is that really the case? do UWP apps get installed and updated automatically? is there a way to NOT update my installed version with my release-build every time? it seems wrong, did I miss something? (did I maybe "install" the changes somewhere along the way without noticing/by double-clicking the executable etc.) and: can I replace the executable that is started in the start menu? I tried to find where it is stored/linked, but I couldn't find anything, as there is zero information in the start menu.
Or can I rely on the start menu version always being my latest release build?
I'm confused, if someone has any information on this, I'd be really happy. :)
You are correct whenever you build and run the app on the local machine using Visual Studio it gets deployed to the system apps from where you can run it. So each time you build and run with any changes they will be updated in the system installed app as well(Basically they are same)
If you want that these changes do not get reflected in the system's app then I think you can use Device emulators available in the Visual Studio.
I encountered a hell problem when I attempted to invoke “LoadLibrary” in C# environment. The application was crashed when I pressed “Ctrl + F5” and entered the directly running environment, but it was certainly O.K. if I pressed “F5” entering the debug mode. I tried to directly run the application, it had the same errors. There are some test projects in attach files, I thought that it was enough describing the issue. How did I solve it?
Ps: The solution’s environment must be set to “Debug” and the compile form must be “X64”, then the ConsoleApplication2 project is “Startup project”.
I tried to use the “LibraryEssential” project to invoking the “MathmaticPower” function which was in “MathmaticLibrary” project. But my C# project “ConsoleApplication2” loaded “LibraryEssential” dll file by “PInvoke LoadLibrary”.
Some improvements: I tried to run the C# exe application in "Administrator", It's O.K., but I run it with other user, it's failed! Shall I must run the application in administrator role? I don't want to do so. Have any other ways for the issue?
attach files: LoadLibrary.zip
I am working on an application that installs a system wide keyboard
hook. I do not want to install this hook when I am running a debug
build from inside the visual studio (or else it would hang the studio
and eventually the system), and I can avoid this by checking if the
DEBUG symbol is defined.
However, when I debug the release version of the application, is
there a way to detect that it has been started from inside visual
studio to avoid the same problem? It is very annoying to have to
restart the studio/the computer, just because I had been working on
the release build, and want to fix some bugs using the debugger having
forgotten to switch back to the debug build.
Currently I use something like this to check for this scenario:
System.Diagnostics.Process currentProcess = System.Diagnostics.Process.GetCurrentProcess();
string moduleName = currentProcess.MainModule.ModuleName;
bool launchedFromStudio = moduleName.Contains(".vshost");
I would call this the "brute force way", which works in my setting, but I would like to know whether there's another (better) way of detecting this scenario.
Try: System.Diagnostics.Debugger.IsAttached
For those working with Windows API, there's a function which allows you to see if any debugger is present using:
if( IsDebuggerPresent() )
{
...
}
Reference: http://msdn.microsoft.com/en-us/library/ms680345.aspx
Testing whether or not the module name of the current process contains the string ".vshost" is the best way I have found to determine whether or not the application is running from within the VS IDE.
Using the System.Diagnostics.Debugger.IsAttached property is also okay but it does not allow you to distinguish if you are running the EXE through the VS IDE's Run command or if you are running the debug build directly (e.g. using Windows Explorer or a Shortcut) and then attaching to it using the VS IDE.
You see I once encountered a problem with a (COM related) Data Execution Prevention error that required me to run a Post Build Event that would execute editbin.exe with the /NXCOMPAT:NO parameter on the VS generated EXE.
For some reason the EXE was not modified if you just hit F5 and run the program and therefore AccessViolationExceptions would occur on DEP-violating code if run from within the VS IDE - which made it extremely difficult to debug. However, I found that if I run the generated EXE via a short cut and then attached the VS IDE debugger I could then test my code without AccessViolationExceptions occurring.
So now I have created a function which uses the "vshost" method that I can use to warn about, or block, certain code from running if I am just doing my daily programming grind from within the VS IDE.
This prevents those nasty AccessViolationExceptions from being raised and thereby fatally crashing the my application if I inadvertently attempt to run something that I know will cause me grief.