Can VisualGDB import existing CMake projects and target Linux?

[wilstark]

I have a CMake based build currently targeting Win32.  There’s around 50 build products, 40+ libraries and a few executables.  I use CMake to generate Visual Studio 2017 projects for the normal working development environment.  The CMake projects include native (C++) and managed (C#) code.  I’m now trying to add a Linux target for this code.  I’d like to be able to build and debug (native code, at least) the Linux target with VisualGDB (Custom license), just as I do Win32 today. More specifically, I’d like to generate a Visual Studio solution from my CMake files that contains both the C# projects and VisualGDB native projects so that I can build them all, and then deploy for debugging native code.

1. Can VisualGDB do this with its CMake support?
2. If yes, is there a recommended recipe for how to get there?

The CMake model would prescribe a toolchain file to run CMake with along with the VS2017 generator, and you would get what you want.  However, VisualGDB appears to operate differently, working with the CMake file directly.  So that is what I’m looking at.

Things I’ve tried:

1. I followed the CMake tutorial (using a RedHat VM on my Win10 machine to do the Linux compile – which works fine).  Then I added a simple C# project to the CMakeLists.txt file.  The VisualGDB VS solution gave me an error: Error C# is currently only supported for Microsoft Visual Studio 2010 and later. C:\usr\local\share\cmake-3.13\Modules\CMakeDetermineCSharpCompiler.cmake 5
2. I also tried to create a new VisualGDB project and import from CMake, but got the same result.  (This was attempted on a simple CMake project with 1 each of a C# exe, C++ exe, and C++ shared library.)  I see the same error reported in this case.

It appears the above 2 approaches produce basically the same result.

I also see more detailed errors (attached) in the output window when I have the CMake line in that includes my C# project.  (If I omit that line, everything works OK just like the above linked VisualGDB/CMake sample tutorial.)

The additional line in the top level CMakeLists is just the ‘add_subdirectory(ManagedExe)’ one. I’ve also attached a zip of this whole directory for reference.

I include all the extra information in case this is something that should work, but isn’t for some reason having to do with my particular details.  If there’s a different approach to take, I’d love to hear it.

Thanks for any help anyone can provide!

Attachments:

You must be logged in to view attached files.

[support]

No problem, we will help you set it up.

First of all, please note that VisualGDB itself does not support debugging of the C# code (Visual Studio itself might support it if you are running .Net Core), however you should be able to use it for building and debugging of your C++ projects.

The errors you described actually come from a CMake limitation – when targeting Linux (i.e. running on a Linux machine, or using a Linux cross-toolchain), it does not support C# targets as it does not know how to build them using the Linux tools. You could fix this in one of the following ways:

1. Instead of defining your C# projects directly, add a custom CMake macro or function to define them. When targeting Windows, this macro should expand to the regular C# project definition. When targeting Linux, it should define a custom target directly invoking the .Net Core compiler, or any other C# compiler you would like to use on Linux. This would be fairly complicated and will involve figuring out the correct flags for the tools and troubleshooting unexpected issues.
2. Skip C# targets when targeting Linux. Simply wrap their definitions with an if() statement, or use a custom macro to ensure they will not be created when targeting Linux.

We would advise starting with the second approach (conditioning out the C# targets for Linux builds). This will quickly get to the point where you could build/debug the C++ targets with VisualGDB. Then you could add C# projects to your solution using the approach shown below:

1. Add a macro to your CMake scripts that controls whether it should process C++ targets, C# targets, or both (e.g. TARGET_TYPES=CPP/CS/ALL).
2. Import the project into VisualGDB by specifying -DTARGET_TYPES=CPP. This will not trigger any errors as the C# targets will be ignored. From the Visual Studio’s point of view, you will have one VisualGDB-provided project (.vgdbcmake extension) containing all C++ Linux targets.
3. Manually run CMake with -DTARGET_TYPES=CS targeting Windows. This will generate a regular Windows solution with only C# targets.
4. Add the .vgdbcmake project created at step 2 to the solution created at step 3. From the Visual Studio’s point of view, there will be a single solution with multiple C# projects and one VisualGDB project. VisualGDB will simply ignore the C# projects.
5. If you are using .Net core, you can try fine-tuning the generated C# projects to build and run on Linux using the regular VS tools. This will not affect VisualGDB, since those projects will be separated from its CMake-based project, so you will be still able to use VisualGDB for the C++ projects.

Hope this explains. Let us know if you have further questions.

We could also do the whole setup for you (including the C# part, researching supported .Net core configurations and getting them to work) as a part of our consulting services. Feel free to contact our sales with more details if you would like a quote.

[wilstark]

Thanks for the detailed description!

Re: suggestion #2, step #2: Is it possible to script the CMake project import / .vgdbcmake project?

(Ideally, I could automatically/programmatically generate a complete functioning Visual Studio solution with C# and the .vgdbcmake projects from a source code workspace that has only my CMake files.)

[support]

Yes, the .vgdbcmake file is actually a fairly lightweight XML file that summarizes the parameters of your CMake build (source directory, build machine, toolchain, extra arguments, etc). It does not store any cached information queried from CMake, hence you can simply create it once via the Import mode in the wizard and then use the file as a template in your generator script (you may want to replace the project GUID each time if you envision including multiple .vgdbcmake projects in the same solution). Even if your project structure changes considerably, the same .vgdbcmake file will still work (and will show the new project structure), as long as the root directory and CMake invocation flags are still relevant.

[wilstark]

I’m pursuing your solution #2. Ultimately, this has a VS solution that houses my C# projects and a VisualGDB project. It looks like there might be a bug in VisualGDB that crashes VS in this setup.

Here’s one way I can reproduce:

Using VS2017 (15.8.6) and VisualGDB (5.4R2 build 2753)
File -> New -> Project -> … -> Visual C# -> Windows Desktop -> Windows Forms App.

… finish the wizard… choose project properties. See the properties. No crash. All good.

Right-click the solution -> Add -> New Project -> VisualGDB -> Linux Project Wizard
Application
CMake
GNU Make
Advanced CMake Project Subsystem checked.
“Next”
Build project over network (uses my configured Linux box, all good here)
“Next”
Store files on the remote machine (default, recommended)
“Finish”

Right-click the C# project, choose properties (as before). Crash VS.

**** UPDATE ****

Crash information in debug session implicates VisualAssist (it is further down in the call stack), and disabling VisualAssist resolves the issue.

• This reply was modified 5 years, 1 month ago by wilstark. Reason: Updated information

[wilstark]

Another update.  This crash does occur even when VisualAssist is disabled.   (Make sure the C# project’s properties actually gets opened the 2nd time.  After creating the VisualGDB project, close the C# project’s properties if it was already open, then re-open it to show the crash.)  I note that when the VisualGDB project is created, a debugger attached to the Visual Studio instance prints out a lot of information that might indicate an issue.  Not sure.

'devenv.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'C:\WINDOWS\assembly\GAC\EnvDTE90\9.0.0.0__b03f5f7f11d50a3a\EnvDTE90.dll'. Module was built without symbols.
'devenv.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'Microsoft.GeneratedCode'.
'devenv.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'Microsoft.GeneratedCode'.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00EF8274.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00EF5694.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Exception thrown at 0x772AB152 in devenv.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.

• This reply was modified 5 years, 1 month ago by wilstark.

[support]

Sorry about that. We have tried reproducing this, however could not get it to crash (please the attached screenshot and let us know if you spot some critical differences from your setup).

We will also try to suggest a few things to try that might help, but that’s a fairly wild guess:

• First of all, please update to VisualGDB 5.4R3. It uses a different initialization mechanism that might no longer trigger the bug.
• Please try disabling Tools->Options->VisualGDB->General->Debug->Hook ‘Start Debugging (F5)’. This is not needed for advanced CMake projects and is one of the few parts of VisualGDB that is using native code. You will need to restart VS after that.
• Please try completely uninstalling Visual Assist, not just disabling it.
• Please try creating a CMake-based Windows project instead of the Linux one. If it helps, try creating a Windows project and store the sources on the Windows side. The ssh:// paths used by VisualGDB for projects with direct file access might confuse some C#-related logic.

Also please try attaching to the crashing VS using both native and managed debug engines and try to get the full (native + managed) stack trace of the crash. You will need to load the symbols for native DLLs by right-clicking at them in Call Stack in order to get a meaningful trace. Feel free to post it here even if it doesn’t contain any VisualGDB frames and we might be able to suggest something.

Finally, as we could not reproduce it on our side, completely resetting your VS environment (i.e. removing all plugins, %LOCALAPPDATA% folders, etc) might solve this completely. It could be faster than trying to pinpoint the problem (you can quickly check it by installing VisualGDB on another machine).

Attachments:

You must be logged in to view attached files.

[wilstark]

OK, it appears that you don’t need Visual Assist to cause the problem.  I uninstalled and it still crashes.

Turning off ‘Start Hook Debugging’ had no effect.

Changing to local source (Windows and not Linux) appears to NOT show the problem. So perhaps it is related to ssh paths then?

Attached is the callstack and debugger output when I reproduce (CMake project with sources stored on Linux).  I can reproduce the issue by creating a new project (as described above), or adding an existing .vgdbcmake project to the solution with my C# project.

I’ll also attach my .vgdbcmake file.  Let me know if I can provide more information.

 

Attachments:

You must be logged in to view attached files.

[wilstark]

Well, your system did not permit the .vgdbcmake file attachment, so I’ll try again.

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the update. The .vgdbcmake file you attached looks very similar to the one we tested, so the crash is likely caused by some plugin, or Visual Studio component that is present on your machine, but not in our test environments.

The easiest way to narrow it down would be to try reproducing the problem on a different machine (or a different user account) and if it doesn’t crash, comparing the other VS extensions and VS versions. Please also consider installing VS2019 Preview, as it will also start with a clean environment and VisualGDB now fully supports it.

Alternatively, please try re-creating your project using the “Store files on Windows and upload them via SSH” mode. It will completely eliminate the “vgdb://” file paths used by VisualGDB, so the problem might stop triggering.

BTW, sorry for the hiccups with the file attachment system. It is on our list, although we are currently prioritizing a few product updates over it.

[Author]

Posts