why i don't have Microsoft.VC80.MFC-file? - windows-7

Got a fresh Win7 machine with VS2005 installed. I tried to start a MyApp.exe that is built with manifest that says in Manifest.bin:
...
<assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
...
and the result was error message "The application has failed to start because it's side-by-side configuration is incorrect...
Event viewer told me the reason in detail:
Activation context generation failed for "c:\Xxx\MyApp.exe". Dependent Assembly Microsoft.VC80.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.4053" could not be found. Please use sxstrace.exe for detailed diagnosis.
so I browsed the winsxs folder and indeed all "4053-folders" were missing. Then i edited Manifest.bin and replaced 4053 with 4927. The errors reocurred with different version. Then I found out that I got "4927-folder" for msvcr80.dll but no "4927-folder" for mfc80.dll.
Two questions:
-Why no "4927-folder" for mfc80.dll?
-How to get all "4053-folders" ?
Thanks & BR -Matti

You should either install Visual C++ redistributable or use merge modules to add the redistributables into your Windows Installer installation package. Or alternatively you should copy MFC libraries in the directory with your application.
Libraries that can be used as private assembly (in your app directory) are located in C:\Program Files (x86)\Microsoft Visual Studio 8\VC\redist\x86, or in amd64 if your app is 64 bit.
Merge modules for Windows Installer (MSI) are in C:\Program Files (x86)\Common Files\Merge Modules.
Redistributable package that installs all the libraries can be found in C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86\vcredist_x86.exe for 32 bit programs and in …\vcredist_x64\vcredist_x64.exe for 64 bit programs. You can get these files from Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update.
And I think you want to update Visual Studio with this package Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update.

Related

Visual Studio 2022: Cannot open include file: 'ctype.h'

I've got the infamous error message in C++ build: "Cannot open include file: 'ctype.h'". I know a similar question was already asked multiple times, but my case seems different because I am using the latest Visual Studio 2022 and seems to behave differently.
I have a bunch of existing C++ projects, they use plain 32-bit Windows API with DirectX 6, and I used VC++ build tools 2015 and Windows SDK 8.1 to compile it without any issues in previous versions of Visual Studio. Everything was fine in Visual Studio 2019, no special setup was needed, until I uninstalled it and installed Visual Studio 2022.
Now I can open my solutions, it nicely shows they are using C++ build tools 2015, which I installed together with VS2022, and the solutions also shows correctly that they use Windows 8.1 SDK. But Windows 8.1 SDK is not present in VS2022 installation, I installed it separately. I also tried to "repair" VS2022 installation, but that only deleted all my UI preferences, but not fixed anything in build. Also, I tried to reinstall Windows 8.1 SDK, but it said it is already OK.
When looking to Visual Studio, I can't see any place where I can set default include and lib directories, I can only list what is being used right now. VS2022 shows this list:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include
C:\Program Files\Windows Kits\10\Include\10.0.10240.0\ucrt
C:\Program Files (x86)\Windows Kits\8.1\Include\um
C:\Program Files (x86)\Windows Kits\8.1\Include\shared
C:\Program Files (x86)\Windows Kits\8.1\Include\winrt
The actual error message I receive is this:
c:\program files (x86)\windows kits\8.1\include\um\winnt.h(31): fatal error C1083: Cannot open include file: 'ctype.h': No such file or directory
So it says that winnt.h from windows kits 8.1 cannot find ctype.h. And yes, there is no ctype.h in that folder or anywhere around, I can see it only in C:\Program Files\Microsoft Visual Studio\2022\Professional\SDK\ScopeCppSDK\vc15\SDK\include\ucrt
which I think is the folder with VC++ 2015 build tools. So this seems correct, but I am wondering why this folder is not a part of default include directories when VC++ 2015 build tools are set in project settings. Because it seems that VS2022 is correctly picking my Windows 8.1 SDK, but not picking correctly the older C++ compiler.
When I try to add the folder where ctype.h resides to include folders, I receive another type of errors saying that other files are incompatible with these include files. Of course, this system of directories needs to be in sync. So please what is the correct way of using this?
Also, I tried to switch the VC++ build tools to 2022 version. Unfortunately, that also does not fix the issue. And Windows 10 SDK is not installed, the software wants to stay compatible with older Windows, so I don't need it.
I found a bug report which is related: https://developercommunity.visualstudio.com/t/windows-81-sdk-1/151682
Although Microsoft staff declined to accept it as a bug, it is happening for me as well. When I install only Windows 8.1 SDK, no project can be compiled with it. I even tried to create a new Windows API project in VS2022, the project was created, but failed to compile with the same error.
So I tried to install Windows 10 SDK (from VS2022 installed, but that is probably not important) and this added some missing files which now help to compile Windows 8.1 SDK projects. Problem seems to be solved, my old C++ code can now be compiled with Windows 8.1 SDK and both C++ build tools 2015 and 2022.

Teamcity: error MSB3147: Could not find required file 'setup.bin'

C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.target
error MSB3147: Could not find required file 'setup.bin' in ... folder
I have seen there are similar messages during the time frame of last upgrade of VS for 2012.
I did not find the registry keys on the build server as mentioned in other posts i.e. Could not find required file 'setup.bin'
I appreciate your help.
Teamcity: error MSB3147: Could not find required file 'setup.bin'
According to this blog entry the bootstrapper files are installed during the .NET Framework SDK/Visual Studio IDE install. It also shows the registry entries that are searched to look for the bootstrapper directory.
If one computer that does not have .Net Framework SDK/Visual Studio IDE installed(such as, build server), none of the registry key would be set.
I did not find the registry keys on the build server as mentioned.
You can install .Net Framework SDK/Visual Studio IDE on the build server to get this registry key. If you don not want to install them, you could manually set it up by following steps:
Copy the whole C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK folder from the local machine with Visual Studio IDE installed to the server.
creating the 14.0 registry key and adding the value:
For 86bits:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\14.0]
"Path"="C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper"
For 64 bits:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\14.0]
"Path"="C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper"
Note: Visual Studio must be restarted.
I don't have SDK installed on the server. I have updated the .csproj with
<PropertyGroup>
...
<BootstrapperEnabled>false</BootstrapperEnabled>
</PropertyGroup>
That fixed the build.

Visual Studio 12.0: missing library "msvcmrt"

I'm trying to use Visual Studio 2015 to compile a VC++ project that, however, targets the Visual Studio 2013 build tools.
I noticed that the Visual Studio 2013 (12.0) tools and libs seem to have been installed alongside VS2015, as I see the C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib directory, with all the libs. Seems fine.
But... it's not. Two lib files are be missing: msvcmrt.lib and msvcmrtd.lib, and without these I cannot compile the project.
My question is: how do I acquire these? Do I have to install VS 2013 from scratch? Or is there a more convenient package available to install? Or is my VS2015 installation damaged, and the files should have been there?
I had a similar issue and I solved it by simply copying msvcmrt*.lib from a machine with vs2013 installed.
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib
There'll be 6 files to copy (x86/arm/x64) * (debug/release)

Task could not find "AL.exe" TFS 2013

I'm using Windows 7 SP1 and Visual studio Ultimate 2013. TFS server 2013 is installed in Windows Server 2008.
Below error occurred while trying to build one solution which supports multilingual resx files:
C:\Program Files
(x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets
(3001): Task could not find "AL.exe" using the SdkToolsPath "" or the
registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v8.1A\WinSDK-NetFx40Tools-x86". Make sure the
SdkToolsPath is set and the tool exists in the correct processor
specific location under the SdkToolsPath and that the Microsoft
Windows SDK is installed
I have gone through similar questions, but those solutions didn't work. Few are given below:
Install Windows SDK
Windows SDK is already installed
al.exe is present in C:\Program Files\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
al.exe is present in \Windows\v7.0A\bin and v8.0A\bin\NETFX 4.0 Tools
Remove resx files and build
Resx files are part of the project and I want them to be in my build.
Any idea to fix this issue?
Thanks for your comments. I installed Windows SDK in server machine, where TFS is installed. It solved my problem.

Visual Studio 2005 (and other) : how to deploy debug dll (msvcp80p.dll & friends, for debugging purposes)

I am trying to run (and debug) my application on a remote computer where Visual Studio 2005 is not installed.
My current problem is that I am facing the (in)famous error : "The application failed to start because the application configuration is incorrect".
Here is what I did :
1) Install all the required vcredist on the target computer :
(I do need all theses versions since some libraries were compiled some months ago, with a previous runtime...).
Microsoft Visual C++ 2005 Redistributable Package (x86)
Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)
Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update
Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update
After installing those redist, the release version works fine.
2) Install the debug dll following the instructions given on the following MSDN pages: Preparing a Test Machine To Run a Debug Executable and at How to: Deploy using XCopy
As mentioned in "Preparing a Test Machine To Run a Debug Executable":
I did run "msiexec /i microsoft_vc80_debugcrt_x86.msm" --> This did not solve the problem.
After that, I added "msiexec /i policy_8_0_Microsoft_VC80_DebugMFC_x86.msm" --> No luck either.
As a last resort, I did "msiexec /i" for all the msm that are in C:\Program Files\Common Files\Merge Modules\*VC80*.msm --> No luck either
As mentionned is "Deploy using XCopy":
I also copied (in subfolders) all the subfolders of
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\
and
C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\
to my app dir on the target machine.
The problem is still present.
Does anyone know what I might be missing ?
Let me answer my own question : the easiest way is to add a "Setup and deployment project" to the solution.
Right click solution / Add new project : Other Project types / Setup and deployment
Right click the new deployment project and select "Add/Project Output" then select your target project
--> this will create a msi that will install all required debug dll !
(Once installed by the msi, the debug dlls are deployed once and for all : you will not need to reinstall them using an msi each time you want to test a new build).
You can use the Dependency Walker tool to find what DLL(s) you missed.

Resources