Linux support visual studio is nerves wrecking !

[gilesgoat]

So .. "if you ever wrote SW for a Linux system using Visual Studio on Windows 10" ( I do because the other option, develop on the 'target' machine in this case is NOT possible ) and used the "multi platform way" you know what I mean.

Fundamentally the idea is kinda simple .. kinda .. I think all it needs is the SSH can't remember what shit enabled on the "target machine" and I think "in some way" it does all via "remote shell commands".

Fundamentally you define a "target directory" let's say "~/My-Project/" and everything you do is local to your PC machine until you start compiling and then "files are copied to the target machine and compiled using gcc ( I suppose ) commands on the target machine".

I *THINK* IN THEORY what happens is something like ..

"compile main.cpp"
->
copy "main.cpp" and "main.h" to "~/My-Project/main.cpp", "~/My-Project/main.h"
run "gcc ~/My-Project/main.cpp"
copy "a.out" => PC somewhere ..

and IT KINDA does something like that , it's even clever enough to "up to a point" start GDB e/o not sure what when you launch "Debug" on the PC ..

So where are the problems ?

MANY !

First "it seems to be working one way only" .. if you change stuff on the Linux machine you won't of course find it changed on the PC machine so "don't touch anything in there it won't work".

Quite often "not sure why/how/when" .. you do modifications on files on the PC and then you re-compile only to find out that the "remote" ( Linux ) files have not changed at all.

"Intellisense" makes "a bit of a mess" with "local caches and stuff like that"

"Include paths" .. hell breaks loose .. "one thing on a PC, all another on Linux" you can't always make them work I really can't find "the logic of why/what" ..

"Okeish" IFF ( If and only if ) your Linux/PC directory structures are TOTALLY IDENTICAL, ( "root dir apart" ) if let's say you are trying to compile "a sub-dir of a bigger dir structure" like let's say you have "ALL_My_Projects/Linux Project" and "ALL_My_Projects/PC Project" and "ALL_My_Projects/Common Stuff" .. and you want to compile only the "All_My_Projects/Linx Project" you are quite in a big shit ..

There's a "copy file options" that to date I have NOT found any way to at least let me know/show "what is it copying and where" .. the options are "copy or NOT copy".

I suspect there'a a "time granularity" of some sort .. "if you modify and re-compile a file too fast" it's like "too little time elapsed to me understand you actually changed it ??" ..

Well in essence I got the point I need to use "a combination of batch files and such" to be quite sure that "stuff is really squeaky clean" and "files are really what they should be" .. yet occasionally I see "all sort of werid incomprehensible shit" happening like "directories appearing from nowhere in ~/" and files like "what the fuck is NOT working" to realise "this is not the file I am editing WHERE IS GETTING THIS FROM ???!"

If you never tried it .. try it and you'll see what I mean ...

[KlaxonCow]

There's a number of options available these days.

For example, "Visual Studio Code" runs on Linux:

https://code.visualstudio.com/docs/setup/linux

And, as that page suggests, you can develop on Windows for Linux, by using Windows Subsystem for Linux (WSL).

Windows Subsystem for Linux

With WSL, you can install and run Linux distributions on Windows. This enables you to develop and test your source code on Linux while still working locally on a Windows machine. WSL supports Linux distributions such as Ubuntu, Debian, SUSE, and Alpine available from the Microsoft Store.

When coupled with the Remote - WSL extension, you get full VS Code editing and debugging support while running in the context of a Linux distro on WSL.

So you can, with WSL, install a Linux distro and run it under Windows. Then Visual Studio Code has a "Remote - WSL" extension that allows debugging to work with WSL.

If you get something like that set up, then developing Linux code on Windows would not, really, be substantially different from local Windows development. You can run the Linux code within WSL on the Windows machine and even, via an extension to VSC, connect to it for debugging as well.

The trick with WSL is that Windows has a built-in hypervisor these days, and it can run different "subsystems" within that hypervisor. This is not emulation either, as the Linux distro is communicating with the bare metal - the hypervisor arbitrates between subsystems.

When WSL first appeared (WSL1), it was WINE-like. But WSL2 uses a hypervisor and the Linux distro is running on the bare metal. And they've eventually gotten GUI stuff to also work through WSL2 as well - the hypervisor even arbitrates this stuff now, so you can have Windows and Linux GUIs on the same desktop.

You should look into this, giles.

Though I've not myself tried Linux development via Windows by this method - as I just develop Linux software on Linux directly - if you can get it to work, then it sounds like the perfect solution. To just run - and even debug - the Linux code directly on Windows, via Microsoft's Visual Studio Code (which is cross-platform, so the same IDE works on both systems).

It's what Microsoft themselves recommend these days. Microsoft loves Linux now, ain't you heard? They're paid members of the Linux Foundation.

[Little stoned kiwi]

Just write everything in Python.

[noodles]

Why on earth would it not be possible to develop on the target machine or a similar one ?!?

[gilesgoat]

Why on earth would it not be possible to develop on the target machine or a similar one ?!?

This machine is NOT a PC ...

This machine is "a consumer product" with "a custom version" of something ...

This machine has very little documentation and almost no support ..

This machine is not really "open" is more of a "closed system" with embedded stuff ...

This machine is NOT made to be "a dev system", yes you can to an extent but anyway working on it it's a bit of PITA.

This machine is a machine where you can't ask anything to anyone because nobody answers.

It's NOT so bad as developing native on Android but "kinda close to it".

[gilesgoat]

Just write everything in Python.

It's worse .. "the official reply is" .. ".. we have SOME support for Unity .. " .. .. " .. and yes there's Unity .. " .. and " that's all .. " ...

[noodles]

Why on earth would it not be possible to develop on the target machine or a similar one ?!?

This machine is NOT a PC ...

This machine is "a consumer product" with "a custom version" of something ...

This machine has very little documentation and almost no support ..

This machine is not really "open" is more of a "closed system" with embedded stuff ...

This machine is NOT made to be "a dev system", yes you can to an extent but anyway working on it it's a bit of PITA.

This machine is a machine where you can't ask anything to anyone because nobody answers.

It's NOT so bad as developing native on Android but "kinda close to it".

oh. (I'm guessing it's the machine from the undead company? )

My choice would be Linux in a VM then as suggested above by KlaxonCow.
Hoping that MS tests these complex arrangements in Visual Studio thoroughly is wishful thinking.
You are their debugger as usual.

[KlaxonCow]

My choice would be Linux in a VM then as suggested above by KlaxonCow.

Well, as suggested by Microsoft themselves. I'm just passing on that message.