I have a visual studio 2019 project that requires a 64 bit build due to dependence on some nuget packages.
As you can see, I have changed the build targets to 64-bit but it doesn't seem to be able to move past the same complaint.
What am I missing here? Is this a bug in Visual Studio 2019 or am I doing something wrong?
Changed all built targets to 64 bit.
While you're looking at the specific build options for a Configuration called "All Configurations", where the Platform is set to "X64". But note your settings in your IDE's toolbar. You're currently targeting/building the "Debug" Configuration for "Any CPU".
To better understand what's going on here, right click on your Solution node in the Solution Explorer and select the "Configuration Manager..." menu item.
Given you require X64, you can/should remove the configurations that allow you to target x86 or ANY CPU. I suspect you are just building the wrong configuration here. That "All Configurations", is probably being brought along by one or more C++ projects in your solution.
Sincerely,
Related
I'm trying to compile a C++ project in VS 2017. Previously I used VS 2019 but due to it's annoying bugs I moved back to 2017, but now I get and error: unknown flag "-pdbrpc" in "p2". I don't even know what this flag means and I didn't find it in .vcxproj files.
I tried to change my project's config settings to disable optimization, but didn't succeed. Also I searched that error in google but didn't find anything useful. How can I fix this annoying problem?
Had same problem. Disabling Whole Program Optimization fixed it.
You probably forgot to downgrade some projects you depend upon.
Make sure all of your projects (including static libraries you link with) use the same v141 (VS2017) Platform Toolset. It can be visible in the Solution Explorer as Project Name (Visual Studio 2017).
In my case I had a hidden project.default.props that was using $(DefaultPlatformToolset), which started to point to v142 as soon as I installed VS2019.
I am using VS 2015 and I created a new “Unit Test App (Windows Universal)”.
If the Default Processor Architecture is set to x64 (under “Test -> Test Settings -> Default Processor Architecture”), the build works fine and the test is also discovered successfully and displayed by the Test Explorer
However, if I change the Default Processor Architecture to x86, the build still succeeds, but VS does not discover any tests.
Thoughts?
P.S. I have looked at some of the similar problems that have been asked here. If you think this is a duplicate, please confirm with me before flagging the question. thanks.
For the larger audience: It seems like there was something that I was missing while installing Visual Studio that resulted in this issue. I reinstalled VS from scratch, and everything works as expected.
I just hit this too.
For me the root cause was that the Build target must match the Test Settings Default Processor Architecture.
New Projects (even Universal Windows projects) always default to Any CPU.
If you are running on x64 machine then your Test Settings Default Processor Architecture has to be x64 too.
In my opinion Universal Windows projects should never have an "Any CPU" config.
Universal always has to build native now so stop the "Any CPU" option and make the user pick the target!
In one project's Properties | Build tab, only x86 is available for Platform. The x64 build option is missing. This is occurring in one project of a solution. The other projects are all still using x64. I tried creating an entirely new and separate solution/project and it is also only displays x86. Also, in the General section x64 is available and selected for Platform Target.
Can anyone explain why this is happening and how to fix it?
I had a solution with one project set to AnyCPU. Then I added a Console application as a second project, who's default Platform seems to be x86. Now it's ( - the Console application) being built as an x86 and I can't change it.
The "Solution Platform" always shows "AnyCPU". But when I show the Console application's properties -> build. It shows x86 without any way to change it. So how do I change it?
Go to Build -> Configuration Manager
Select for the overall solution the Active Platform = AnyCPU
Go to the Console Application line and Set the Platform to AnyCPU
If there isn't the voice create a new configuration
Check that the Console Application is flagged for compile.
Also look at this discussion about console applications default to x86
This is an unfortunate flaw in the VS user interface design. The solution's Platform name is not relevant for managed projects, it only means something for native C++ projects. Where "AnyCPU" doesn't mean anything since native code cannot run on any cpu. This got a wee bit better in VS2010 with a new default Platform name of "x86". Merely a wee.
The only setting that really counts is the Platform target setting for the EXE project. Project + Properties, Compile tab for a C# project. The class library project settings are not relevant either since it is the EXE that nails down the bitness of the process.
Best thing to do is just ignore it. You can make that more permanent with Tools + Customize and just drag the combobox off the toolbar so you don't have to look at it again.
First let me say that I can remote debug a release build on the remote computer. I set up my release build much like my debug build but I mostly had to make sure the Debug flag was not set. I've dealt with doing this for a while and finally decided to try and figure out why I had to go through this. I should also mention that my remote debugging experience is limited to this project and the C# program uses a C++/CLI (built with /clr) .DLL to mediate to some critical C++ libs. I don't need to debug the underlying C++ libs but I do need to debug the C++/CLI code. (One reason I mention this is I can't link libs in statically while using the /clr flag).
I recently discovered Dependency Walker so I used it to see what was going on. Turns out with the debug flag set, the linker links in MSVCR100D.DLL and MSVCP100D.DLL, when the flag isn't set it uses the files without the "D" suffix. Now normally I might just copy over my versions of those .DLLs to the remote machine but there's a problem. My dev laptop with VS2010 is a 64 bit machine and the target machine is 32 bit. That means the only versions of those DLLs I own are 64 bit. I have installed the remote debugging for VS2010 (I had this same problem under 2008) on the remote machine but it doesn't include the debug versions of these .DLLs either (I'm not sure why but I'm assuming this is by design). So my questions are:
As a registered owner of VS2010 is there a valid source for 32 bit versions of these .DLLs I can put on the remote machine?
Is there a simpler way for me to get Debug support? That is can I change some other setting that just tells VS to not use the debug version of those two DLLs? The advantage here is the DEBUG symbol would be set and any conditional code using it would work.
The debug versions of the CRT DLLs are all available with the standard Visual Studio installation, including the x86 versions even on 64-bit machines.
By default, they're located in the following path:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist
Under that folder, you'll find two additional folders (x64 and x86) that contain the debugging versions of these DLLs for the respective platforms.
But pay special attention to the name of the folder (Debug_NonRedist). That indicates that these debug DLLs are not redistributable. It's certainly OK for a developer who owns a license for VS to use them when testing his/her code on another machine, but they should not be distributed to client machines and used to run your application. (Sounds like from your question that you know this, but it's worth pointing out anyway for future Googlers.)
Alternatively, you can change which version of the CRT DLLs that a Visual Studio project links to for specific project configurations. That means that you can compile a "Debug" version of your application, but tell Visual Studio to link to the full redistributable versions of the CRT.
To do that:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Debug" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to either "Multi-threaded DLL (/MD)" or "Multi-threaded (/MT)".
Notice here that you're just telling Visual Studio not to use the "Debug" variants of each of these options. They still mean the same thing. The first will dynamically link to a DLL, the second will statically link the CRT into your application. Pick the one most appropriate for your case. (I often find it convenient to configure my "Debug" builds to statically link exactly for instances like this.)
This question is for an older version of Visual Studio, but in case anyone comes here for a newer version (as I did), there is built-in support to deploy the debug DLLs that you need in VS 2013 (perhaps earlier). This is an obvious setting, but it can be easy to miss if one is rushing through things (as I was). So maybe this will help somebody.
In the property pages, under Debugging, when Debugger to launch is set to Remote Windows Debugger, in the property list, there is an option called Deploy Visual C++ Debug Runtime Libraries. Simply set that to Yes.
Update -- as requested, this is to clarify which property pages I'm referring to, by way of how to access them: In Solution Explorer, right click the startup project (the one in bold), and click Properties on the context menu. The Property Pages window appears. In the panel on the left side, expand Configuration Properties, and then select Debugging, the second item under Configuration Properties.
Edit to the Update: I got here via notification, and did not see that I could have just said, "See Cody Gray's answer for a picture of the window," to meet the request for clarification. But, there's the how-to anyway in case anyone needs it.