I'm not sure if anyone has noticed but there seems to be a conflict with the DirectX SDK and VS2010's Windows SDK. If you look inside the folder under the directory
C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Include
You will see it contains the old headers for DirectX 11. The above directory is by default included to each VS 2010 project file and is required in order for VS 2010 to be able to compile correctly.
The same is true for .lib files for DirectX.
Now here lies the problem, to include the Directx SDK to your project in VS2010 you add the directories via the project property sheet. This automatically means you are including both the old headers and libs for DirectX as well as the new ones... :(
If you think you're building with the latest DirectX libs and header files you may very well be mistaken as the compiler could be using the unintended files.
How can I get around this problem as I can't seem to compile anything without keeping the default project settings ?
Also bare in mind I am using C++ and VS2010 Ultimate from MSDNAA.
Short answer: It probably doesn't matter.
Updated DXSDK installation won't update the system DLLs that ship with windows. It doesn't matter if you are including/linking with the DXSDK directory or the v7.0A directory. When the app runs, it loads the same DLLs either way. (Notable exception: the D3DX_xx.dll for helper functions - as those aren't OS components, they ship with the SDK and are meant for inclusion in the app setup package). The header files that ship with DXSDK should be nearly identical to what's in the v7.0a directory.
And if I'm not mistaken, include and lib directories specified in the Project Settings dialog for your app take predence BEFORE default SDK dirs. So updating your Project Settings dialog should be ok.
But if you really want to be sure... Instead of adding the DXSDK header/libs for each project, make them default search directories for all projects.
From the top-level menu for Visual Studio: Select Tools->Options.
From the left-nav menu on the Options dialog select "Project & Solutions", and "VC++ Directories" underneath that.
Then on the dropdown in the top right for "Show Directories for", select "Include Files".
Makes sure your $(DXSDK) include directory comes before the $(WindowsSdkDir) entry. If it's not already there, add it.
Repeat this for the "Library Files" option under the "Show Directories for" menu option.
Related
I've been trying for days to figure out how to get my native C++ DLL dependencies included in my ClickOnce deployment of a C# WinForms app built with VS2019. The native DLLs do not appear under Publish -> Application Files on the Properties page of the main .NET app (though the .NET DLLs do).
I've read this a hundred times:
Set the Build Action for the native DLLs to 'Content'.
... and I think I'm interpreting/doing that wrong.
Output from the native C++ projects is naturally not 'included' in any projects, (an apparent prerequisite for exposing the Build Action property,) and thus does not appear in Solution Explorer to allow me to set it to 'Content'. So I
[Solution Explorer] -> Project -> Add -> Existing Item -> [select native C++ DLL]
to add the native C++ DLLs to the Project to enable the Build Action property, which I then set to 'Content'. {Important Note: It has to be 'included' in a Project, rather than just the Solution to get a Build Action property.}
So I do that and it works, but of course I had to select a specific platform and configuration (e.g., x64 & release) of the native DLL, and this selection is fixed (not controlled by the selections in the VS2019 GUI when I build), and worse -- not even labeled as to which platform & configuration is 'included' in the project. {Side note: How did I not have to select which version (x86 vs x64) of the .NET DLLs to use under Publish -> Application Files ? It just automatically picks the right ones? How do I set up an x86 version and a x64 version that I can switch back & forth between & build each?} I cannot imagine this is the way it is supposed to be done. It is fragile and opaque. Surely there is a better way. I think I'm missing something that everyone else finds 'obvious'. Any other developer who tries to use or maintain this configuration will curse my name, and be right for doing so.
What is the 'right way' of making the ClickOnce deployment (via the VS2019 GUI) include my native DLLs (the projects for which are included in the same solution) in the ClickOnce deployment package?
Note, I found one promising setting in the Properties Page for the native C++ projects: Custom Build Setup -> General -> Treat Output as Content. But it does not seem to have any effect.
I'd be eternally grateful for any pointers.
After refining this for another day or so, I've found that the VS2019 GUI just comes up short for this purpose. The better answer is to just manually edit your .csproj file for the .NET project to Include the native DLLs as Content. Find the other elements in that project file and add the native DLLs like this:
<ItemGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
<Content Include="..\bin\MyApp\x64\Release\native1.dll">
</Content>
<Content Include="..\bin\MyApp\x64\Release\native2.dll">
</Content>
</ItemGroup>
<ItemGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
<Content Include="..\bin\MyApp\x86\Release\native1.dll">
</Content>
<Content Include="..\bin\MyApp\x86\Release\native2.dll">
</Content>
</ItemGroup>
(where *..\bin\MyApp{x86|x64}{Debug|Release}* is your output folder where your native DLLs, native1.dll and native2.dll have been copied, post-compile, to be used by your .NET app, MyApp.exe). Of course the x86 folder contains the 32-bit native DLLs, the x64 folder contains the 64-bit native DLLs, etc. - you know the drill.
No confusing extra links and whatnot to clutter up the solution/project, and the .dll files appear where they are supposed to, rather than in separate child sub-directories.
Of course you could add additional elements for the remaining conditions -- namely the debug builds, but who wants ClickOnce deployments for debug versions? You're probably running those directly from Visual Studio, right?
Adapted from here :
Compile your solution.
Right click on the managed project and select "Add/Existing Item". Do not use "Add Reference".
Navigate to your compiled native DLL and select it (adjust file types as needed to expose it).
Click on the down arrow in the "Add" split button and select "Add As Link" (this allows us to not keep multiple copies of the DLLs floating around).
Right click on that freshly added file and select "Properties".
Make sure "Build Action" is "Content" and "Copy To Output Directory" is set to "Do not copy" (since you already automated that task elsewhere, long before getting to the deployment stage of development).
Note that you'll get a 'File Not Found' error upon initial build after a proper cleaning of all output folders, but the native DLL will be created anyway, preempting that error on the next full build.
On the Properties page for the .NET app, do Publish -> Application Files -> Reset All to populate the native DLLs into the list. Adjust 'Publish Status' et. al. as needed.
Publish.
I found that I can maintain a 'virtual' folder structure in the project to store the links to the various versions (e.g., x86 vs. x64 and debug vs. release) of the native DLLs without cluttering up the file system, (and to ensure the DLLs aren't stale): Add the folder structure (e.g., ".\NativeDLLs\x64\Release", etc.) via the Solution Explorer, and add Links only (no real files) to the folders. Then delete the folders from the file system using Windows Explorer or shell commands. They will remain in Solution Explorer after deletion from the file system because they still contain the links.
The hierarchy of those virtual folders now exists only in the project file ([appname.csproj]) as Content elements (containing the Links) within Item Group elements (which seems to be the key to getting them to appear in the ClickOnce deployment world).
One pointer (for myself) that would have helped: Don't be afraid to hit the Reset All button on the Publish -> Application Files dialog.
I have a Visual Studio 2017 C++ project which depends on ffmpeg libraries. As of now it crashes at run time because of the missing dependency avformat-58.dll. I've tried adding this file into the project by dragging it into my project but that does not suffice. I tried looking at the Add Reference screen but it is empty. What can I do?
On the advice of #HansPassant I added the dll(s) to the project as existing external files. I think there should now be an option somewhere to "Copy to output directory" but I'm not seeing it. Here is what I see when I open property pages of one of the dlls.
#sellotape Here is a screenshot of the window when I just single click.
According to this documentation https://learn.microsoft.com/en-us/windows/desktop/Dlls/dynamic-link-library-search-order I can copy the necessary dlls to any directory in the PATH environment variable. There were many dlls already in C:/Windows/System32 already so I just put the ffmpeg dlls there as well and the executable runs.
I'm new to visual studio and can't seem to find an answer to this anywhere.
I'm working on a project in VC++ with VS2010. I have another project that builds into a .lib file set up as a reference, but can't figure out how to actually include the headers. Google has proved useless. Please help!
Generally this is done by adding the directory where the include files live to the project's "Additional Include Directories" property (in the "C/C++ | General" property page).
Note that the location can be a relative path if the different projects will always be at the same file system level relative to one another, or they can use VS macros or environment variables.
I did see some similar questions about this - but I couldn't piece together what I needed.
I'm using boost in a project in Visual Studio 9, and I'm unable to get it to recognize all the header files that I'm trying to include. I'd installed Boost using the Windows installer that also places the binaries on my machine.
In Visual Studio, I modified the Project->Properties->Linker->Additional Libarary Dependencies to include the folder "mypath\boost_1.44\lib", which contains the binaries - but I still can't get VS to recognize my Boost header files. Please help!
Cheers.
edited to clarify some text
You need to modify the project properties to add header locations for the boost headers as well. If you want a global setting, this is how you do it:
Tool->Options->Projects and Settings->VC++ Directories. Then on the right hand side, Open the dropbox labeled "Show Directories For" and pick "Include Files".
Add a new line for your boost header path.
This is a screenshot from VS2008 - it is similar in VS2010 and VS2005.
Additionally, you can also set these directories on a per-project basis by modifying each project's specific properties.
i would like to use OpenGl in Visual Studio 2010. Following Problem: "error LNK1104: Data "GIU32.lib OpenGL32.lib freeglut.lib glut32.lib" could not be oppend"
I read many Tutorials but they don´t help me :-(.
The lib data sets are in "C:\Program Files(x86)\Microsoft SDKs\Windows\v7.0a\lib".
The header data sets are in "C:\Program Files(x86)\Microsoft SDKs\Windows\v7.0a\Include\gl"
The dll data sets are in "C:\Windows\SysWOW64"
I Use Windows 7 Professional 64Bit.
I put "GIU32.lib OpenGL32.lib freeglut.lib glut32.lib" on Project > Properties > Linker > Input.
This is what you need to do.
Obtain GLUT for Windows (OpenGL Utility Toolkit) from Nate Robins’ web page. I put it on my C drive. The current documentation for GLUT tells you to go into the glut project folder and build the glut.dsw Visual Studio project. This is a little misleading since there is no glut.dsw file and all the dll, lib etc files you need are already there! So don’t worry about doing this, just download it.
Create a Visual Studio Project such as a new Console Application. For Windows XP: paste the glut32.dll file into: C:\Windows\System32. For Windows 7: place the glut32.dll inside the C:\Windows\SysWOW64 folder instead.
In the Project properties, select C/C++ -> General -> Additional Include Directories and add the location of the glut.h header file. This might be C:\glut-3.7.6-bin\
In the Project properties, select Linker -> General -> Additional Library Directories and add the location of the glut libraries eg C:\glut-3.7.6-bin\
In the Project properties, select Linker -> Input -> Additional Dependencies and add “glut32.lib”.
It should then compile. For a more detailed explanation, plus advice for installing the latest Windows Drivers from the Intel site, see this blog post.
Your error message lists all missing files in the same error.
That means you didn't set your dependencies correctly, because the linker searched for the file "GIU32.lib OpenGL32.lib freeglut.lib glut32.lib", which doesn't exist, of course.
The file names have to be separated by ";" in the Additional Dependencies section (under Linker > Input).
Or, if you use the edit menu by choosing it from the drop-down selection, each dependency has to be in a new line.
So you have to write "GIU32.lib;OpenGL32.lib;freeglut.lib;glut32.lib".
If error persists, you just put the libs in wrong place. Try to define additional lib path in project properties (sorry, I don't have VS 2010 around to show you exact location).
The DLLs need to be in BOTH system32 and syswow64
See here:
http://www.james-bennet.com/2011/10/using-glut-under-visual-studio-2010/
Has a HOWTO including a screenshot of the linker options you need to set.