Where's _WIN64 defined in C++/CLI project compiled as x64? - c++-cli

It seems to be added automagically in every project I create and I compile for x64 but it doesn't even appear in the project's Configuration Properties/(C/C++)/Preprocessor when selecting the x64 configuration.

_WIN64 is automatically defined by Visual Studio. See the list of Predefined Macros.

Related

"Librarian" rather than "Linker" shown in VS2015 DLL project

I have a DLL project in Visual Studio 2015 with properties:
However on the left hand side, I see "Librarian" rather than "Linker" options. Also on build I get undefined symbols for all referenced libraries (the project references a few projects in the solutions which build as static lib).
To note:
I converted the project from a static lib to a DLL by changing the "Configuration Type" option.
I have applied, saved, closed, reopened
Linked projects are of same type (e.g. Debug/x64) for this solution configuration.
This could be a VS2015 bug?
Note perhaps similar question for previous version of Visual Studio
In Visual Studio 2012 what is the difference between Librarian and Linker?
(however the question doesn't specify that it's a DLL project)
The problem is that the DLL project had a property sheet which sets the project as a static library, and had a libraries section.
It seems setting your project settings to DLL cannot override this kind of property sheet.

Win32 Project (API): Compatibility with other version of Windows

I use API to make a programs. It runs pretty well on Windows 7 (with debug file .exe), but it doesn't when I run it on Windows XP. Are there any ways to solve this problem?
I suppose you are using Visual C++, according the the message you get.
Your project is set up (by default) to link the Microsoft C++ Runtime Librairy dynamically, so it saves up space in your final executable, but you need the dynamic linked libraries to be in your system or in your executable's folder.
To solve this in Visual C++, without any afford from who are executing the program in their machines, you can change how MSVC link their runtime library to your executable, that is, if you set it to be linked statically, all the dependencies will be linked inside your final .exe, with no need of additional .dlls.
To change this option, refer to /MD, /MT, /LD (Use Run-Time Library) - MSDN.
Or in short: Project Properties>Configuration Properties>C/C++>Code Generation>Runtime Library
If in debug mode, use /MTd, otherwise use /MT.

msvcp100.dll missing

I wrote a program in C++ using Visual Studio 2010
But when I run it on some computers with WinXP it says
"Cannot start because MSVCP100.dll wasn't found"
How do I prevent such dependencies on dlls that do not come with windows?
Thank you.
you cannot prevent this dependency, as it's the core runtime library of Visual C++. Instead, include the Visual C++ 2010 Redistributable package with your application (usually a separate link is enough since most people have it installed already)
However, if in fact your program cannot start because a dll with D at the end such as MSVCP100D.dll then you need to build your program in release mode, which by default switches the run time to a non-debug version. You need to be careful to nut out any other included static and dynamic libraries you're including in your project to make sure all debug or all release versions match for your builds.
If you are having trouble finding which sub-projects are referencing the debug versions, you can download and run depends.exe and browse through the exe file to see.
Sorry for the late respones, but yes you can prevent this dependency, just go to solution property of yopur project, go to C/C++ > Code Generator and in Runtime Library change it from MDd to MTd, will include statically the dependent libraries, and not in run time, like this avoid Run time errors while try to run the Dll.

Can't build UserControls under x64

I am trying to troubleshoot a VB.NET project that contains UserControls (actually, several of them that are displaying the same issues). I am trying to get them to build under x64, but it is impossible. In x86 or AnyCPU, the UserControl builds and shows up in the Toolbox, so I can add or modify it in the forms that require it. In x64, the controls disappear from the Toolbox, I get warnings during build (the current project builds though), I can't see any of the forms - I get errors (please see below) - and projects that require the project with the form as an import will not build.
When I was studying what these UserControls are so that I can maybe rebuild them from scratch, I downloaded code from a book - great learning tool, but I get the same errors:
Could not find type 'Chap15SampleCode.ListSelector'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built using settings for your current platform or Any CPU.
The variable 'ListSelector1' is either undeclared or was never assigned.
I also get warnings, not sure what to do about them:
Possible problem detected while building assembly 'Chap15SampleCode': Referenced assembly 'mscorlib.dll' targets a different processor
Possible problem detected while building assembly 'Chap15SampleCode': Referenced assembly 'System.Data.dll' targets a different processor
I checked and found System.Data as a Reference is in c:\Windows\Microsoft.NET\Framework... (if I change the target framework to 4.0 the Reference is in c:\ProgramFiles(x86)... that was what my projects had ... and I tried to change it because of the x86, I couldn't, I had a few others in ProgramFiles(x86) and I thought that may be the problem ?)
Reinstalled VS2010, reinstalled Windows - did the same before btw - but I do have a clean system so I can't blame it.
If I can get this simple project to work, I hope the real projects will be easy - Please help me figure out what this is about. Thank you.
You have changed the Platform target setting in the project to x64. This is not appropriate for any project that produces a DLL. The actual bitness of a process that uses your DLL is determined by the EXE that starts the process. Or the host in which your DLL runs, the case for Visual Studio which is a 32-bit process. There is nothing a DLL can do to force the bitness, it can only refuse to get loaded. Which is what you see happening.
Change the setting back to AnyCPU so that your UserControl will work correctly in any process, regardless of its bitness. Including the VS designer. Project + Properties, Build tab. For VB.NET it is located in the Compile tab, Advanced Compile Options button.

Creating 64 bit CLR C++ projects in VS2008

I am creating a wrapper around a native lib, which comes in both 32 & 64 bit flavors. I have a fairly complex C++/CLR project that includes a number of header files from the native libs. I got it to work fine on x32, but now I'm not sure how to provide an alternative x64 build.
Can someone outline the steps to create such project?
Various defines depend on _WIN32 / _WIN64, so must be multiple projects?
Both x32/x64 native libs have identical file names. Currently the lib ref is done with #pragma comment (lib, "xxxxxx.lib"). How should this be changed?
Lastly - VS2008 has only Win32 platform listed, not Win64 (I do have x64 VS2008 component installed).
Thanks!
Normally it is sufficient to select the drop down which says win32 (next to the Debug/Release one on the toolbar) and selected "Configuration Manager". Then open the "Active Solution Platform" drop down and select New. Choose x64 type (which if it doesn't exist then 64bit compilers are not installed) and copy solution from the orignal Win32 one. Now your project can be built selectively by changing the drop down on the toolbar.
Normally it works more or less as is but you might want to consider tweaking a few pre-processor defines if only for the intellisense.
As for libraries, for platform ones (supplied as part of VS/PSDK) then you dont need to change anything. For your libraries you are wrapping then change the Additional Library Directories in the project properties to point to the 64bit directory.
Visual studio doesn't always install the 64 bit options.
It can be fixed by running the VS installer, choosing add/remove features, and checking the x64 feature.