I recently have been asked to write a .dll and some function that works with it. Since I've never touched this before, I would appologize if I asked something stupid.
First of all, my IDE is Visual Studio 2012 Express version.
On the other (green) hand, I follow the instructions at: http://msdn.microsoft.com/en-us/library/ms235636(v=vs.110).aspx to create projects.
I successfully built the dll project as adviced. The .dll file is peacefully lying in the Debug folder. However, when I create another project and try to reference to the .dll file that I created in the first project, at Framework and References page, I clicked Add New Reference, and no dll is found.
I am quite confused at this, since I've done everything the MSDN said. Thus I start to wonder if this is a limitation of Express version.
Can anyone clue me if I am on the right track?
Many thanks in advance.
The instructions say
The Add Reference dialog box lists the libraries that you can
reference. The Project tab lists the projects in the current solution
and any libraries that they contain. On the Projects tab, select the
check box next to MathFuncsDll, and then choose the OK button.
This means you add a reference to the dll project in the references section, not the dll that it produces.
Don't forget to link with the .lib file the dll project produces and give it a fighting chance of finding any header files you need to include, as per the instructions
Related
My current preferred C++ environment is the free and largely excellent Microsoft Visual Studio 2005 Express edition. From time to time I have sent release .exe files to other people with pleasing results. However recently I made the disturbing discovery that the pleasing results were based on more luck that I would like. Attempting to run one of these programs on an old (2001 vintage, not scrupulously updated) XP box gave me nothing but a nasty "System cannot run x.exe" (or similar) message.
Some googling revealed that with this toolset, even specifying static linking results in a simple hello-world.exe actually relying on extra .dll files (msvcm80.dll etc.). An incredibly elaborate version scheming system (manifest files anyone?) then will not let the .exe run without exactly the right .dll versions. I don't want or need this stuff, I just want an old fashioned self contained .exe that does nothing but lowest common denominator Win32 operations and runs on any old win32 OS.
Does anyone know if its possible to do what I want to do with my existing toolset ?
Thank you.
For the C-runtime go to the project settings, choose C/C++ then 'Code Generation'. Change the 'runtime library' setting to 'multithreaded' instead of 'multithreaded dll'.
If you are using any other libraries you may need to tell the linker to ignore the dynamically linked CRT explicitly.
My experience in Visual Studio 2010 is that there are two changes needed so as to not need DLL's. From the project property page (right click on the project name in the Solution Explorer window):
Under Configuration Properties --> General, change the "Use of MFC" field to "Use MFC in a Static Library".
Under Configuration Properties --> C/C++ --> Code Generation, change the "Runtime Library" field to "Multi-Threaded (/MT)"
Not sure why both were needed. I used this to remove a dependency on glut32.dll.
Added later: When making these changes to the configurations, you should make them to "All Configurations" --- you can select this at the top of the Properties window. If you make the change to just the Debug configuration, it won't apply to the Release configuration, and vice-versa.
I've had this same dependency problem and I also know that you can include the VS 8.0 DLLs (release only! not debug!---and your program has to be release, too) in a folder of the appropriate name, in the parent folder with your .exe:
How to: Deploy using XCopy (MSDN)
Also note that things are guaranteed to go awry if you need to have C++ and C code in the same statically linked .exe because you will get linker conflicts that can only be resolved by ignoring the correct libXXX.lib and then linking dynamically (DLLs).
Lastly, with a different toolset (VC++ 6.0) things "just work", since Windows 2000 and above have the correct DLLs installed.
In regards Jared's response, having Windows 2000 or better will not necessarily fix the issue at hand. Rob's response does work, however it is possible that this fix introduces security issues, as Windows updates will not be able to patch applications built as such.
In another post, Nick Guerrera suggests packaging the Visual C++ Runtime Redistributable with your applications, which installs quickly, and is independent of Visual Studio.
I'm new on here, but not a total beginner to programming. I got a book on creating a 2D DirectX game engine so I could expand my programming knowledge, however I am new to C++ and DirectX itself, so I'm afraid I'm a bit clueless on working with multiple project files and headers. I decided to develop my game engine in a proper development environment, so I got VS2013 Professional though the Dreamspark program.
As I said, I haven't worked with something like VS before, so I'm hitting issues with getting my game engine running and I'm not sure what to do. The book said that if I get all my code down correctly (in 3 .cpp source files, 3 headers and 1 main .cpp source file to initialize my engine in a blank game project) the program should compile fine, and it does. The issue is that I only get the resultant .obj files and the project's static library file to appear in my project folder. I don't know what I have to do to get the project to compile the executable needed to actually run this 'blank game' with the engine.
The actual project solution was taken from the disk which came with the book, I wrote my code on top of that solution as my own was causing linker errors. The project properties show that the project is defined as a .lib project, so how is this supposed to work?
I apologize if this is a simple problem, but I'm only used to working with 1 file console applications in C, this is a big jump for me but I'd like to understand how I'm meant to get an .exe created from this project, I would appreciate it if someone could explain to me how this sort of .lib project works. I can post the code if it's necessary, but there's 7 files of it so it's quite long. Thanks!
Solution 1:
As the project contains a main.cpp it looks like it is not meant to be a library-project.
In VS2013 you can switch the type of a project by
In your Solution Explorer (on the left side by default) rightclick onto the project
Select the item Properties from Context Menu (should be on the bottom)
Select the category General
In the section Project Defaults change the Configuration Type to Executable (.exe)
Solution 2:
It could be possible that the executable is stored somewhere else after a successful build. Check what is configured as output directory:
In your Solution Explorer (on the left side by default) rightclick onto the project
Select the item Properties from Context Menu (should be at the bottom)
Select the category General
In section General there should be an Output Directory defined (At the top of the configuration). Per default it should be something like $(SolutionDir)$(Configuration)\
I'm using VS2013 Express, but it should work with Prof too. I'm also using a German edition, hope I translated everything well.
Information about what I want to do:
-read in a few integer variables from a text file that will be located on a dropbox public folder.
-the variables will be used to trigger some if statements thus controlling my application remotely if I need to have it do something ( I would just save the variable I need to that text file and my program with would read from it every 5 seconds would see it and perform the required actions).
-this is a console application which is being built and compiled in visual studio 2010 on windows 7. The software will also be running on a win7 computer.
I need help with:
I already have read on using a library called libcurl. The problem is that I do not know how to link this library with my project in vs2010. Detailed instructions on how to do this on vs 2010 would be very helpful.
OR
if you can think of a better and easier way to accomplish what I need done, offer some advice and direction
It sounds like you're a novice, is that correct? If not then apologies for stating the obvious.
To use your compiled DLL in your application you need to 'add a reference' to it. You can do this by adding what is called a binary reference, where you simply tell visual studio where to find the dll. Or you can add a project reference if the project which is producing the dll is within the same solution. The best approach is to use something called nuget. It's a visual studio extension which automates the adding of binary references available from a public repository.
I have just done a search for libcurl on nuget.org and drew a blank. As I am unfamiliar with this library you may have better luck finding a nuget package as you will be a le to search using better terms that I did (curl and libcurl)
Whatever approach you take, just right-click on the project in which you want to use libcurl within the solution explorer and you should find an add reference option in the menu.
I am creating a simple C++ DLL project using Visual Studio 2008 Express Edition.
I have a few classes inside a namespace, and a few non-static functions and constructors inside it are declared with __declspec(dllexport).
All those functions are implemented.
I also have an extern "C" BOOL APIENTRY DllMain function which simply returns TRUE.
As I hit Debug(or Release), it successfully builds with no errors nor warnings.
The output folder(either "Debug/" or "Release/") gets files such as "BuildLog.htm", one ".obj" file per source file, "vc90.pdb", "vc90.idb", "[DLLNAME].dll.embed.manifest", "[DLLNAME].dll.embed.manifest.res", "[DLLNAME].dll.intermediate.manifest" but... not the DLL itself.
This is the first time I try to compile this project(so I never sucessfully compiled before) and I have little experience with C++/DLLs, although I do know standalone C++ and created Linux C shared objects before.
What am I doing wrong? Is there any particular required file that I'm missing?
I'd look up a little higher in the directory structure (the one that the solution is in) and see if your Debug/Release folders (with the DLL) are there.
I think the default is to put the actual DLLs in folders in the solution directory, not the project directory (I think the assumption is that you want all the DLLs that you build for a solution to go to the same place)
Right click on <ProjectsName> in Solution Explorer View, select Properties, go to Configuration Properties > General tab and check out the Output Directory field. The path may consist of some macros like $(SolutionDir)$(ConfigurationName) etc. Click on it, select Edit and then when a window pops up choose Macros to see what they actually mean e.g. which directory SolutionDir maps to. You can deduce the output dll's path from there.
My current preferred C++ environment is the free and largely excellent Microsoft Visual Studio 2005 Express edition. From time to time I have sent release .exe files to other people with pleasing results. However recently I made the disturbing discovery that the pleasing results were based on more luck that I would like. Attempting to run one of these programs on an old (2001 vintage, not scrupulously updated) XP box gave me nothing but a nasty "System cannot run x.exe" (or similar) message.
Some googling revealed that with this toolset, even specifying static linking results in a simple hello-world.exe actually relying on extra .dll files (msvcm80.dll etc.). An incredibly elaborate version scheming system (manifest files anyone?) then will not let the .exe run without exactly the right .dll versions. I don't want or need this stuff, I just want an old fashioned self contained .exe that does nothing but lowest common denominator Win32 operations and runs on any old win32 OS.
Does anyone know if its possible to do what I want to do with my existing toolset ?
Thank you.
For the C-runtime go to the project settings, choose C/C++ then 'Code Generation'. Change the 'runtime library' setting to 'multithreaded' instead of 'multithreaded dll'.
If you are using any other libraries you may need to tell the linker to ignore the dynamically linked CRT explicitly.
My experience in Visual Studio 2010 is that there are two changes needed so as to not need DLL's. From the project property page (right click on the project name in the Solution Explorer window):
Under Configuration Properties --> General, change the "Use of MFC" field to "Use MFC in a Static Library".
Under Configuration Properties --> C/C++ --> Code Generation, change the "Runtime Library" field to "Multi-Threaded (/MT)"
Not sure why both were needed. I used this to remove a dependency on glut32.dll.
Added later: When making these changes to the configurations, you should make them to "All Configurations" --- you can select this at the top of the Properties window. If you make the change to just the Debug configuration, it won't apply to the Release configuration, and vice-versa.
I've had this same dependency problem and I also know that you can include the VS 8.0 DLLs (release only! not debug!---and your program has to be release, too) in a folder of the appropriate name, in the parent folder with your .exe:
How to: Deploy using XCopy (MSDN)
Also note that things are guaranteed to go awry if you need to have C++ and C code in the same statically linked .exe because you will get linker conflicts that can only be resolved by ignoring the correct libXXX.lib and then linking dynamically (DLLs).
Lastly, with a different toolset (VC++ 6.0) things "just work", since Windows 2000 and above have the correct DLLs installed.
In regards Jared's response, having Windows 2000 or better will not necessarily fix the issue at hand. Rob's response does work, however it is possible that this fix introduces security issues, as Windows updates will not be able to patch applications built as such.
In another post, Nick Guerrera suggests packaging the Visual C++ Runtime Redistributable with your applications, which installs quickly, and is independent of Visual Studio.