microsoft / vslinux Goto Github PK
View Code? Open in Web Editor NEWVS extension for C++ Linux development
VS extension for C++ Linux development
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:
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.
Often requested, we should do this.
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.
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.
This would be nice.
Please add support for using the Windows Subsystem for Linux as a "remote" machine.
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).
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.
Sometimes a little Linux box just doesn't have the oomph to compile. There are cross compiler tools available, we should use them.
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.
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.
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
We need to fix this so people get notified of new drops.
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.
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)。
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:
netstat
as a required dependency: the command above semi-fails and selects port 4444
when netstat
is not presentbash
and HISTCONTROL
set to ignorespace
but well...)Hope that helps
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"
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
An implementation detail we've been discussing added here for tracking.
Please use the following bug reporting template to help produce actionable and reproducible issues:
See our contributing instructions for assistance.
As the tile says. The workaround today is logon as root which obviously isn't idea.
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
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.
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
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.
See our contributing instructions for assistance.
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."
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?
The MIEngine supports this, we just need to add a flag in the project properties that enables it if needed.
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
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:
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:
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?).
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.
As it says
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
Please use the following bug reporting template to help produce actionable and reproducible issues:
VS2015 enterprise Ubuntu servers
See our contributing instructions for assistance.
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 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.
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
Please use the following bug reporting template to help produce actionable and reproducible issues:
See our contributing instructions for assistance.
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.
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. ?
As it says. It would be a convenience mechanism since you could do it directly on the Linux machine, but it would be handy.
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
More complex solutions need support to reference other projects.
Please use the following bug reporting template to help produce actionable and reproducible issues:
See our contributing instructions for assistance.
Source dependencies on header files are not correctly applied to incremental build. This takes two forms:
make
do)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
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.
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
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.
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?
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
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++
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
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.