I have been writing my own library wrapper for Win32. I want to have it as an easily accessible library I can include in my projects.
Currently I have to manually add all the files to the project I am creating, then add the code:
#include "..etc/somefolder/frzn_windows.h"
Is there a way I can setup Microsoft Visual Studio 13 to automatically link the folder I store "frzn_windows.h" in, and also so I don't have to add each .h/.cpp file to the project. Similar to how it knows "windows.h" or < string>, etc.
I don't want the library to be a .dll or anything, just code that includes a bunch of classes to make it easier to use the Windows API.
You can use Additional Include Directories feature, that is accessible through project's Property Pages. See official Microsoft documentation here for details.
Related
I am creating a static library project in visual studio for personal use, and I'd like to include another existing static library into my own static library.
Usually (for executible projects) I can set up extra include and lib directories in the project's properties, but this time the menues are different and I don't know which settings to use. How would I do that?
You can include a static library inside a static library, but it generally leads to bloat and other problems.
The best approach is usually to add the link library to your 'public header' using a #pragma so it's automatically linked:
#pragma comment(lib,"nameoflibIneed.lib")
I figured out a sort of hacky way to make it work.
I just included the library normally as I would in a normal project, and only after that I changed the project type to .lib.
Apparently the additional dependencies get saved after changing the type of the project even though the respective menus in the project configuration pages disappear.
I want to make a multilanguage program via using resources(.resw files).
Its really easy for PCL but I dont know how to do it in Shared Project?
Create a Portable Class Library (PCL, or just Class Library Project) using .NET Standard, in order to localize resources in a Xamarin.Forms shared project.
Create the PCL, and then reference it from all 3 projects (Android, iOS, UWP).
Using a naming convention like AppResource.resx for the main resource, select that code generation should be Public, from inside the resource editor (in the top toolbar, there is a drop-down.)
Afterward, create a resource filed named AppResources.fr-FR.resx for French, for example. Always use the format ResourceFile.Language.resx.
Code generation will automatically be disabled for the localized resource when you name it, by the project manager. Keep it that way. It doesn't need code generation.
Voilà! You can now access localized resources from a shared Xamarin.Forms app using a Portable Class Library.
Now you can follow the rest of This Tutorial From Microsoft from within the PCL.
I've faced some day ago the same problem (and with .net standard there isn't documentation about it).
I've created a library to do quickly the localization also in shared project.
Hope it helps:
https://github.com/andreabbondanza/DewXamarinLocalization
I am building a DLL using visual studio, which involves installing the following libraries :
GLM
GLFW
GLEW
I linked those libraries to visual studio using the following method :
specifying Additional Include Directories in the project property page
specifying Additional Dependencies in the project property page
specifying Additional Library Directories in the project property page
Of course GLM is a header only Library, which means that I am only required to specify the Additional Include Directories for GLM. And my dll built perfectly fine.
But the real problem occurs when using the library in a test project. I linked my test project to my library using the method mentioned above, but when I tried to build the test project, it produces the following results :
Cannot open include file <GLFW/glfw3.h>
And the same goes for glew. It seems that these libraries are not found when the library is being used by another test project. How can I fix this? Any help would be highly appreciated.
Set the Additional Include Directories correctly for all projects. The compiler doesn't magically inherit settings from a project which happens to have it's output linked into another project. So you have to provide it the correct include path for any source file it sees. To spare yourself from having hardcoded paths to include directories you could use a property sheet common for both projects. Or you could tackle the problem in code and make use of the PIMPL idiom (eventually as simple as e.g. forward declaring some GL types and using a unique_ptr to them in public classes) so the headers of your project never expose any of the external include files.
In Visual Studio 2010 have a website project, a class library projects, and a console app.
The class library project talks to YouTube and references dll's Google.GData.Client, Google.GData.Extensions, Google.GData.YouTube etc..
When I add a reference to this project from the console app it just adds the class library dll.
But when I add a reference to the class library project from the website it automatically adds all the google dlls.
Why is this? The console app behaves as I would expect just adding the reference to the class library, but the website adds all the dlls that the class library is dependent on also to the website.
Really I don't want this because I don't want the website to have any knowledge of the underlying framework (youtube). e.g. I don't want developers to be able to create youtube video objects. I have a wrapper class for this so if the underlying video repository changes I won't have to make changes all over the website.
All directly or indirectly dependent assemblies will need to be present in order for your Web application to use your class library. Your console application, when built, will also have the dependencies in the same folder as the executable. If you do not want it readily apparent that you use the Google libraries, you will need to embed them into your class library's assembly.
Another SO question on the topic of dependencies is here.
we're building a cross-platform utility which must have a small footprint. We've been pulling header files from boost as and when we need them but now we must link against some boost C++ thread code. The easiest immediate solution was to create our own custom library using CMake's "add_library" command to create a static library composed of some boost thread source files. These compile without any problems.
The difficulty arises when I try to link to this library from an executable. Visual Studio 2008 returns an error saying that it cannot link to "libboost_thread-vc90-mt-sgd-1_40.lib". What really puzzles me is that I've grepped through all the source code and CMake config files and I can't find any reference to this libboost library, leading me to think that this has been autogenerated in some way.
This works OK in Linux, can anyone point out why I'm experiencing these issues in Windows?
#Gearoid
You found the correct reason for your problem, but not the correct solution. The BOOST_AUTO_LINK_NOMANGLE is an internal, i.e. for library authors, definition to control the auto-linking. The user level definition is BOOST_ALL_NO_LIB which when defined disables the auto-linking feature for all Boost Libraries code you use. This is described in the user.hpp configuration header (see user.hpp near the bottom and the Boost Config documentation). You can also control this on a per library level as describe in that header.
Ok, well, it turns out that Boost uses this auto-link feature for Visual Studio which embeds references to a mangled (ie, platform-compiler-mult-threaded, etc) boost library name.
The header file which controls this is called "auto_link.hpp" which lives in the config directory of the boost include tree. There's a special preprocessor definition called "BOOST_AUTO_LINK_NOMANGLE" which toggles this behaviour.
Another triumph of mediocrity for Microsoft.