I'm looking through the Microsoft MFC source file winctrl3.cpp and I see references to 3 symbols CBS_UNCHECKEDNORMAL, CBS_CHECKEDNORMAL, and CBS_UNCHECKEDDISABLED for drawing the check state of a checkbox. I'd like to know what the other choices are so I go searching the source files included with Visual Studio but I'm coming up empty, the single occurrence in winctrl3.cpp is the only one found.
I finally found an online Microsoft reference which tells me the values should be defined in Vsstyle.h and/or Vssym32.h, but I can't find those files in my Visual Studio 2005 installation or anywhere else on my system. What am I missing?
It's installed as part of the Windows SDK on my system (version 7, in my particular case). It may be that you need to perform a full SDK install to get that particular file or it may be a fairly recent addition to the SDK (i.e., more recent than the SDK included with Visual Studio 2005).
Related
I am attempting to compile a .cpp file on Visual Studio 2019 Preview 1 and the file windows.h is not present on the system. What do I have to do to make this file available to Visual Studio? The file being compiled contains include <windows.h>.
windows.h usually comes from Windows SDK installation. Like you discovered, some projects might even require a certain version of Windows SDK. Therefore, when such compilation errors happen, the first thing to do is to read carefully the source code documentation, which might indicate what is needed to install in advance.
Visual Studio 2017/2019 become more modular than previous releases, so missing a component is expected, and you can always go back to VS installer to find the suitable components to install.
I just installed Visual Studio Community 2017 for school purposes. My lecturer gave us these instructions to use a GraphicsSDK library with VS (after we have Visual Studio installed). I ran the Tutorial.sln file he gave but I got this error.
I have followed all the steps correctly. I've been looking at other questions on StackOverflow and they said to change the Properties/Output file to $(OutDir)$(TargetName)$(TargetExt) but mine is correct.
I also noticed one line in the code which was underlined red.
/* Render here */
glClear(GL_COLOR_BUFFER_BIT);
It said that GL_COLOR_BUFFER_BIT was undefined. Not sure if this matters at all.
In older versions of Visual Studio the folder settings were part of the IDE. But in version 2017 you specify the search paths in the application itself.
If you go to your projects properties you will see a VC++ Directories section:
You need to make sure that the folders to the libraries and include files are correct (for both debug and release configurations).
Then, when you do a build it will be able to find the definitions it needs. But your question is lacking a lot of information. This is my educated solution for now.
I have a problem with our executable. I'm running this C++ 32-bit executable on my Windows 7 64-bit development box that also has all those Microsoft applications (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office)...
And it's still running just fine.
Now I got the client installation of the very same program and was asked to test it with a clean Windows 7 installation. Thus I got one Windows 7 64-bit VMware and updated it to Windows 7 SP 1 (the very same version my developer box is tuning).
But while on my developer box everything is fine the program does not work with the VMware (30 days trial) box.
The x86 Dependency Walker is telling me that the following DLL files are missing:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL
I googled for those API-MS-WIN-... DLL files and found they should actually already be part of Windows 7 (some sites claiming the belong to Windows 8 and Windows Server 2012 though).
I already tried the suggested fixes I found, which are:
running 'sfc /scannow'
installing Visual Studio 2008 SP1 runtime executables
But that didn't solve anything. :-(
Side note: My development box does not have them either, and does not seem to need them. For example, the user32.dll on my box does not link against one of those, while the installation on the VMware does.
Any idea on how to fix this issue?
I tried to find a suitable download / fix on the Microsoft pages, but I failed.
After solving my issue I wanted to report what I found out, and I can't post this as an answer because the question has been closed.
Actually all the DLL files reported missing by the Dependency Walker tool, namely those
* API-MS-WIN-CORE-...
type DLL files were not part of the actual problem.
In my case the registration of three OCX files was missing and after that everything was just fine, BUT Dependency Walker tool still listed all the very same DLL files as before even when the program was just running fine now.
The gist of it: As someone elsewhere stated, the tool is a bit dated by now and does not always work properly with a newer OS. Thus keep an eye open and don't get mislead by missing 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... the problem probably lies entirely elsewhere.
This problem is related to missing the Visual Studio "redistributable package." It is not obvious which one is missing based on the dependency walk, but I would try the one that corresponds with your compiler version first and see if things run properly:
Visual Studio 2015
Visual Studio 2013
Visual Studio 2010
Visual Studio 2008
I ran into this problem because I am using the Visual Studio compilers, but not the full Visual Studio environment.
Going to dare to inject a new link here: The latest supported Visual C++ downloads. Stein Åsmul, 29.11.2018.
I just resolved the same problem with C++ Qt 5 and Windows 7 64 bits with MSCVC 2012.
In the beginning I thought it was a MSVC/Windows DLL file problem, but as BorisP said, the problem was in my project dependencies. The key is "How to know your project dependencies in Qt 5?".
As I didn't find any clear way to know it (Dependency Walker didn't help me a lot...), I followed next the "inverse procedure" that takes no more than 5 minutes and avoid a lot of headaches with DLL file dependencies:
Compile your project and take the executable file to an empty folder: myproject.exe
Try to execute it, It will retrieve an error (missing DLL files...).
Now, copy all the DLL files from Qt (in my case they were in C:\Qt\Qt5.1.1\5.1.1\msvc2012_64_opengl\bin) to this folder.
Try to execute again, it will probably works fine.
Start to delete progressively and try every time your executable still works, trying to leave the minimum necessary DLL files.
When you have all the DLL files in the same folder it is easier to find which of them are not valid (XML, WebKit, ... whatever..), and consequently this method doesn't take more than five minutes.
I just resolved the same problem.
Dependency Walker is misleading in this case and caused me to lose time. So, the list of "missing" DLL files from the first post is not helpful, and you can probably ignore it.
The solution is to find which references your project is calling and check if they are really installed on the server.
#Ben Brammer, it is not important which three .ocx files are missing, because they are missing only for Leo T Abraham's project. Your project probably calls other DLL files.
In my case, it was not three .ocx files, but missing MySQL connector DLL file. After installing of MySQL Connector for .NET on server, the problem disappeared.
So, in short, the solution is: check if all your project references are there.
As mentioned, DCOMP is part of the VC++ redistributables (implementing the OpenMP runtime) and is the only truly missing component. All the rest are false reports.
Specifically API-MS-WIN-XXXX.DLL are API-sets - essentially, an extra level of call indirection introduced gradually since Windows 7. Dependency Walker development seemingly halted long before that, and it can't handle API sets properly.
So there is nothing to worry about there. You're not missing anything more.
A better alternative to find the truly needed DLL files that are missing (if that is indeed the problem) is to run Process Monitor and step backwards from the failure, searching for sequences of failed probes for a specific DLL file in all the system path.
I also ran into this problem, but the solution that seems to be a common thread here, and I saw elsewhere on the web, is "[re]install the redistributable package". However, for me that does not work, as the problem arose when running the installer for our product (which installs the redistributable package) to test our shiny new Visual Studio 2015 builds.
The issue came up because the DLL files listed are not located in the Visual Studio install path (for example, C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist) and thus had not been added to the install. These api-ms-win-* dlls get installed to a Windows 10 SDK install path as part of the Visual Studio 2015 install (e.g. C:\Program Files (x86)\Windows Kits\10\Redist).
Installing on Windows 10 worked fine, but installing on Windows 7 required adding these DLL files to our product install. For more information, see Update for Universal C Runtime in Windows which describes the addition of these dependencies caused by Visual Studio 2015 and provides downloads for various Windows platforms; also see Introducing the Universal CRT which describes the redesign of the CRT libraries. Of particular interest is item 6 under the section titled Distributing Software that uses the Universal CRT:
Updated September 11, 2015: App-local deployment of the Universal CRT is supported. To obtain the binaries for app-local deployment, install the Windows Software Development Kit (SDK) for Windows 10. The binaries will be installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt. You will need to copy all of the DLLs with your app (note that the set of DLL files are necessary is different on different versions of Windows, so you must include all of the DLL files in order for your program to run on all supported versions of Windows).
This contribution does not really answer the initial question, but taking into account the hit-rate of this thread I assume that there are quite a few people dealing with the problem that API-MS-WIN-CORE- libraries cannot be found.
I was able to solve a problem where my application refused to start with the error message that API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL is not found by simply updating Visual Studio.
I don't think that my build environment (Windows 7 Pro SP1, Visual Studio Ultimate 2012) was messed up completely, it worked fine for most of my projects. But under some very specific circumstances I got the error message (see below).
After updating Visual Studio 11 from the initial CD-Version (I forgot to look up the version number) to version 11.0.61030.00 Update 4 also the broken project was running again.
This solved the issue for me:
Uninstall the Visual Studio 2010 redistributable package if you have it installed already, and then install Microsoft Windows 7 SDK.
I solved the problem. When I registered the OCX files, I ran it with the Command Window that had been executed as an administrator.
For anybody who came here, but with a Photoshop problem: my solution was to uninstall the MS VC++ redistributable first x86 and 64 both. Then install one appropriate to the Windows version and architecture (86 or 64).
Installation of SQL Server Management Studio 2014 on a freshly installed Windows 7 resolved this problem at our client after a two-day ridiculous battle.
I came here with this problem occurring, after trying a fresh Windows 7 OEM install, upgrading to Windows 10.
After some searching of Microsoft forums and such I found the following solution which worked for me:
Replace C:\Windows10Upgrade\wimgapi.dll with the one from C:\Windows\System32\wimgapi.dll
I suggest also checking how much memory is currently being used.
It turns out that the inability to find these DLL files was the first symptom exhibited when trying to run a program (either run or debug) in Visual Studio.
After over a half hour with much head scratching, searching the web, running Process Monitor, and Task Manager, and depends, a completely different program that had been running since the beginning of time reported that "memory is low; try stopping some programs" or some such. After killing Firefox, Thunderbird, Process Monitor, and depends, everything worked again.
I had the same problem. After spending hours searching on the web, I found a solution for me.
I copied the file combase.dll file (C:\Windows\System32) to the release folder, and it resolved the problem.
Just to confirm answers here, my resolution was to copy the DLL that was not loading AND the ocx file that accompanied it to the system32 folder, that resolved my issue.
I'm using the Visual Studio Setup project. If I go to the properties of the Setup project, it lets me choose which pre-reqs are required, at which point I choose the C++ Redistributable.
On some systems, this works fine - but recently my users are reporting that the install failed because "A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine."
What's the proper way to do this? Is Visual Studio's detection fouled up somehow and unable to detect C++?
Yuck, this is ugly. I was wondering what would happen after Microsoft gave up on the side-by-side install of the runtime DLLs for VS2010. Seems clear, the interwebs are full of this installer error. The biggest victim seems to be Microsoft itself with Streets and Maps failing to install.
I'm not aware of any security patches for it so I have to guess that you haven't updated to SP1 yet. And your customers use a product of a vendor that did. This is a battle that you're always going to lose some day. Do consider taking advantage of the app-local deployment for the DLLs, copying them in the same directory as your main EXE. Simply copy them from the vc/redist directory before putting the setup package together, no need to tick the prerequisite. You'll need:
msvcr100.dll and msvcp100.dll for the regular CRT
atl100.dll if you use ATL
mfc100.dll, mfc100u.dll, mfcm100.dll, mfc100u.dll if you use MFC (u = Unicode, m = managed)
mfc100xxx.dll where xxx is the 3 letter language code if you use MFC on a non-English machine
vcomp100.dll if you use OpenMP in your code.
Only disadvantage is that they won't get updated if there's a security patch. That could be an advantage too, depending on what color glasses you wear. If you're uncomfortable about it then keeping the machine that creates the setup package updated, including enabling Windows Update, is an important requirement.
The default Visual C++ 2010 Redistributable uses a Product Code for detection. So Visual C++ 2010 SP1 Redistributable is not detected as installed. This is why the package tries to install it and fails.
A good solution is to create your own custom prerequisite which uses a better detection criteria. Here is an article which may help you:
http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx
Visual Studio setup projects do not support custom prerequisite creation. However, it can be done by manually generating the required manifests.
You can find the manifests structure here: http://msdn.microsoft.com/en-us/library/ms229223(VS.80).aspx
These manifests can be generated automatically with the Bootstrapper Manifest Generator tool.
After generating the package manifests, you can add all these files (including the package) in a separate folder in the Visual Studio prerequisites folder, for example:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\
This way Visual Studio will show the prerequisite in your setup project properties page.
I just wondered if it possible within various Visual Studio versions to automatically remove all references from a project that were never been used?
In your answer, please specify which version of VS the solution applies to.
If you have Resharper (plugin) installed, you can access a feature that allows you to analyze used references via Solution Explorer > (right click) References > Optimize References...
http://www.jetbrains.com/resharper/webhelp/Refactorings__Remove_Unused_References.html
This feature does not correctly handle:
Dependency injected assemblies
Dynamically loaded assemblies (Assembly.LoadFile)
Native code assemblies loaded through interop
ActiveX controls (COM interop)
Other creative ways of loading assemblies
All you need is stone and bare knuckle then you can do it like a caveman.
Remove unused namespaces (for each class)
Run Debug build
Copy your executable and remaining namespace references to new location
Run the executable
Missing Reference DLL error will occur
Copy required DLL from Debug folder
Repeat 4-6
Gu Gu Ga Ga?
Throw your stone
You can also rely on your build tools to let you know which reference is still required. It's the era of VS 2017, caveman still survived.
The Resharper extension will do this for you.
This extension supports Visual Studio 2005 through 2017.
While the compiler won't include unused assemblies, extraneous using statements and references slows down Visual Studio and Intellisense, since there's more code the tools have to consider.
You can try the free VS2010 extension: Reference Assistant by Lardite group. It works perfectly for me. This tool helps to find unused references and allows you to choose which references should be removed.
In a Visual Basic project there is support to remove "Unused References" (Project-->References-->Unused References). In C# there isn´t such a function.
The only way to do it in a C# project (without other tools) is to remove possible unused assemblies, compile the project and verify if any errors occur during compilation. If none errors occur you have removed a unused assembly. (See my post)
If you want to know which project (assembly) depends on other assemblies you can use NDepend.
With Visual Studio versions 2017 and 2015, you can do this with the Code Map feature, but this feature is only available in the Enterprise Edition, not the Community or Professional versions.
Right-click on the project node in the solution explorer and select 'Show on Code Map.' This will display your .dll as a single node in a blank graph. Right-click on that node in the Code Map and select "Show Assemblies This References." This will add an additional node called "Externals" which can be expanded to show only the assemblies that are actually referenced.
For Visual Studio 2013/2015/2017 there is an extension that does exactly what you want: ResolveUR. What this basically does is:
reference is removed in the project
project is compiled with msbuild
check for build errors
restore removed references if there were build errors.
For anybody coming here looking for Visual studio 2012:
Download and Install Reference Assistant for Visual Studio 11
Later you can do:
In Visual Studio 2013 this extension works:
ResolveUR
Some people suggested to use an awesome tool - Reference Assistant for Visual Studio. The problem is that VS2012 is the latest supported Visual Studio. But there is the way to make it work in VS2013 as well ;)
And here is how:
1) Download Lardite.RefAssistant.11.0.vsix
2) Change the extension to zip: Lardite.RefAssistant.11.0.vsix -> Lardite.RefAssistant.11.0.zip
3) Unzip and open the extension.vsixmanifest file in the text editor
4) Find all occurences of InstallationTarget Version="[11.0,12.0)" and replace them with InstallationTarget Version="[11.0,12.0]" (note the closing bracket)
5) Save the file and zip all files so they are on the root zip level
6) Change the extension of the new zip to vsix
7) Install and enjoy :)
I've tested it with VS2013, thanks source for the tutorial
EDIT
Add to support VS 2015 Community Edition
<InstallationTarget Version="[14.0,15.0]" Id="Microsoft.VisualStudio.Community" />
Meaning of the brackets
[ – minimum version inclusive.
] – maximum version inclusive.
( – minimum version exclusive.
) – maximum version exclusive.
[Update] This feature is only available for .Net core projects.
This feature will be coming to Visual Studio 2019 very soon and already available with Visual Studio 2019 v16.10 Preview 1.
This option is turned off by default, but you can enable it under menu Tools > Options > Text Editor > C# > Advanced. Select the Remove Unused References command in Solution Explorer (Experimental). Once the option is enabled, the Remove Unused References command will appear in the right-click menu of a project name or dependencies node.
You can use Reference Assistant extension from the Visual Studio extension gallery.
Used and works for Visual Studio 2010.
In the VS2022 (preview at the moment of writing) this comes out of the box for SDK Style Projects (read: .NET Core and newer).
If it is available you can find it in the project context menu:
You get to choose what to do with each finding.
Read more about it here.
Pro-tip: Check if your project compiles and runs correctly after applying this. In my experience it doesn't check whether a dependency is used at runtime, for instance.
Using DevExpress, I follow these instructions:
In VS, go to DevExpress - Editor - Code Cleanup. Under Rules, check 'Remove unused namespace references'. Click OK.
Right-click on the solution, and choose 'Code Cleanup'. The cleanup runs for a few minutes, and finishes.
Build your application
The following method does not depend on any 'add-on's and is not very painful.
Step through each of your source files and
Select all (Ctrl-A)
Toggle outline expansion (Ctrl-M, M). This will reduce the file to two lines.
Click on the namespace's '+'. This will show each of the file's classes as a single line. Scan each class's reference count, looking for unreferenced classes.
Click on each of the classes' '+'. This will show each of the class functions as a single line. Scan each function's reference count, looking for unreferenced functions.
Scanning each file looking for '0 reference' takes only a second.
Scanning an entire project takes only a couple of minutes.
In VB2008, it works this way:
Project>Add References
Then click on the Recent tab where you can see list of references used recently. Locate the one you do not want and delet it. Then you close without adding anything.