WinRT project, C++/CX. When my XAML files are compiled, the generated code files contain an
#include "pch.h"
line. I want my precompiler header to be called differently - stdafx.h, for legacy code reasons. Changing it in project properties affects C++ sources, but not the XAML compiler - it still emits the pch.h line. I could not find XAML compiler settings anywhere in the project properties.
How do I change the PCH name that XAML compiler assumes, please?
The name of the precompiled headers file is not configurable in the XAML compiler in Visual Studio 2012. It is assumed to be pch.h, which is the default name of the file in all of the project templates.
It might be possible to tweak the build targets files to disable use of precompiled headers for XAML-generated C++ source files; I'm not that familiar with the targets, so I cannot say for sure. Alternatively, you could disable usage of precompiled headers for your project, then enable usage per-file for all of the non-generated C++ source files in the project.
If this feature is important to you, please consider opening an issue on Microsoft Connect.
Related
I am using Visual Studio 2008 trying to create a .dll. The dll uses an external library (.lib). Compiling and linking works fine (I included the paths to header/lib in the options). When my .dll is used by a program (as a plugin) it says "externalLibrary.dll missing" but there is no externalLibrary.dll, just a externalLibrary.lib.
Are there different options of linking (so the externalLibrary is already in my .dll)? Or can i simply create a .dll from the .lib? Or any other solutions to this problem?
Edit (to be more concrete):
In project properties i added
the header path # C/C++ - General - Additional Include Directories
the library path # Linker - General - Additional Library Directories
the library name # Linker - Input - Additional Dependencies (although
this doesn't change anything)
The .lib file you are using is an import library which basically means that it contains only stubs for functions/classes/... but not the actual implmentation. That implementation is in the dll. An import library is only useful for the linker as it uses it to resolve symbols. But at runtime, the actual compiled code is needed so your application/dll looks for the dll. But even if your dll is used as a plugin, it's no problem for it to depend on other dlls. So if you have the other dll I suggest you go that way. (what is 'externalLibrary' btw?, it's not normal a vendor supplies you only with an import library and not the dll)
If you really do not want to use the external dll, you'll have to find the static library for the code of 'externalLibrary'. Unlike the import library, a static library does contain all symbols complete with actual implementation etc. So after linking with a static library, your application/dll contains the code itself and does not need to resolve it at runtime.
In a Objective-C project I am using a static library, compilation of this static library depends on some preprocessor macros to be set.
When I set these macros in the project depending on the library the library does not see them. But when I set them in the library project it does work.
Since I want to reuse this library for other projects, I require to set the preprocessor macros for each project depending on the library separately. Is there a solution for this?
Preprocessor maros only have any meaning at compile-time, so any library you build will be specific to the values of these preprocessor macros at the time you built the library. You will either need lots of different versions of your library, built with the different possible values of your preprocessor macros, or you could switch to using a different method to control the behaviour of your library code which will work at run-time, e.g. setting some appropriate parameters through the library API.
This is not an answer per se, but something interesting I discovered while struggling with this same issue.
I have a static library (MyLib) that contains a header for logging (Log.h). I have an application project (MyApp) that uses MyLib. Log.h has some resemblance of this:
#ifdef LOG_LEVEL_DEBUG
# define LogDebug(...) NSLog(__VA_ARGS__)
#else
# define LogDebug(...)
#endif
In MyApp build settings, I can use the preprocessor macro LOG_LEVEL_DEBUG to successfully turn off and on logging. This works when I use LogDebug() in source files found in MyApp. However, the MyLib source files that use LogDebug() are not affected by the MyApp build settings. I have to use the MyLib build settings to affect LogDebug() within the MyLib source files.
I am pretty sure I know what is happening but I'd be open to correction. Below is the scenario where MyApp defines LOG_LEVEL_DEBUG in build settings (enabling debugging) and MyLib does not define it (disabling it).
When MyApp builds, it first compiles MyLib where all of the LogDebug() are replaced within the MyLib source files as no-op (since LOG_LEVEL_DEBUG was not defined). After MyLib is compiled, MyApp is compiled and all of the LogDebug() methods within MyApp source are replaced with NSLog() statements because LOG_LEVEL_DEBUG was defined in the build settings.
Question: why would an application not find the DLL “boost_thread-vc100-mt-1_46_1.dll” when the DLL is in fact properly installed, and other applications use the DLL successfully?
Problem: when starting an instance of my application, the following error message appears:
“The program can’t start because boost_thread-vc100-mt-1_46_1.dll is missing from your computer. Try reinstalling the program to fix this problem.”
Several reasons why this message confuses me:
The dll is present in C:\Program Files(x86)\boost\boost_1_46_1\lib
Another project with similar settings runs properly and does create
boost::thread objects successfully
When I remove the code that creates boost::thread objects from my application, the error
message does not appear.
Additional details:
I am developing a C++/CLI application using MS VS 2010 with CLR enabled.
I am using the Boost Thread library (version 1.46.1).
Following the advice on posts about using Boost Thread and C++/CLI, I added the following code to one of my header files:
#if defined(_MANAGED)
#define BOOST_USE_WINDOWS_H
#endif
#define BOOST_THREAD_USE_DLL
#include "boost/thread.hpp"
namespace boost {
struct thread::dummy {};
}
#pragma warning(push)
#pragma warning(disable:4793)
#include "boost/thread/mutex.hpp"
#pragma warning(pop)
#include "boost/thread/locks.hpp"
I appreciate any advice you may have. Thank you.
Being in C:\Program Files(x86)\boost\boost_1_46_1\lib doesn't help much.
It needs to be in the DLL search path.
Other applications using boost probably have a local copy of the DLL alongside the main executable.
You need to add the location of the boost libs to the linker search path.
Right click on the C++ project that is showing the linker error, select Properties. Go to Linker -> General then in the right hand panel you see Additional Library Directories. Put in the path to the folder holding boost_thread-vc100-mt-1_46_1.dll - typically this folder will hold all of your boost libs and will be something like D:\Program Files\boost\boost_1_49_0\stage\lib.
Now the linker will search that folder when looking for libs, and everything should work.
I'm currently busy on a project where I need to use an external accessory to read Mifare 1k tags.
The accessory was provided with an SDK, written in (Objective ?)C++ and I followed the instructions provided to set XCode to "Compile sources as: Objective-C++" and added "-Obj-C++" in "Other linkers flags.
The SDK compiles fine then, but trouble is I am already using several libraries in the project (such as ASIHTTPRequest, JSONKit, ...) and I get compilation problems because of those new settings in those libraries. If I switch back to the previous settings, I get compilation problems in the reader's SDK
The question is: is there a way to compile only the class from the SDK as C++ and the rest of the project as objective-c ?
Edit: the SDK files consists only of .h (and a linked library)
thanks for your help,
Mike
Select the file you want to compile as Objective C++ from the file navigator, and then select the File Type in the file inspector view. This is in Xcode 4, but there is a similar mechanism in Xcode 3.
Try renaming the files where you are including the library headers to myClass.h for interface and myClass.mm for implementation files. This forces the files to be compiled as objective-c++.
I have resolved this problem:
You should set "According to file type" to "Complile Sources As",
Set "-ObjC++" to the "Other Linker Flags"
The last,you should modify the files's suffix to .mm that reference
the library method
well, in Build phases tab, there is a section Compile sources. For file you want to use Objective-C++ compiler add flag: -xobjective-c++
tested in Xcode 12.5
I got a .h file, two .lib files, a .dll file and a tiny test project from a hardware vendor to talk to their hardware.
Compiling and running their test project works just fine. Noteworthy: they don't use the .dll. I can throw the dll-directory and all of it's content away, everything works just fine.
To start things off I simply copied the communication parts of their code (connect, disconnect and send a command) into my project. This is actually all that you can do. I have included the .h file and pointed to the directory containing the .lib files. Just like in the tiny test project. It all compiles, but when I try to run the project complains that it is missing the .dll file.
Can anybody explain what is happening? How are libs and dlls supposed to work?
All of this is on windows, VS2005. I compared the .vcproj files and could not find any significant differences.
The test project is statically linked - the lib is included in the exe.
Your project is dynamically linked - the dll is referenced and therefore needed at runtime.
See this Stack Overflow question for more information.
Basically the answer depends on whether you are going to use static or dynamic linking for your executable.
With static linking, you need the .h and .lib files but not the .dll files to compile and link. Your executable will be larger but you won't need any of the .h/.lib/.dll files during runtime.
With dynamic linking, you just need the .h files to compile and link. Your executable will be smaller but you will need one or both of the .dll files during runtime.
For a more detailed treatment of this from the Visual Studio perspective, check out http://msdn.microsoft.com/en-us/library/1ez7dh12.aspx -
"Dynamic linking differs from static linking in that it allows an executable module (either a .dll or .exe file) to include only the information needed at run time to locate the executable code for a DLL function. In static linking, the linker gets all of the referenced functions from the static link library and places it with your code into your executable."