I am using visual studio 2015 on windows to develop a c++ application for a linux machine using the linux project template. So far I have built the libraries I need on the remote machine, then transferred those libraries to my windows machine.
From there I have included them in my project as normal (in the project properties), but there are still some errors when I am building the project, as far as I can tell they are link errors. I am fairly certain I have included all the necessary files and linked everything correctly within the IDE.
This is purely for fun and a learning experience for me, so please forgive me if I am way off base here. I have read about makefiles but am still new to linux development and was just wondering if anyone has any experience with this.
If this cant be done remotely from within the visual studio IDE I would love to hear suggestions.
EDIT: It seems I was mistaken about what it was exactly that I am trying to do, sorry guys.
You cannot link libraries on Windows with MSVC compiler that you compiled on your remote Linux machine with a different compiler. You will need to recompile them.
Related
If I'm in my WSL2 Ubuntu filesystem I can simply navigate to a javascript/nodejs folder and type code . to open that project folder and thanks to VS Code's Remote extensions, I'm essentially remoting into the Linux environment and ready to code.
Now Visual Studio 2022 has been released, I was wondering if it too supports the same level of cross-platform IDE capability as VS Code?
How, for instance, when in my WSL2 Ubuntu project in Windows Terminal, can I open my javascript/nodejs project in the Linux filesystem using VS2022, or is this not supported because VS Code is the only cross-platform IDE that can do this?
So its not really possible to do how your thinking. The problem here is that you your not understanding the difference between a "Code Editor", and an "Integrated Development Environment (IDE)", which is totally understandable, as the line that separates the two has become blurred in recent years, and also a topic of debate. There was a far more explicit distinction between the 2 10-15 years ago, however, Microsoft has done a good job at separating the two, where JetBrains will release a piece of software that can be used as an IDE, but is more often than not, used as an editor, but will still call it an IDE, even though its not an IDE in a pure sense.
How is all this related to your question?
When you open your Node.js project in VSCode via the code . command, you are opening it in an editor that implements Intelli-code, as well as a wealth of other tools, but essentially, the editor, and all the tools extract the names & file extensions of your documents, parse them (usually turning much of the info into an AST, where many extensions will make use of that info to offer the various tooling capabilities/features. The point is at the end of the day, the editor just parses all of your code, gives you info, and you make any changes as needed to your code. And again, this is what your doing with code .
With Visual Studio 2022, you can't open a project with it, unless its a project type the IDE supports, and enables the IDE, to embed its-self into your project. This includes things like built in environment, built in cache, built in build system, the files needed to bootstrap its-self. With an IDE, the IDE is part of the project.
So then why does Visual Stdio 2022 work with Node?
It works with node, to create Node.js applications within a windows environment, and it offers the ability to access different Windows SDK features via Node. These are things you could never do using server-side Linux builds with Node. When you build a Cpp application for windows, you package the entire thing in a .sin file, I haven't built a windows app in node, but I know that Node also uses the .sin file build system, which requires Visual Studio & Windows SDK to do, and parts of Visual Studio/Windows to be embedded into the project, for the project to be able to work in a Windows OS, and take advantage of MS Windows features.
Long story short, V.S. Code is the right tool for what your doing, why would Microsoft invest in two identical tools any way? If you ever want to build something for Windows, or for MS mobile device using Node, you will probably want to change your environment, to VS2022.
I am trying to build a few different 32-bit C++ applications with Visual Studio 2015 that use CEF. To use CEF, I am currently acquiring the CEF prebuilts from Spotify. The dll wrapper for CEF is built using Visual Studio 2015 with some modifications to its CMake files to force it to build with MD and MDd mode regardless of other settings. This was sufficient to make these C++ applications run on some machines. Any machine on which Visual Studio 2015 is installed on before anything else they can run on, however some machines seem to exist in a state such that the program will produce an error on starting when lacking the MSVC 2015 runtime (as expected), but when adding the MSVC 2015 runtime the program simply crashes; however, it only crashes after CEF is used. These programs work fine when they don't link to libcef.dll and don't include the browser functionality.
Upon investigating, I found that libcef.dll, as built by spotify, links to MSVCP110_WIN.DLL, which is from the Visual C++ 2012 Redistributable package. Naturally, the application I am building links to MSVCP140.DLL, which is from the Visual C++ 2015 Redistributable package. This means that the application ultimately links to two runtimes simultaneously. I do not know if this is an issue, but so far it seems to be my best lead. Installing the Visual C++ 2012 Redistributable does not change the outcome and it continues to crash when CEF is used.
This issue has been witnessed on both Windows 7 and Windows 10 and the application works without CEF on both of those operating systems as well, so the operating system is not likely to be the cause of the failure on these systems specifically.
Has anyone else encountered this issue and does anyone know a workaround? Also, does anybody know if it is okay to mix these two runtimes and what the limitations are? It seems that the installation history of a given machine affects the success of running the application, so any hints into what combination of things leads to this failure would be helpful as well.
You have some options:
Use the lastest version of VS that will allow a selection of Platform Toolset that matches libdef.dll. For example, VS2013 might allow the selection of the 2012 CRT.
Or convince Spotify to rebuild libcef.dll such that it matches your version of CRT
Or convince Spotify to not release libraries that depend on the CRT (yes that's probably a bit of work).
Or make a small app built against the older CRT, this app can then successfully use libcef.dll. Then you get to use any IPC technique so that your main VS2015 app can talk to this wrapper. Running out-of-process is one way to segregate the unruly third party libraries.
EDIT:
This is open source? Well good news, you can fix this yourself, built the CEF against your favorite version of VS.
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
I like the Linux operating system and vim editor, but there are many companies that develop under Windows environment in Visual studio etc. There is a possibility that I will have to work for such a company in about a month.
I'd like to do my work on my Linux system and copy the files to them. I have experience with both developments and I found out that I don't want to work with MS products but I like programming and writing MS code is not such a pain.
Are you a similar developer? Could you give me some advice about your methodology to be most of the time on Linux platform, to create code and debug everything in vim on Linux and only when neccessary open Visual Studio with Windows forms and similar things and test the things that weren't possible to test in Linux environment?
I would see the work in creating small peaces of code on Linux, testing them and then move it to MS platform and integrate to the whole system. How do you debug and test your code? The development will be probably in C# or C++. I can't imagine Visual Basic.
Please write here your experience, style of work, if this has sence or there are too many troubles and I should rather give up.
So the question is: How to develop applications that run on Windows with Linux tools, without touching Visual Studio and browsing with Windows file manager etc.
thank you
Not sure, if this will help you or not but there is a Vim Emulation layer for Visual Studio 2010 called VsVim.
Check out : http://visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-46ca-8fe1-0e90e3f79329
If I were you I'd install MinGW or Cygwin on your windows machine and just use gvim/vim anyway (or maybe just use the Win32 vim).
VS is just a big editor. You'll be building with the microsoft compilers ( perhaps using msbuild or nmake ) but probably are going to have to accept that you can only debug windows things with VS ( unless you build for MinGW or Cygwin and use gcc and gdb)
You can use vim as a code editor, you can even stick on Linux when developing software for the .NET platform. The people behind the Mono make this happen. Mono is a software platform designed to allow developers to easily create cross platform applications. It is an open source implementation of Microsoft's .Net Framework based on the ECMA standards for C# and the Common Language Runtime.
You can stick to the editor of your liking and use the tools that come with Mono to compile your stuff. There is a IDE called Mono Develop, but compared to Visual Studio it is pretty basic... and compared to VIM it lacks simplicity.
C# projects are plain text files so it's easy enough to edit them over an SMB share in whatever editor you wish from anywhere the sysadmins let you.
Testing however will be difficult without going back to the windows machine, and while Mono implements the framework, it's still a different environment if you're targeting Windows.
Newbie here. I made a project in visual studio 2010, and it works perfectly. Now i need to compile and run this code in a machine that runs ubuntu. Is there some export/import method, or how does it work (of course assuming such thing is possible).
What i am thinking is making a makefile in visual studio, then take the code and compile it in ubuntu? does such thing make sense?
Thank you in advance.
In an ideal world, the code is independent of any IDE or build chain, which keeps its own metadata saparate. Windows doesn't play nice with Linux.
On the other hand if you set up your project with CMake or something like that, then you can generate Visual Studio projects for a given code base just as easily as Linux makefiles.
You shouldn't need to change much code itself. Or, at least you should be aware of what is windows-specific. You probably will have to expend some effort in creating your CMakeList.txt or whatever you end up using, but it's pretty easy once you're familiar with it.
If you mean take Visual Studio source code and compile it on Linux: the answer is yes, though there may be anywhere from zero to a lot of work to make the code compile properly and run. It all depends on programming choices. Unfortunately, standard practice with Visual Studio generally is to use the most Microsoft-specific API features, thus greatly complicating porting to a POSIX or Linux environment. It is possible to make most non-GUI choices very portable, however a GUI intensive program is the least portable unless a cross-platform GUI API is used.
If you mean take the resulting .exe file output from Visual Studio and run that on Linux, that is usually much easier. Install the Wine package, (yum install wine or whatever the Ubuntu equivalent is) and fire up the program with wine program.exe. I have had very good luck (98+%) running Windows programs this way. The major exceptions are Microsoft software: in particular Visual Studio uses many non-standard Windows API operations, so much so that the Wine developers call VS's support level "garbage", a surprising outlier considering the number of Windows games which are well behaved and run under Wine straight out of the box.