I've got Visual Studio 2017 (Linux and IOT extension installed) and a linux makefile project. The code is compiled using an arm cross-compiler.
When I try to debug, visual studio will always choose one of the gdb.exe in Common7/IDE/VC/Linux/bin/gdb/8.1. The decision is made based on the choosen architecture (x86, x64, ARM, ARM64) of the VS project.
However my cross-compiler and the gdbserver running on my device are not compatible with the provided aarch64-linux-gnu-gdb.exe.
Is there a way to tell VS to use a specific gdb.exe on my pc?
Replacing files within the VS installation is not an option.
Within Common7/IDE/VC/VCTargets/Application Type/Linux/1.0/Linux.props I've found the GDBRoot property pointing towards the first directoy, but I failed to override this property.
I prefer to keep a solution instead of a project with thelaunch.vs.json if possible.
Related
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.
My Visual Studio 2012 solution has C# projects, VB.NET projects, C++/CLI projects and C++ projects. Currently, I have three platforms: x86, x64 and Win32. When I added x64, I noticed it was used by all projects. I'd like to do the same with x86, so that I can remove Win32.
So I went to Configuration Manager, selected a C++ project and in the platform combo box I only had the options: Win32, x64, New and Edit. If I selected New, the only option available is ARM.
So then I thought of just replacing Win32 with x86 in my .vcxproj. Didn't work (it defaulted to x64). Then I looked at the .sln file, but couldn't see how x64 manages to work for every project.
The IDEs differ too much to get a common platform name for 32-bit code. Otherwise reflective of managed code being rather fundamentally different from C++ code. Managed project platform names can only be AnyCPU, x86, x64. C++ project platform names can only be Win32, x64 and ARM. History plays a role, Win32 comes from the early 1990s, back when Windows NT introduced the 32-bit version of the winapi. Distinguished from the 16-bit version. There was no real opportunity to ever change it again without risking breaking existing projects.
The x86 platform name for managed projects isn't exactly standard either, that was a mistake in VS2010 that you appear to have inherited. VS2012 creates new projects with the AnyCPU platform name like old VS versions used to do. Which pretty accurately describes the true platform for managed code, it runs on any thanks to the jitter. The name is otherwise irrelevant, only the Project + Properties, Build tab settings matter to force a specific jitter to be used at runtime. In other words, if you don't force x86 there then your program is still going to run as a 64-bit process, even though the platform name is x86. That was the VS2010 mistake, it caused a lot of misery.
So you're pretty stuck with this. It is not a real problem, the IDE can handle the mix just fine. You already know about the Build + Configuration Manager dialog, it unambiguously shows which platforms are going to be built when you use Build + Build or press F5.
I built a C++ based COM object using Visual Studio 2012. It registers and works fine on 64-bit machines (called by 32-bit code and calling a 32-bit out-of-process COM server) but does not register on 32-bit machines (neither XP nor Win7 32-bit). The message from regsvr32 is
LoadLibrary("comobj.dll") failed - The specified procedure could not be found.
The project was originally built with Visual Studio 6 (7 years ago). It uses ATL macros such as BEGIN_COM_MAP and BEGIN_SINK_MAP to declare its implementation of various interfaces. It had to be re-compiled because the COM server it was invoking changed (new ProgID, new GUID, new type library, etc). Other than making those adjustments, and using current VS, there were no (intentional) changes -- there certainly was nothing in the old equivalent of the project file that would have pointed to 64-bitness.
Examining the DLL with the 64-bit version of DEPENDS.EXE shows "64" icons next to the standard referenced DLLs like KERNEL32 and USER32. Other than having built the DLL on a 64-bit machine, there is nothing "64-bit" about the DLL that I can find. The target is explicitly Win32 (not X64).
Examining the DLL with the 32-bit version of DEPENDS.EXE (on Windows XP running under Virtual PC) shows KERNEL32.DLL with a red icon, apparently because there are references to FlsAlloc FlsFree FlsGetValue FlsSetValue that do not exist in the 32-bit KERNEL32.DLL. (I have no idea what those are and don't know where those references come from -- perhaps from the copy of MFC on the 64-bit machine where the compile was done?)
Could it be that I have to install VS2012 on XP and re-compile there? How could that really be what needs to be done to build a Win32 COM object in C++ using current Visual Studio?
Does anyone know where I might look? I've checked all the project and solution options and nothing seems set to 64-bit. The option under "Use of MFC" is set to "Use Standard Windows Libraries" -- that's probably the answer but if that's not portable to 32-bit Windows it's hardly using only "standard libraries". (I will be trying changes to that after sending this.)
Thanks in advance for any advice.
Default toolset coming with Visual Studio 2012 produces output incompatible with Windows XP, through using certain APIs introduced only later with Vista.
In order to both utilize the power and feature richness of the latest Microsoft C++ compiler, and be still compatible with Windows XP, you need to use an alternate toolset codename "v110_xp" introduced with Visual Studio 2012 Update 1. At the moment the latest update available is Visual Studio Update 3, and you might want to simply install latest available updates for Visual Studio.
You have the setting available under Project Settings:
See more here: Configuring C++ 11 Programs for Windows XP.
I have a Visual C++ library which I want to compile for a certain platform (I try to compile POCO for a Win CE ARM platform, but that might not be relevant to this question). I got a vendor-specific Windows CE SDK (including all common Windows include files e.g. winbase.h) which is set as target platform within the Visual Studio project files. However, when I compile the program, I can see from the error log that the default Windows 6.0A SDK is used, resulting in a bunch of compilation errors.
I guess the WindowsSdkDir ist not set accordingly - I thought this would be automatically overriden when setting the target platform within Visual Studio.
So my question is: can I modify the WindowsSdkDir for a single project explicitly?
Thank you in advance
Which CE version, which VS version and on which Windows version? I know that I had problems installing CE5 and/or CE6 SDKs and getting them recognized by Visual Studio 2005 running on Windows 7 (64 bit). I don't remember the exact symptoms and fix, but you can test that by simply creating a smart device project for the target SDK.
If that is not the issue, there is also the pitfall with the target in both the project file (.vcproj) and the solution (.sln). You can change both independently from each other, up to the point where you compile the x64 debug version of a project in the win32 release version of the solution. Verify that these setting match.
Then, if you adjusted the .vcproj file to use your target platform (for which I personally would use a text editor), things should work. If you need to adjust the build or some paths, you can sometimes get by with e.g $(Platform) in the compiler/linker settings.
Lastly, if all that doesn't work, there are property sheets, which can adjust certain settings. You then create a property sheet once and then load it into the project that you want to compile. I'm not sure if you can change the target platform or the SDK paths with that approach though, and I'd rather try to find out why the SDK doesn't work and how to fix it instead.
I am writing an installer using wix. I have also written custom actions. But while installing the MSI the installation fails because the target system does not have MSVCR100D.dll
I am linking using /MTd option which is what the docs I read suggested for static linking.
Can anyone please let me know how to link msvcr100d.dll statically so that even if msvcr100d.dll is not present on the target system, my MSI installation succeeds?
The "D" in MSVCR100D.dll indicates that your native custom action DLL is a debug DLL. The "D" dependency won't be on the target machine unless they have various SDKs installed. Rebuild your DLL in release and the dependency will change to MSVCR100.dll
Also, since you are using WiX / Votive, there is a Visual Studio WiX C++ CA project type that creates the project for you. My experience has been that all of the default compiler and linker settings are good to go out of the box when you use that project type.
I have noticed the same problem. In my case, I am trying to debug my custom actions running in the context of the installer, so I do want to install debug versions.
The Visual Studio debug CRT DLL's are not redistributable, by Microsoft policy. Apparently, it seems furthermore that a 64-bit DLL compiled with Visual Studio 2010 using /MTd (static linking, debug configuration) produces output with a dependency on MSVCR100D.dll. In the 64-bit release configuration, as expected, compiling with /MT results in no dependency on MSVCR100.dll.
One solution is to install Visual Studio on the target test machine. Microsoft offers further suggestions here.