When hitting a function breakpoint, if the source code window is dismissed the No Source window pops up, indicating that the Frame was not module and source code cannot be opened. (See screenshot below).

Note that you can still open source code by using the callstack view. The expected window is "filename not found".

Configuration used:
`

exec-run

`

In an android native activity application:

for (;;)
{
    int i = 0; // set brekapoint here
}

1. Set a breakpiont on the line specified.
2. Start debugging, breakpoint will be hit.
3. Disable breakpoint (do not delete it).
4. Continue the process.
5. Enable the breakpoint.

Expected: Breakpoint is hit.
Actual: Breakpoint is not hit. Process does not stop.

Workaround: It appears that enable/disable works from break mode, so async break and then enabling will work.

I've noticed that there is no difference between step-in and step-over when stepping in the disassembly view. Looking at the GDB log, I see that VS is always issuing the "stepi" command in this case, where it should be using "nexti".
-joe porkka
https://visualstudiogallery.msdn.microsoft.com/35dbae07-8c1a-4f9d-94b7-bac16cad9c01/view/Discussions

On the version of GDB that I have on Linux (Ubuntu 7.7.1-0ubuntu5~14.04.2), gdb doesn't support an -exec-abort command. I went through all the mi commands using strings on it. It appears that the only way to kill the process is to use the non-mi 'kill' command.

I have a question about extensibility of MIEngine.
I have seen the csharp debugging demo(VS Code on Mac) shown in connect 2015.
Is the demo based on MIEngine ?
How can gdb/mi protocol control csharp managed code debugging information ?
Thank you.

Not sure if this is an MIEngine issue of lldb.

Hi,
Long story short,
When modules are loaded (e.g. shared libraries), an event is sent back to the SDM,
but never received by my VSPackage debug events callback listener.

Now the details:
File: src\MIDebugEngine\Engine.Impl\EngineCallback.cs
Function: public void OnModuleLoad(DebuggedModule debuggedModule)

Is called whenever a module is loaded, and an event is sent back to the SDM.

From another VSPackage, MyVSPackage1, I subscribe to debug event callbacks
and implement int IDebugEventCallback2.Event.

Unfortunately, I never see the "module load event" coming from MIDebugEngine.dll, but only
the ones coming from the (MSFT C++) native debug engine
(yes, I have 2 engines running at the same time, but attached to different processes).

Any idea why SDM won't forward this event to the listener?

More information can be found here [1].

Thanks,
Ofir Cohen

[1] https://social.msdn.microsoft.com/Forums/sqlserver/en-US/3d628919-7a10-4a1d-aa9e-e04e95649150/idebugmoduleloadevent2-event-is-never-triggered-by-my-debug-engine?forum=vsx

my code is in the old VS.So I can't use this tool!

Hello,

I've also posted this question on "Visual Studio Integrate" forum [1],
but this might be the more appropriate forum to discuss and raise this question.
Also, since the VS IDE hang is sporadic (see problem below), I'm concerned
that suggestion solution (launch with /log) might not address/reveal the problem.

Would very much appreciate any help :-).

Problem

I am working on a custom debug engine that debugs applications on some custom proprietary runtime.

My goal is to be able to debug native applications and proprietary code at the same time,

But it appears that getting the SDM to synchronize the paused/running state across all debug engine is a non-trivial task.

I get random VS IDE hangs and I need to kill Visual Studio and start all over again.

Details

This custom debug engine [1] is a fork of MIEngine, and is a gdb and gdbserver based solution

for debugging our applications running inside the proprietary runtime.

Scenario

1. User launches a native (host) application
2. Our VSPackage (MyVSPackage1) intercepts the IDebugLoadCompleteEvent2 event
3. on IDebugEventCallback2.Event callback (by calling AdviseDebugEventCallback).
4. When we receive an IDebugLoadCompleteEvent2, we launch gdb and gdbserver
   (we call LaunchDebugTargets4 by calling ExecuteCmd(MIDebugPackage.MIDebugLaunch))

Now, at that point in time we have 2 debug engines running in parallel.

Whenever a break event happened, e.g. you stopped in a breakpoint in your native C++ application,

VS calls CauseBreak(), and we wish to pause the debuggee on our custom debug engine.

The implementation at MIEngine GitHub repo doesn't wait for acknowledgement

that the debuggee stopped, and it is executed asynchronously.

The problem with that is that the state of our debuggee is not synchronized with Visual Studio,

and it causes lots of errors and issues.

To alleviate that, we force the Main UI thread (I know it's horrible and that's why I'm here)

to wait until we also stop/continue, something like that:

public int CauseBreak()
{

        _debuggedProcess.SDMSyncEvent.Reset();

        _pollThread.RunOperation(() => _debuggedProcess.CmdBreak());

        // Blocking the VS IDE main thread for 10 seconds,
        // as this is the only way to keep the SDM in sync
        // with our debug engine.
        //
        bool stopped = true;
        if (_debuggedProcess.ProcessState != ProcessState.Stopped)
        {
            stopped = _debuggedProcess.SDMSyncEvent.WaitOne(SYNC_EVENTS_TIMEOUT);
        }

}
and the same is done in AD7Engine.cs, Continue().

It fixes the original problem of being out-of-sync with VS, but creates another problem, VS IDE sporadically hangs

while debugging, and it didn't happen before this fix was introduced.

So my questions to you:

1. Is the above the correct way to synchronize between two debug engines?

 Or there is some SDM wizardry to make the debug engines co-exist peacefully?

2. Why would the main UI thread hang? I provided a timeout of 10 seconds,

I would expect the message pump thread or whatever to gracefully recover.

Thanks,
Ofir

[1] https://social.msdn.microsoft.com/Forums/sqlserver/en-US/b7ddffc7-5baa-4d3d-a013-dee18139e763/mixed-debug-engines-how-to-synchronize-access-between-multiple-debug-engines?forum=vsx

Address breakpoints are currently not supported ('Unsupported Breakpoint Type").
Are there any plans to add this in the future?
It would sometimes be helpful to be able to set breakpoints in the disassembly window. The restriction to source lines prevents inspection of code that covers a single source line, but consists of multiple instructions. Would also help to get around in code that has no debug info. (libraries)

I'm wonder if variable in watch window can be displayed using gdb pretty printers or equivalent system.
I make a test with gdb and std::vector type is shown in "raw" format. Pretty printers is enabled because I can see variable in "pretty" format within command window (Debug.MIDebugExec print myvar).

Having a Microsoft.MIDebugEngine.pkgdef with hardcoded features supported and GUIDs of the debug-engine could be improved and simplified. This file could be generated directly from source code to be always up-to-date by dedicated RegistrationAttribute. Especially, it will make the redistribution easier.

I already used the dedicated DebugEngineRegistrationAttribute attribute here in my plugin.
I could port it here instantly. What properties should be exposed by this attribute to cover all features of MIEngine?

Diagnostics are crucial to figure out why visualizations aren't working.
But with remote debugging they aren't printed to the Debug Output pane.

In some applications Visual Studio hangs when enabling Hexadecimal display in the call stack window.

I have a dump of the hang to share internally

It appears that lldb produces frames with -1 as the line offset. MITextPosition does not handle negative integers and launch fails.

The test machine was Ubuntu 14.04.

The config file used:
<PipeLaunchOptions xmlns="http://schemas.microsoft.com/vstudio/MDDDebuggerOptions/2014" PipePath="F:\MIEngineWorkspace\plink.exe" PipeArguments="-i F:\MIEngineWorkspace\private.ppk [email protected] -batch -t lldb-mi-3.6 --interpreter mi" ExePath="~/Shared/TargetApp/targetapp" TargetArchitecture="x86_64" MIMode="lldb">

Resulting output
MS_MIDebug: (1439629) ->1005-thread-info MS_MIDebug: (1439629) -> MS_MIDebug: (1439629) ->1005^done,threads=[{id="1",target-id="targetapp",frame={level="0",addr="0x00400df1",func="main",args=[],file="main.cpp",fullname="/home//wiktor/Shared/TargetApp/main.cpp",line="25"},frame={level="1",addr="0x7f7f7079dec5",func="__libc_start_main",args=[],file="??",fullname="??",line="-1"},frame={level="2",addr="0x00400ca9",func="??",args=[],file="??",fullname="??",line="-1"},state="stopped"}]

Resulting exception

    Microsoft.MICore.dll!MICore.Debugger.ParseUint(string str, bool throwOnError) Line 1214 C#
Microsoft.MICore.dll!MICore.ConstValue.ToUint.get() Line 246    C#
Microsoft.MICore.dll!MICore.ResultValue.TryFindUint(string name) Line 110   C#
Microsoft.MIDebugEngine.dll!Microsoft.MIDebugEngine.MITextPosition.TryParse(MICore.TupleValue miTuple) Line 43  C#
Microsoft.MIDebugEngine.dll!Microsoft.MIDebugEngine.ThreadCache.CreateContext(MICore.TupleValue frame) Line 172 C#
Microsoft.MIDebugEngine.dll!Microsoft.MIDebugEngine.ThreadCache.CollectThreadsInfo(int cxtThreadId) Line 239    C#

`

The initial guide suggests that debugging MIEngine could be started automatically as soon as F5 is hit, when solution is opened. That's not correct for me and should be updated. Or am I doing something wrong?

I noticed that MIEngine actually shares the same GUIDs as VS build-in MDD debug-engine used for Android development (which RTM version doesn't work for me neither; can't start debugging on my 2 non-VM machines, failing with 'Reference not set to an instance of object' exception). That's why MIEngine is never loaded, then no breakpoints are working etc.

Very first step is actually following redistribution instructions to customize the GUIDs. Then it works as expected.

GDB supports child process debugging. This is the backlog item to add support to mi-engine for that. Note that this is a customer ask.

We don't have a story right now for how console input/output would work if we launched a process under the debugger.

This has two big problems:

1. The program is going to get the input that we want to send to gdb
2. There is no way for the user to send the input they would like to send to their program

Possible implementations that I can think of:

1. Run the program under gdbserver so we can avoid the problem
2. SSH into the box a second time to create a separate terminate, and redirect the output of the program using -inferior-tty-set.
   Ex:
   A. SSH in
   B. Run 'tty' to find out that device id.
   C. Run a program which isn't reading from stdin (ex: sleep)
   D. -inferior-tty-set /dev/pts/6
   E. -exec-run

Hi,
I am the author of the plugin that enables development targetting BlackBerry devices directly from Visual Studio (or being more precise - I forked originally abandoned BlackBerry project and made it usable).
The mentioned plugin already has a GDB integration and as a starting point I wish to write some glue layer, that would allow me to have both (original and MIEngine) available. Do you see any problem with my integration with the MIEngine? Should I create a user story for that propose or any architecture drawings? All ideas are welcome.
This plugin has also some nice features in it, that I would love to port back, if possible. At the end of the day I would love to have MIEngine as the main debugger, but this could take longer time as I estimate ;)

the script should take some sort of flag such as 'dev' in order to pull down Microsoft.VisualStudio.clrdbg.dev instead of the standard package.

We aren't seeing specific issues from this yet, but AD7PendingBreakpoint.Bind() ends up calling several AD7 COM api calls off of the main thread, which is a bad. In VS IDE, this will invoke vsdebug directly from background threads.

Most of these calls happen in the BindAsync function or lower in MIEngine. BindAsync() is either executed directly on the worker thread if we are stopped, or indirectly on the event thread when we stop due to internal break.

Some of the calls are HostMarshal calls, which become Marhsal.GetObjectForIntPtr calls in VS IDE, or calls on AD7 interface objects, such as IDebugDocumentPosition2.GetFileName

Example:

case enum_BP_LOCATION_TYPE.BPLT_CODE_FILE_LINE:
    {
        IDebugDocumentPosition2 docPosition = HostMarshal.GetDocumentPositionForIntPtr(_bpRequestInfo.bpLocation.unionmember2);

        // Get the name of the document that the breakpoint was put in
        EngineUtils.CheckOk(docPosition.GetFileName(out documentName));

        // Get the location in the document that the breakpoint is in.
        EngineUtils.CheckOk(docPosition.GetRange(startPosition, endPosition));

        // Get the document checksum
        if (_engine.DebuggedProcess.MICommandFactory.SupportsBreakpointChecksums())
        {
            // TODO: This will need to be configurable in the future somehow
            // TODO: We might want the MICommandFactory to return the algorithm we should use
            // TODO: But HashAlgorithmID is not part of MICore becuase it uses AD7Guids
            HashAlgorithmId[] hashAlgorithmIds = { HashAlgorithmId.SHA1Normalized };

            try
            {
                checksums = GetChecksums(hashAlgorithmIds);
            }
            catch (Exception)
            {
                // If we fail to get a checksum there's nothing else we can do
            }
        }

        break;
    }

This whole code path needs to be cleaned up so that AD7 interface calls are only made from the main thread.

Debugging the following little program on a CentOS 5 target with MIEngine and gdb 7.6.1-47.el5 stops the debugger without any way to continue:

#include <iostream>
#include <dlfcn.h>

int main() {
    std::cerr << "Hello World";
    //std::cerr << std::endl; // fixes the issue

    if(!dlopen("libpthread.so.0", RTLD_LAZY)) {
      std::cout << "error: " << dlerror() << std::endl;
      return 1;
    }
    return 0;
}

The last message in the log reads:

Hello World*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="11"

The problem appears to be a missing newline on the cerr pipe which hides the gdb message that follows afterwards. Adding the newline fixes the issue.

I try to add a function breakpoint before starting target. At debugger startup, function breakpoint failed.
Can I used function breakpoint ? Is it implemented in MIEngine ?

class llvm::Type {
  enum TypeID {
  ...
  };
  unsigned IDAndSubclassData;

  <Type Name="llvm::Type">
    <DisplayString>{(TypeID)(IDAndSubclassData &amp; 0xFF)} data: {IDAndSubclassData >> 8}</DisplayString>

[Type]  -var-create: unable to create variable object data: 0   llvm::Type

Changing it to <DisplayString>{(llvm::Type::TypeID) makes it work for remote debugging.

Does not support the format specifiers yet like ,su for unicode strings. See https://msdn.microsoft.com/en-us/library/75w45ekt%28v=vs.140%29.aspx

I suggest we open a bug and do the fix. Treat the -1 as a zero I suppose; maybe just ignore the thread? Will have to try with the sample project to see if we can repro the behavior though.

(8240) ->1009^done,threads=[{id="10",target-id="Thread 936",frame={level="0",addr="0x40036fc0",func="__ioctl",args=[],from="libc.so"},state="stopped",core="0"},{id="9",target-id="Thread 935",frame={level="0",addr="0x40036fc0",func="__ioctl",args=[],from="libc.so"},state="stopped",core="0"},{id="8",target-id="Thread 931",frame={level="0",addr="0x400380e0",func="__futex_syscall3",args=[],from="libc.so"},state="stopped",core="0"},{id="7",target-id="Thread 930",frame={level="0",addr="0x400380e0",func="__futex_syscall3",args=[],from="libc.so"},state="stopped",core="0"},{id="6",target-id="Thread 929",frame={level="0",addr="0x400380e0",func="__futex_syscall3",args=[],from="libc.so"},state="stopped",core="0"},{id="5",target-id="Thread 928",frame={level="0",addr="0x400380e0",func="__futex_syscall3",args=[],from="libc.so"},state="stopped",core="0"},{id="4",target-id="Thread 927",frame={level="0",addr="0x40037ba8",func="recvmsg",args=[],from="libc.so"},state="stopped",core="0"},{id="3",target-id="Thread 926",frame={level="0",addr="0x400379a0",func="__rt_sigtimedwait",args=[],from="libc.so"},state="stopped",core="0"},{id="2",target-id="Thread 924",frame={level="0",addr="0x400380e0",func="__futex_syscall3",args=[],from="libc.so"},state="stopped",core="0"},{id="1",target-id="Thread 921",frame={level="-1",addr="0x40757610",func="??",args=[]},state="stopped",core="0"}],current-thread-id="1"

Using appropriate gdb commands in local launch options the MIEngine can be made to load a core file. But gdb never generates anything that looks like a stopping event, so the MIEngine never raises the event to the UI. Suggest that LaunchCompleteCommand.Core is added to generate such an event.

The locals tests currently hits breakpoints that are not set. I have not investigated it yet. The TestScript.xml currently contains additional go's to get past these false breakpoint events.

Is there any information about what clrdbg is, where it is available from, etc? The README doesn't link to anything for it, so it isn't clear (to me at least).

Depending on where in my code I set breakpoints debugging sometimes works fine, sometimes everything hangs which can only be resolved by killing plink.exe (no timeout?) and sometimes I get this oscure error:

In this case I tried to circumvent the problem by setting a breakpoint programmatically. It brings up the dialog whether it should break or continue and after clicking either I get 139.
Debugging the program with gdb on Linux itself works fine.

Not sure what to do about it, quite a blocker.

I create app with wizard template "Native-Activity Application (Android)". Compile it as x86, set some breakpoints into 'android_main' and run debug. App was sucessfully deployed into emulator and runs. But breakpoints do not hits, and in breakpoints window appears with empty circles.

Environment:
Visual Studio 2015
CrossPlatform installed. Also i tried to checkout and run MSIEnine project with the same effect.

Emulator:
BlueStacks 2.1.8.5663

shell@klte:/ $ getprop ro.build.version.release
4.4.2
shell@klte:/ $ getprop ro.build.version.sdk
19
shell@klte:/ $ cat /proc/version
Linux version 3.10.30-android-hd (build@Build2) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #1 PREEMPT Tue Mar 22 19:05:48 IST 2016

Build log:
1>------ Rebuild All started: Project: Android2.NativeActivity, Configuration: Debug x86 ------
1> ANDROID_HOME=E:\Android\sdk
1> ANT_HOME=E:\Android\ant-1.9.7
1> JAVA_HOME=C:\Program Files (x86)\Java\jdk1.8.0_101
1> NDK_ROOT=E:\Android\ndk\android-ndk-r11c
1> pch.h
1> android_native_app_glue.c
1> main.cpp
1> Android2.NativeActivity.vcxproj -> c:\Work\test\Android2\x86\Debug\libAndroid2.so

Debug session (with the 'Break All' at end:

Due to its size moved to "paste" service: http://pasted.co/60c83004

Target machine is Ubuntu 14.04

Xml configuration:

`

exec-run
`

targetapp contains several calls that produce newlines:

    auto result = TestClass::Add(2, 3.14f);
    wcout << result << endl; 
    usleep(500000);

    auto result2 = TestClass::Add(2, 3);
    wcout << result2 << endl;
    usleep(500000);

    auto result3 = TestClass::Add(3.05, 2.03);
    wcout << result3 << endl;
    usleep(500000);

The result in the VS output window:

145.08.145.08.145.08.145.08.145.08.145.08

As described at https://github.com/Microsoft/MIEngine#get-started, the build of the "prebuild" project is failing, and looks like NuGet is failing to use temp folder path with SPACE characters in it. (It builds fine when profile without SPACE characters in the path is used)

...
1>------ Build started: Project: prebuild, Configuration: Debug Any CPU ------
1>  All packages listed in packages.config are already installed.
1>MSBUILD : error MSB1008: Only one project can be specified.
1>  Switch: Delendik\AppData\Local\Temp\tmp2641.tmp
1>  
1>  For switch syntax, type "MSBuild /help"
1>MSBUILD : error MSB1008: Only one project can be specified.
1>  Switch: Delendik\AppData\Local\Temp\tmp2682.tmp
1>  
1>  For switch syntax, type "MSBuild /help"
1>MSBUILD : error MSB1008: Only one project can be specified.
1>  Switch: Delendik\AppData\Local\Temp\tmp26C2.tmp
1>  
1>  For switch syntax, type "MSBuild /help"
1>  
1>C:\Work\MIEngine\src\prebuild\prebuild.csproj(31,5): error MSB3073: The command ""C:\Work\MIEngine\tools\NuGet\NuGet.exe" restore -PackagesDirectory "C:\Work\MIEngine\src\packages" -MSBuildVersion 14 "C:\Work\MIEngine\src\MIDebugEngine.sln"" exited with code 1.
...
4>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.Internal.VisualStudio.Shell.Interop.14.0.DesignTime". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
...
6>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "libadb.dll". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
...
9>CSC : error CS0006: Metadata file 'C:\Work\MIEngine\bin\Debug\Microsoft.AndroidDebugLauncher.dll' could not be found

I have VSCode installed with the C# extensions that includes clrdbg. Is there some configration file I can modify to enable hitting breakpoints on files that do not end in ".cs"? If no, can this be enabled in a future release?

Hi,

My first post here: let me congratulate you on this truly awesome tool!
I work on embedded systems and being able to debug from Visual Studio is a dream come true. 😄

Now my issue.
I want to be able to debug an ELF using gbd and OpenOCD.
Right now I can start the debug session but I need to launch OpenOCD first from a command prompt.
Tried using DebugServer and DebugServerArgs to start it but it's not working.

1. I'm understanding the correct purpose for these two settings?
2. Follows my LocalLaunchOptions for you to review

Thanks!

After attaching to a process on Linux+GDB (Ubuntu 7.7.1-0ubuntu5~14.04.2), we don't have a way of breaking into the target process.

The result of this bug is that we can't get into break state to set breakpoints, or any of the other tasks we might want. So only breakpoints set before start debugging will work.

The only way I found that we could work around this is to -

1. Configure gdb to stop on SIGINT using: handle SIGINT stop
2. Using kill from the shell to interrupt the target:
   kill -TRAP

Some of the things I tried:

1. Enabling target-async before the attach. I tried both on the command line and before issuing the command.
2. Sending Ctrl-C. My debuggee has signal handlers installed, which could be the problem, but I couldn't get this to work.

When one PendingBreakpoint corresponds to more than than one BoundBreakpoints, it's possible to disable only some of the BoundBreakpoints from Visual Studio debugger UI, but MIEngine simply ignores the disable/enable operation. IDebugBoundBreakpoint2.Enable should use MI commands like "=break-disable 2.1" to disable the corresponding BoundBreakpoint.

If debugging is started with a breakpoint set but disabled, it looks like we hang. It is important that the breakpoint is set on a line where it would get hit, but is disabled when debugging is started. Async break no longer works and the debugger is hung.

I am guessing that the breakpoint gets set and hit by gdb, but MIEngine does not understand it.

I'm using the MIEngine to load a ELF file and debug with GDB.
I've reached the point of having the image loaded on the flash.
Now I'm trying to set a break point at a function where the debugger should stop. Tried with SetupCommands and CustomSetupCommands without success.
How can I do this?

Thanks,

Hello and kudos on a very nice project.

The case I've got in mind is analogous to the 'Exe project file' option in VS. Is it possible to point VS at a Linux executable for example and then set up the project to use the MIEngine via remote GDB (or similar)?

edit: oops. missed this.

https://github.com/Microsoft/MIEngine/wiki/Start-debugging-other-platforms-using-the-MIEngine

Many thanks

Jerry

Hi,
I believe this is the best forum for these kinds of questions.

The project I'm working on uses an MIEngine fork that supports debugging
of GPGPU kernels on the GPU via Visual Studio.

We are really pleased with the infrastructure provided by MSFT and it
achieves most of the goals, but we still have room for improvements.

1) Are there some customizations for a GPU-targeted MIEngine?
The MSDN page [1] suggests the following:
"Independent hardware vendors who want to support GPU debugging in Visual Studio must create a
DLL that implements the VSD3DDebug interface and targets their own drivers."

But unfortunately this interface is no where to be found.

2) Performance and scalability
The GPU we are targeting contains a lot of cores,
each core is capable of running multiple threads.
When the threads window in VS is opened and a breakpoint is hit, we've noticed a severe
perf degradation, because it seems like this window is not lazily evaluated
(i.e. only for the threads that fit in within the window size, but for the entire active threads).

Is there a way to re-use the GFX debugging VS tool windows,
or improve somehow the performance?

It kind of connects to the first question.

Thanks,
Ofir

[1] https://msdn.microsoft.com/en-us/library/hh873126.aspx

I get the need for the [Visualized View] sub-menu, esp. for arrays and the like. But why can't the part be applied automatically? If you expand the main node it is already evaluated anyway:

• imageName std::string
• [Visualized View] 0x8c27c8 "foo"

"Explicit refresh required for visualized expressions", but clicking the refresh button does not work.

Since we set a breakpoint on main to act like the entry point, a user breakpoint set on main will not be hit.

Data breakpoints is always greyed out.

• request from joe porkka
  https://visualstudiogallery.msdn.microsoft.com/35dbae07-8c1a-4f9d-94b7-bac16cad9c01/view/Discussions

Using LocalLaunch options and launching a console application built with MinGw or cygwin with GDB no console window is visible.

HI
is there a reason Natvis.ShowDisplayStrings is not DisplayStringsState.On ?
it seems to prevent DisplayStrings from showing up

Problem

When trying to build a fresh clone (checkout) of this repository, it will fail miserably
if you try it via CLI using MSBuild.

Details

You have to open the solution with VS at least once in order to fetch ("nuget restore") the missing packages dependencies.

This is devastating for automated CI builds, as the NuGet packages are taken from .\packges
(this is dictated by the .csproj files), and thus need to be fetched and retrieved for every fresh clone.

I tried to Google it but couldn't find anything useful.

Does any one know how to solve/work-around that?

Is there some .csproj XML property that allows the missing NuGet packages to be retrieved
prior to building?

Thanks,
Ofir

From VS Feedback item:

1. Make two shared objects by having 2 projects in a Solution
   (Denote these by project/library 'A' and 'B')
2. In two separate projects, create a C++ source file in each with the same name
   (in my solution/workflow, "OnLoad.cpp" appears in multiple projects (which are made into multiple .so files)
3. Put a breakpoint in one of the "OnLoad.cpp" files
   (in my case, I put a breakpoint in the last library loaded by my application)
   (App loads project 'A' and then project 'B' libraries -- which means my breakpoint was in project 'B')
4. Start Debugging using GDB. If the breakpoint is in said file contained in project 'B', the debugger interprets project 'A's file with the same name and will use the breakpoints in project 'A's library -- not project 'B' as you desired.

This repros in VS IDE for MIEngine against both gdb and clrdbg.

Repro:

1. File -> New Project -> Visual C++ -> Cross Platform -> Android -> Native ActivityApplication
2. Set a breakpoint in android_main but disable it:
   
3. F5

Expected: Breakpoint exists but appears disabled and is not hit
Actual: Breakpoint appears bound but does not get hit: