C++ compiler options -frtti and -fthreadsafe-statics are applied to C source files. Don't see a way to disable them under properties.

gcc -c -x c /root/projects/LinDemo/MainDemoSource/TcimDemo.cpp -I /root/projects/LinDemo/MainDemoInclude -g2 -gdwarf-2 -o "/root/projects/LinDemo/obj/x86/Debug/TcimDemo.o" -Wall -O0 -fno-strict-aliasing -fno-omit-frame-pointer -fthreadsafe-statics -fexceptions -frtti

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Application Type\Linux\1.0\Linux.Common.targets(245,5): warning : command line option "-fthreadsafe-statics" is valid for C++/ObjC++ but not for C

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Application Type\Linux\1.0\Linux.Common.targets(245,5): warning : command line option "-frtti" is valid for C++/ObjC++ but not for C

VC_Linux 1.0.5

Debugger only shows raw gdb view of STL containers: std::list, std::vector etc., which is uninformative.
On most Linux systems, gdb print command is extended with a number of additional commands: plist, pvector etc., via a gdbinit script. This is sometimes referred to as 'pretty printing'. See http://www.yolinux.com/TUTORIALS/GDB-Commands.html#STLDEREF for more information.

On Windows, the VS debugger can inspect STL containers and the same functionality should be made available to VC_Linux.

Known issue added here to track progress.

Visual Studio 2015 Pro Update 3
Windows 10 insider latest
VC_Linux 1.0.4
Mageia Linux 5 (x64)
gcc 4.9.2 / gdb 7.8.1 / gdbserver 7.8.1

Should we? The example on the blog using OpenGL is fairly popular, particularly for demoing what is possible. This would make it easier to get started.

Today if you accidentally press CTRL-F5 instead of F5, you get the cryptic message: "Unable to start program 'app_process'. The filename, directory name, or volume label syntax is incorrect."

Description
In case when a project is including source files from multiple non-child directories something weird happens with the layout on the remote machine. I am currently porting an existing VisualGDB based project to this extension and it kept the sources in an external folder, VisualGDB seemed to handle that but because of this bug I can't port the project to VSLinux.

Assume the following file layout:

src/
    bad_folder/
        bad_include.h
    bad_layout_project/
        main.cpp
    good_layout_project/
        main.cpp
projects/
    windows/
        bad_layout_project/
            project file
        good_layout_project/
            project file
        solution file

bad_layout_project project uses the main.cpp from the src/bad_layout_project/ folder and the bad_include.h from the src/bad_folder/ folder, while good_layout_project references the main.cpp from src/good_layout_project/ folder.

What happens (at least what I expect) is that when I build the solution the layout on the remote machine for both projects is similar, however that is not the case.

Expected results

I would expect the remote layout to look like this:

remote root/
    bad_layout_project/
        bad_folder/
            bad_include.h
        main.cpp
    good_layout_project/
        main.cpp

Actual results

This is the remote layout I get:

remote root/
    bad_layout_project/
        bad_folder/
            bad_include.h
        bad_layout_project/
            main.cpp <--- shouldn't it be a lever higher?
    good_layout_project/
        main.cpp <-- as expected

screenshots from winscp:

Steps required to reproduce the error

I've attached a zipped version of the project so it should be very easy to reproduce the issue.

• Required packages and commands to install
  bad_layout_solution.zip

See our contributing instructions for assistance.

I would like to create a solution consisting of four Shared Object libraries: libA.so, which has two dependencies: libAA.so and libAB.so, which itself has a dependency: libABA.so.

To get started I'm simply attempting to link two Shared Object libraries: libA.so and libAA.so. Each library just consists of a single function. The function in libA calls the function in libAA. libAA compiles fine.

I have added the absolute path to libAA in libA's Additional Dependencies project property. I have also added a reference to libAA to the libA project.

The command line for LibA is:

-o"C:\Users\Duncan\OneDrive\A\A\bin\x64\Debug\libA.so.1.0" -Wl,-z,relro "/root/projects/AA/bin/x64/Debug/libAA.so.1.0" -shared -Wl,-z,noexecstack -Wl,--no-undefined -Wl,-z,now

When I attempt to build libA I get an error:

relocation R_X86_64_PC32 against undefined symbol `_Z11FunctionTwov' can not be used when making a shared object; recompile with -fPIC

I switched on diagnostic build output and had a look at the build command lines for both libA and libAA. I found that neither of the commands included the -fPIC switch to stipulate output of Position Independent Code. As I understand it PIC is generally recommended for Shared Objects, and it seems when linking one .so to another .so it is perhaps a requirement.

Is there a way I can add the -fPIC switch to the build command line in the project properties? I have looked at all the properties and cannot see how to add it? If it cannot be added in project properties, can I open up the .vcxproj file and edit the XML to enable -fPIC? Otherwise is there another solution to this scenario of chaining multiple Shared Object Libraries?

Thanks for creating this excellent extension,
Duncan

Sometimes a little Linux box just doesn't have the oomph to compile. There are cross compiler tools available, we should use them.

One of the attractions (and challenges) of developing applications for Linux is the wide range
of platforms it runs on and, therefore, might need to be targeted. PC(x86) and ARM are the most common but there are many others with varying levels of demand and support. And, of course, variations within a given architecture.

One possible solution is cross-compilation, Issue #19. But this can be difficult to setup and doesn't readily support debugging. Much easier to have an appropriately configured remote system available. In my case, for example, I'll use a VM for 32-bit and 64-bit Linux on PC and have a Raspberry Pi on my desk for ARM.

Proposal

It would be very useful for a build of the ARM target to automatically select the Pi, and a build of an x86 target to select the VM.

We set the Linux Connection in Tools / Options / Cross Platform / C++ / Linux . This already allows multiple connections to be established, although it only appears to use the first one. So we can, for instance, setup a connection to an 'x86_64' target (PC) and another to an 'armv7l' target (Pi3). And the connections manager recognises the architecture and OS of the target: x64/unknown and ARM/Raspbian, in my case.

Matching the project target to a remote connection so that simply changing the 'Active Solution Platform' in the project properties would select the corresponding remote system for building and debugging.
And Build / Batch Build... would build every project configuration in turn on the corresponding
remote systems.

One question : what should happen when two connections are configured with the same target
architecture? Should the build be run on the first that can be reached, allowing for remotes
that might be turned off or changed locations? Or should the build be run on all so you might have a Debian build, a RedHat build etc. ?

Docker now provides Windows users with Docker for Windows that basically hides all the complexity of running a Linux host on Hyper-V, sharing files between Windows and the linux containers etc.

One very good usage of Docker is to use containers to build code using a special purpose container image (or even build code directly from a Dockerfile to benefit from the docker image cache), and run/debug in a container supporting GDB.

It would be really nice to get this experience from Visual Studio.
If you need some support or more info from the Docker for Windows team, fill free to contact me.

Opening an issue to document a change ahead of having a home for docs.

We now have over ridable timeouts through project customization for command execution, compile, link and the archiver. The default value for timeout has been increased to 30 minutes so most people won’t need this. If you do need to increase this value, unload your project in VS and then edit it. Under the element add an element from this list corresponding to the value you need to change.
• RemoteExecuteTimeout
• RemoteCompileCommandTimeout
• RemoteLdCommmandTimeout
• RemoteArCommmandTimeout

Please use the following bug reporting template to help produce actionable and reproducible issues:

• A brief description
  The extension does not seem correctly installed although it works well in most ways. The tools/options/crossplatform/C++/connection manager does not have the LINUX field shown in your how to, and more importantly the servers that I have installed there do not appear in any sort of list in the properties of projects so I can select them for debugging.
• Expected results
  In the property pages under remote settings - to be able to see and select from the ssh linux servers configured.
• Actual results (with build output window contents if applicable)
  no way to get VS to choose the server.
• VC++ version, Linux system name and version, GCC/GDB/gdbserver version, CPU arch, etc. If you are using a specific version of Linux on an embedded board, we might need to know about it to get a repro on similar hardware

VS2015 enterprise Ubuntu servers

• Steps required to reproduce the error
  none - it is persistent.
• Required packages and commands to install
  the extension for Linux.

See our contributing instructions for assistance.

Visual Studio C++ Development for Linux fails when the user on the remote machine runs anything else but sh/bash as default shell.

For instance, when using fish shell on Archlinux, the linux console window remains blank and trying to debug gives "Could not select a remote port for gdbserver to listen on."

This is because you're sending the following command:

netstat -tln | awk '{gsub(/.*:/,"",$4); print $4}' | grep -o '[0-9]\+' | sort -un | awk -v n=4444 '$0 < n {next}; $0 == n {n++; next}; {exit}; END {print n}'

Which is not valid in fish syntax. You may want to send all this through sh -c to be independent of the user's default shell.

While debugging this, I noticed the two following additional points:

• you don't list netstat as a required dependency: the command above semi-fails and selects port 4444 when netstat is not present
• you may want to start the command you're issuing with a space character to avoid filling shell's history (assumes bash and HISTCONTROL set to ignorespace but well...)

Hope that helps

VC++ on Windows continues build to end so that all sources are compiled, successfully or not.
Sometimes, when the error is in a header file and the same error occurs in multiple surce files this can generate rather a lot of error messages but then you're a superstar for fixing dozens of errors with a single correction 😉 .
Using incremental build ensures that, once the errors are fixed, only the failed sources need be compiled again which is usually quick.

But VCLinux stops at the first source with errors. So the edit/build cycle results in not only compilation of previously failed sources but all the ones that follow it in the project too. Which, on larger applications, can defeat the object of going to lunch while the solution builds. Although this is, to a large extent, contingent on issue #29 : header dependencies and incremental builds.

For consistency, VCLinux should do the same as VC++ on Windows. This is what is expected and desired. It is also the behaviour of make when the --keep-going option is specified.
Keep Calm and Carry On, as the popular slogan has it.

Visual Studio 2015 Pro Update 3
Windows 10 insider latest
VC_Linux 1.0.5
Mageia Linux 5 (x64)
gcc 4.9.2 / gdb 7.8.1 / gdbserver 7.8.1

An implementation detail we've been discussing added here for tracking.

Would this help people get going quicker with devices? There are some things it may help illustrate around parameters that need to be passed in.

For Windows, Visual C++ defaults to C++14. And there is no option to fallback to C++11. To be consistent, VC_Linux should also default to C++14. Users can always specify the -std=c++11 command line option if needed.

We should provide either natvis or python pretty printer support for formatting types during debugging. We could start with pretty printer support as I believe that would help with STL. Probably on by default but override to turn it off if it causes perf issues.

Sometime you just have to use a specific version of gcc. It'd be great to be able to override our default of gcc with something more specific if needed.

This would be nice.

There are two arguments for using make (GNU make) on the target Linux system for builing projects in VCLinux : performance and flexibility.

On Windows, the VC++ build process is a sequence of steps where each source file is compiled to an object file and then object files combined into an application (or library) by executing the appropriate CL command for each step under the control of MSBuild. This works well and the ability to run pre- and post-build commands allows for customisation.

VCLinux build processing closely follows that of native Windows applications. However, pre- and post-build commands are missing (1.0.4) and, because it's building on a remote target, the build proceeds slowly.

The VCLinux build steps (1.0.4) are:

1. validate ssh communication with, and architecture of, Linux system
2. copy all project source files to be compiled via ssh to Linux
3. execute g++ command to compile each source file in turn
4. copy object file from each successful compilation back to Windows
5. link objects into executable (or static or shared library)
6. copy executable back to Windows

Personally, I'm quite happy with this process in principle. My applications consists exclusively of C++ source that is built into one or more static libraries, shared libraries and executables. But using make seems to offer opportunities to offload some work, both development and execution, to an existing tool.

Performance
Because everything has to be done at arms length on a remote Linux system, building is much slower than on Windows; steps are executed sequentially and copying takes time.

It does seem that using make on the Linux target and building as a batch process would offer performance improvements:

1. single command via ssh for build
2. parallel compilation capabilities in make (--jobs option)

An additional perfomance improvement might be to not copy object files back to Windows. The executable is required for debugging with gdb and must be copied. Object files are only to satisfy MSBuild and a locally generated zero-length file with the appropriate name and time stamp would suffice.

Flexibility
In addition, basing VCLinux build on make would allow users to supply their own makefiles. This would give complete control over the process and work-around issues such as pre- and post-build steps, non-g++ compilation, cross-compilation, etc. There are simply too many variations for VCLinux to cover all the options.

So how would it work?
I don't want to have to write a makefile for my projects and would want VCLinux to generate one from the project settings. This is what Eclipse CDT does. Eclipse will create / recreate a makefile on demand from the project settings and contents. Thereafter, Eclipse builds the project using this makefile as it would with a user-supplied one. It's rather clumsy in that the user must regenerate the makefile following any changes to the project, including the addition of new source files.
I'd like to see VCLinux automatically generate its makefile on every build; creating the makefile is quick and build-specific makefiles can be simpler and need only reference the source files affected. It does not need to be a makefile that can be used outside VCLinux.

At the same time it should be possible to give VCLinux the makefile to use. It would have to be part of the Visual Studio project and 'live' on the Windows host. But it would be opaque to VCLinux, i.e. I'm not suggesting it should be parsed by VCLinux. Rules would need to be established for the build targets, e.g. make debug, make clean and what and where the generated executable (or library) wiil be; it being the users responsibility to ensure that everything corresponds (with great power comes great responsibility, eh?).

After compiling each source file, Visual Studio copies the object files (*.o) back to the local computer, which slows down the build for projects with multiple source files. An option could be provided to disable this, or the copying and building could be carried out in parallel to speed up compiling process.

• A brief description
  We need to support only copying files over that have changed.
• Expected results
  Only new/changed files are synced to Linux machine.

The MIEngine supports this, we just need to add a flag in the project properties that enables it if needed.

Currently, the include files need to be manually copied from the Linux system. It would be nuce to have a feature which automatically copies the headers and adds them to VC++ directories, while syncing any changes made on the remote system.

See UPDATE at the end of the post.

Hi,
I have a project hierarchy similar to the following:
SolutionFolder
---Project.Shared (contains files shared by multiple projects/platforms)
fileShared.cpp
---Project.Pi (used to compile on Raspberry Pi)
filePi.cpp
---Project.Win (used to compile on windows)
fileWin.cpp

On the target (RPi), I expect the following:
/Project.PI/filePi.cpp
/Project.PI/fileShared.cpp

but I get instead:
/Project.PI/Project.PI/filePi.cpp
/Project.PI/fileShared.cpp
ERRATUM: should be: /Project.PI/Project.Shared/fileShared.cpp

UPDATE [12 SEPT 2016]
The extension seems to copy the files differently according to if some source files are present in Project.PI.

If there are no source files in Project.PI but only settings then I get:
/Project.PI/fileShared.cpp

After adding filePi.cpp to Project.Pi I got:
/Project.PI/Project.PI/filePi.cpp
/Project.PI/**Project.Shared/**fileShared.cpp

The path of the files from Project.Shared is now changed on the target. This may be the intended behavior.

Environment: VS2015, Raspbian (RPi3, ARM), extention version: 1.0.5

We need to fix this so people get notified of new drops.

More complex solutions need support to reference other projects.

Please use the following bug reporting template to help produce actionable and reproducible issues:

• A brief description
• Expected results
• Actual results (with build output window contents if applicable)
• VC++ version, Linux system name and version, GCC/GDB/gdbserver version, CPU arch, etc. If you are using a specific version of Linux on an embedded board, we might need to know about it to get a repro on similar hardware
• Steps required to reproduce the error
• Required packages and commands to install

See our contributing instructions for assistance.

Probably this is not a bug but a simple configuration error, if so I apologize (I am new to compile under Linux).
Anyway, I am trying to link statically the boost library to my Console project (Linux) . The project builds but fails to link (and the error is not clear to me):

1>------ Rebuild All started: Project: TestApp2, Configuration: Debug x64 ------
1> Cleaning remote project directory
1> Validating architecture
1> Validating sources
1> Copying sources remotely
1> Starting remote build
1> Compiling sources:
1> main.cpp
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Application Type\Linux\1.0\Linux.Common.targets(245,5): warning : GMP header version 5.1.1 differs from library version 6.0.0.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Application Type\Linux\1.0\Linux.Common.targets(245,5): warning : GMP header version 5.1.1 differs from library version 6.0.0.
1> Linking objects
1>collect2 : error : ld returned 1 exit status

Here is my scenario:
Microsoft Visual Studio Professional 2015 Version 14.0.25421.01 Update 3 Visual C++ for Linux Development 1.0.5
connet to virtual machine running CentOS:
Linux 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

I tested a simple Console Application for Linux and everything was fine. Then I tried to link statically to boost. I installed with command: yum instal boost-devel
This installed boost version 1.53: I can see the headers files in /usr/include/ and the lib in /usr/lib64/

Therefore I added a simple include (#include <boost/filesystem.hpp>) in my console application.
I added the configuration settings:

C/C++ -> General -> Additional Include DIrectories =/usr/include/
Linker -> General -> Additional Library Directories=/usr/lib64/
Linker -> Input -> Library Dependencies=boost

not really sure about the last setting...

(I checked that the file filesystem.hpp exists and I see:
libboost_filesystem-mt.so
libboost_filesystem-mt.so.1.53.0
libboost_filesystem.so
libboost_filesystem.so.1.53.0
in the /usr/lib64 directory)

Probably there is more to do or the warnings I see are important. I hope someone can point me in the right direction.

Thanks a lot.
cr

Often requested, we should do this.

Source dependencies on header files are not correctly applied to incremental build. This takes two forms:

1. Header file changed is in current project - a full recompilation of the project is forced i.e. only the changed header file is copied (good) to the remote Linux system however every source file is then compiled whether there is a dependency on the changed header file or not.
   In a typical scenario we will declare a class in a header file and include it in two source files, one to implement the class, the other to use it. Only these three files are affected by a change in the header and the desired action would be:
   . copy changed header
   . compile the two source files only (which is what VC++ on Windows and make do)
2. Header file changed is not part of current project - dependency is not detected and build reports project up to date. The header file in question is on both host and remote systems, with the same (newer) date stamp, and in the include path for the remote and IntelliSense path for the host. It just so happens that the include path for the header file I'm interested in at this time is the same relative path on both host and remote but this will not always be the case.

I note that dependency (.d) files are generated by g++ on the remote but not copied back to the host. All dependencies are correctly identified but in terms of the remote file paths which will make exploiting them difficult. It's possible that leveraging make on the remote might be the best strategy for handling dependencies, particularly when header is external to the project.

Visual Studio 2015 Pro Update 3
Windows 10 insider latest
VC_Linux 1.0.5
Mageia Linux 5 (x64)
gcc 4.9.2 / gdb 7.8.1 / gdbserver 7.8.1

include

int main(void) {
std::cout << "HelloWorld" << std::endl;
printf("HelloWorld");
return 0;
}

when i run remote gdb debugger i got this

=thread-group-added,id="i1"
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Loaded 'shared libraries loaded at this time.'
Stopped due to shared library event:
Inferior loaded /usr/lib64/libstdc++.so.6
/lib64/libm.so.6
/lib64/libgcc_s.so.1
/lib64/libc.so.6
/lib64/ld-linux-x86-64.so.2
Loaded '/usr/lib64/libstdc++.so.6'
Loaded '/lib64/libm.so.6'
Loaded '/lib64/libgcc_s.so.1'
Loaded '/lib64/libc.so.6'
Loaded '/lib64/ld-linux-x86-64.so.2'
[Inferior 1 (process 44287) exited normally]
程序“”已退出，返回值为 0 (0x0)。

Once we allow override of compiler used we know people will try clang. Options specific to this one need to be provided if used.

Whole new toolset?

Please use the following bug reporting template to help produce actionable and reproducible issues:

• A brief description
  While linking an error is thrown, however it is obscure: "g++ exited with code 1, please see the Output Window - Build output for more details."
• Expected results
  Error that has occurred being displayed.
• Actual results (with build output window contents if applicable)
  1> Linking objects
  1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Application Type\Linux\1.0\Linux.Common.targets(183,5): error : g++ exited with code 1, please see the Output Window - Build output for more details.
  ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
• VC++ version, Linux system name and version, GCC/GDB/gdbserver version, CPU arch, etc. If you are using a specific version of Linux on an embedded board, we might need to know about it to get a repro on similar hardware
  Visual Studio Community 2015 version 14.0.25421.03 Update 3
  Redhat Enterprise Linux 7.2
  gcc = 4.8.5 20150623 (Redhat 4.8.5-4)
  gdb = 7.6.1-80.el7
  gdbserver = 7.6.1-80.el7
• Steps required to reproduce the error
  Build my project.
• Required packages and commands to install

See our contributing instructions for assistance.

if the Remote Root Directory is using a mounted directory, we always get the following error:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Application Type\Linux\1.0\Linux.Common.targets(43,5): error : The remote project directory '/xxxMountedDrive/home/xxx/tmp/test_linux' is set to a system directory. This can cause harmful behavior and is not allowed.

Flexibility
Add an option to disable this check

Build project should compile only those source files that are not up to date, i.e. have been changed or did not compile in last build.
Instead, Build causes all source files to be copied to Linux target and recompiled, i.e. it does a Rebuild.

Known issue added here to track progress.

Visual Studio 2015 Pro Update 3
Windows 10 insider latest
VC_Linux 1.0.4
Mageia Linux 5 (x64)
gcc 4.9.2 / gdb 7.8.1 / gdbserver 7.8.1

When a single C++ source file is compiled (via Build/Compile Ctrl+F7) the compilation
uses the C language options from the project settings in addition to the C++ language options.
C++ source file has extension .cpp.
When the same file is compiled as partion of Build project, only the C++ language options are used - as expected.

This appears to be something that changed after Visual Studio Update 3.

Visual Studio 2015 Pro Update 3
Windows 10 insider latest
VC_Linux 1.0.4
Mageia Linux 5 (x64)
gcc 4.9.2 / gdb 7.8.1 / gdbserver 7.8.1

log from Build/Compile Ctrl+F7

g++ -c /***/***/***/vcl01/main.cpp -g2 -gdwarf-2 -o "/***/***/***/vcl01/obj/x64/Debug/main.o" -Wall -O0 -fno-strict-aliasing -fno-omit-frame-pointer -fno-threadsafe-statics -fno-exceptions -fno-rtti -std=c11 -std=c++14 -Wextra

     main.cpp
     cc1plus: warning: command line option '-std=c11' is valid for C/ObjC but not for C++

log from Build/Build Solution

g++ -c -x c++ /***/***/***/vcl01/main.cpp -g2 -gdwarf-2 -o "/***/***/***/vcl01/obj/x64/Debug/main.o" -Wall -O0 -fno-strict-aliasing -fno-omit-frame-pointer -fno-threadsafe-statics -fno-exceptions -fno-rtti -std=c++14 -Wextra

It would be awesome if we could just trigger make on the remote machine instead of specifying all the options for compilation via property pages, especially for existing projects.

Adding "../" produces a weird "-I" directive:

Instead of the expected value "/home/rudolfs/projects/include_path_test/../" it produces "/home/rudolfs/projects/include_path_test/../../include_path_test".

While for example using "../test/" works as expected and produces "/home/rudolfs/projects/include_path_test/../test"

• A brief description

Please add support for using the Windows Subsystem for Linux as a "remote" machine.

• Expected results

Using the local instance of Ubuntu, copying source files could be eliminated alltogether, greatly reducing incremental build times while also reducing the complexity of the back-end.

We use the add-in for compiler conformance testing and benchmarking, and for benchmarking it would be great if the very same machine could run the same codes with minimal virtualization overhead for the GCC part (which WSL does not incur). One solution with multiple projects, all referencing the same source file.

SolutionDir/XCompiler.sln
SolutionDir/inc/header.hpp
SolutionDir/src/main.cpp
SolutionDir/VisualC++/VisualC++.vcxproj
SolutionDir/Clang/Clang.vcxproj
SolutionFir/GCC/GCC.vcxproj

I expect to press F7 and see the build output from all compilers. Having a custom script target that invokes each of them, one after the other to benchmark them is the cherry on top (but has nothing to do with the add-in).

• Actual results (with build output window contents if applicable)
• VC++ version, Linux system name and version, GCC/GDB/gdbserver version, CPU arch, etc. If you are using a specific version of Linux on an embedded board, we might need to know about it to get a repro on similar hardware
• Steps required to reproduce the error
• Required packages and commands to install

It were nice if the the WSL build would happen either via calling the compiler from the host MSBuild process or if remotely it would invoke a .Net Core targeted MSBuild instance.

I am developing a C lang DLL for Windows and a SO for Linux
using the same code. In one solution I have 4 projects 1-Linux SO, 2-Linux OUT, 3-Win DLL, 4- Win EXE. The Linux projects and Windows projects "share" the same source files with some #ifdefs (WIN32 vs Linux). "h" files and "c" files are in common folders. I've set the configuration manager to build either Linux or Win32. The debugger is displaying wrong source code at times. If I step into a func that is in the Linux SO, the source code displayed is the Win32 source (meaning the ifdefs think that it is WIN32 and not linux). If I first set a break in the Linux version of the file, then it will display correctly. However, there seems to be no rhyme or reason for which project it chooses from at times. If I have the Linux project set as "Startup project", shouldn't VS know which project to pull source code from? With Linux, it appears that you cant set a reference to a SO from the main app as you can with WIN32, so that may be a factor. If you try to set a reference the path is bad.
VC_Linux 1.0.5

We currently have Intelisense support for the STL by default. To add support for your own environment you need to setup the VC++ Directories to point to your include files, we cover on way to do that here.

We could make this more discoverable by doing something like what is done in VS Code for C++, when there are squiggles prompt an action bulb that offers help in setting this up.

Another option would be to add the capability to sync all of the include files locally from common locations for each Linux connection we have.

Of course things may not be in a common location so perhaps a bit of both?

We get fairly regular reports that can be traced to missing prereqs on the Linux machine. Since we know what they are we should check for them and inform people if anything is missing.

As the tile says. The workaround today is logon as root which obviously isn't idea.

As it says. It would be a convenience mechanism since you could do it directly on the Linux machine, but it would be handy.

As it says

Please use the following bug reporting template to help produce actionable and reproducible issues:

• A brief description
• Expected results
• Actual results (with build output window contents if applicable)
• VC++ version, Linux system name and version, GCC/GDB/gdbserver version, CPU arch, etc. If you are using a specific version of Linux on an embedded board, we might need to know about it to get a repro on similar hardware
• Steps required to reproduce the error
• Required packages and commands to install

See our contributing instructions for assistance.

Please use the following bug reporting template to help produce actionable and reproducible issues:

• A brief description
  Compiled binaries like .o or .out files are downloading very slowly from a remote server.
• Expected results
  Compiled files should download with close to full bandwidth.
• Actual results (with build output window contents if applicable)
  Download bandwidth of MSBuild.exe is hovering at about 50KB/s
• System info
  Server is a x64 Debian Jessie up-to-date hosted at OVH. My ping to it is about 60ms and bandwidth over sftp/ftp/http is my full home bandwidth (2.7 MB/s down).
• Steps required to reproduce the error
  Compile on a real remote server.
• Additional info

When compiling on my raspberry pi which is connected via 100mbit LAN i get over 400KB/s for compiled binaries but the raspberry build still isnt a good alternative for one because its a different arch but its also slow.
And i dont really understand why every .o file has to be downloaded as it seems its not needed anyway on clientside. In my case i also dont need the final executable on my machine.
In my debug build my .o files are 27MB and my final executable is 12MB. Which takes a ton of time to download.
Here is an example of a compile where i only changed two chars in one source file.

Hi,
The following was working flawlessly on 1.0.4 but was broken on 1.0.5.

I have a project hierarchy similar to the following:
SolutionFolder
---Project.Shared (contains files shared by multiple projects/platforms)
fileShared.cpp
---Project.Pi (used to compile on Raspberry Pi)
filePi.cpp
---Project.Win (used to compile on windows)
fileWin.cpp

The compilation fails with the following for each file:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Application Type\Linux\1.0\Linux.Common.targets(245,5): error : /home/pi/projects/Project.Pi/../Project.Shared/fileShared.cpp: No such file or directory

Of course this fails as the file was copied to /home/pi/projects/Project.Pi as it should.

Environment: VS2015, Raspbian (RPi3, ARM)