I've got an 32-bit C++ app, "MyOldApp" built with VS2005. I recently changed my dev PC from a WinXP box to a Win7/64 one. On it I installed VS2005,VS2008,VS2010 and VS2012 (in that order).
Then I found I could not launch "MyOldApp" inside VS2005 in the Debug configuation (Release works fine). Error: Unable to start program. This application has failed to start because the application configuration is correct." Windows event log says: Activation context generation failed for "MyOldApp.exe". Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis.
I check the manifest and it confirms this dependency.
So I check C:\Windows\winsxs and find this directory: x86_microsoft.vc80.debugcrt_1fc8b3b9a1e18e3b_8.0.50727.42_none_ef74ff32550b5bf0
Then I check VS2005 Help > About, find it at 8.0.50727.42 and realize I never installed SP1 which I must have been using on the XP box. So I set out to update my machine from .42 to .762 but fail. I have tried installing it from here:
Visual C++ 2005 Sp1 Runtime (x86)
and from here:
Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Update
While installing, I get and agree to the license agreement, then see the "preparing to install" dialog. Then the installer just silently exits, and I am left with version .42 and my original problem.
How do I get SP1 to install? Thanks.
Found this:
Microsoft® Visual Studio® 2005 Team Suite Service Pack 1
and it was kind enough to run to completion. Launched VS2005 and it told me to do another update, which I found here:
Visual Studio 2005 Service Pack 1 Update for Windows Vista
which also ran to completion. VS2005 Help about now shows version .762 and my app can be run in Debug Configuration.
Related
I have a VS 2015 C++ project on a remote directory that I want to share between 2 computers. On one computer it loads fine (it has Microsoft Visual Studio Community 2015 Version 14.0.25431.01 Update 3 Microsoft .NET Framework Version 4.6.01055) on the other computer it fails to load (it also has Microsoft Visual Studio Community 2015 Version 14.0.25431.01 Update 3 Microsoft .NET Framework
Version 4.6.01055). When it fails to load I get the (not very informative message)
TargetImager.vcxproj: The application which this project type is based on
was not found. Please try this link for further information
[The link is completely useless!]
I opened the project file in the solution (can't remember how I managed to do this) and it presents a number of warnings eg.
Severity Code Description Project File Line Suppression State
Warning The element 'PropertyGroup' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003' has invalid child element 'PlatformToolSet' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003'. List of possible elements expected: 'Property, VisualStudioVersion, MinimumVisualStudioVersion, AdditionalFileItemNames, AllowUnsafeBlocks, AppConfigForCompiler, ApplicationIcon, ApplicationRevision, ApplicationVersion, AppDesignerFolder, AspNetConfiguration, AssemblyKeyContainerName, AssemblyKeyProviderName, AssemblyName, AssemblyOriginatorKeyFile, AssemblyOriginatorKeyFileType, AssemblyOriginatorKeyMode, AssemblyType, AutoGenerateBindingRedirects, AutorunEnabled, BaseAddress, BootstrapperComponentsLocation, BootstrapperComponentsUrl, BootstrapperEnabled, CharacterSet, CheckForOverflowUnderflow, CLRSupport, UseDebugLibraries, CodePage, Configuration, ConfigurationName, ConfigurationOverrideFile, CreateDesktopShortcut, CreateWebPageOnPublish, CurrentSolutionConfigurationContents, DebugSecurityZoneURL, DebugSymbols, DebugType, DefaultClientScript, DefaultHTMLPageLayout, DefaultTargetSchema, DefineConstants, DefineDebug, DefineTrace, DelaySign, DisableLangXtns, DisallowUrlActivation, CodeAnalysisAdditionalOptions, CodeAnalysisApplyLogFileXsl, .... Miscellaneous Files H:\CodeProjects\QTProjects\TargetImager\TargetImager.vcxproj 20
Here is the section of the project file XML
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<PlatformToolSet>v140</PlatformToolSet>
It doesn't like this PlatformToolSet setting for instance. I don't get it because it is a setting in the property pages on VS2015 that can be selected. I anyway changed this property clicked apply then changed it back clicked apply. It is still there in the project file as before with same error message, I also changed the setting to v140_xp just to verify that it was seeing the new property which it was.
The story is that I was working on one computer with VS 2015, then I wanted to run something on another remote computer, however by then VS 2015 was replaced with VS 2017 and I installed VS 2017 on the remote. I built the project on VS2017 but then went back to the local PC with VS2015 to do some QT stuff (QT plugin is not yet available on VS2017). This was OK but then it refused to load on the remote VS2017 PC. So I uninstalled VS2017 and replaced it with VS2015, the project still doesn't load on the remote PC with VS2015.
Maybe somehow I have a VS 2017 project that for some reason loads on one computer with VS2015 and not the other, hence the settings that VS 2015 doesn't like.
So I try to create a new QT GUI project (I installed QtVsTools extension) on the remote machine that has problems with my project file. And now I get an error (the same error also occurs with a new win32 console application)
.../TarImager.vcxproj cannot be opened because its project type (.vcxproj) is not
supported by this version of the application.
To open it please use a version of the project that supports it.
As far as I know .vcxproj has been supported since MS VS 2010
Any idea how I can debug this?
The visual studio install had become corrupted, I repaired the installation then was able to create projects again. If you get weird project loading errors, then maybe your VS install is messed up.
I'm doing C++ in Visual Studio 2017, and just recently updated Windows 10 from Anniversary Update to Creator's Update.
I found out by accident that when I'm compiling a DLL project, I would get the error message:
LNK1104 - cannot open file 'kernel32.lib'
After twiddling a bit in the Project Properties, I noticed if the Windows SDK version is set from 10.0.14393.0 to 10.0.15063.0, the error message appears. If I set it back to 10.0.14393.0, I can compile just fine.
I would like to know why when the Windows SDK version is set to the Creator's Update build version, it's throwing this error message, yet it doesn't if set back to the Anniversary Update's build version?
Thanks.
https://developercommunity.visualstudio.com/content/problem/41913/link-fatal-error-lnk1104-in-empty-c-project.html
The Windows 10 Creators Update SDK made some significant changes to
what is installed as part of the installation to minimize on-disk
footprint. This is a Known Issue that results from that refactoring
work where the "desktop" components of the Creators Update SDK do not
get installed by default. The previous new project logic always
selected the latest Windows 10 SDK, assuming the desktop portions were
installed as part of that installation scenario. We are working on a
fix for a future update.
The workarounds available are as follows:
Select a version of the Windows 10 SDK that's fully installed on the system (i.e. 10.0.14393.0 or earlier) in the Project Properties
Install the 'Windows 10 SDK (10.0.15063.0) for Desktop' component via the Visual Studio Installer. win10sdk-15063desktop.png
Daniel Griffing,
Visual C++ Libraries
I have the same problem, honestly, looks like a bug in VS 2017. Just switch to 10.0.10586.0.
I couldn't imagine, just how hard it can be for me to start building a sample minifilter driver using vs 2015 and wdk 10!
I've had 2013 running on my pc, then received a swapbuffer sample configured for 8.1. I simply installed WDK 8.1 from Microsoft and that's all. it compiled.
But when I tried to build a minifilter driver using wdk10 everything got hard as hell.
everything is done as this guy said in here and I am on a virtual machine running windows 10.
after installation and that and that and repairing this and that ... when I create an empty fsfilter driver project using vs sample project, build fails with this error:
"An SDK corresponding to WDK version '8.1' was not found. Please install the SDK before building."
This error refers to the file windowsDriver.common.targets in tis line:
<Error Text="An SDK corresponding to WDK version '$(TargetPlatformVersion)' was not found. Please install the SDK before building."
Condition="'$(MatchingSdkPresent)' != 'true'" />
can somebody give me a hint on how to solve this issue?!
thanks.
Windows 10 WDK requires matching SDK version to be installed. Looks like the default for the project you created is falling back to 8.1.
In the project properties, look for Configuration Properties -> General -> "Target Platform version" drop down and select the 10.0.10XXX.0 and try to build it.
If you have installed the latest version of WDK(10.0.105860.0) then make sure the corresponding SDK is installed too. You can check this in the VS installer to see if "Tools (1.2) and Windows 10 SDK (10.0.10586)" under "Universal Windows App Development Tools" is selected.
UPDATE
After much mucking about it turns out that the WDK is not enough; you also need to install the latest Windows 10 SDK which does not by default get installed or updated with Visual Studio. I thought it did, (I've got VS2015, Update 3) but clearly it doesn't. I got the latest version from https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
, retargeted my project to the latest version (at the time of writing that is 10.0.14393.0), and both the 10 year old sample and the VS wizzard generated projects now work (at least the small sample I've tried.)
I have a fresh Windows 8.1 Pro x64 install with a fresh Visual Studio 2013 Pro.
When trying to compile a project with Platform Toolset to Windows7.1SDK I'm getting
Error 1 error MSB6006: "CL.exe" exited with code -1073741515. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.targets 57 5 MenuBrowser
I tried running the supplied "Windows SDK Configuration Tool" and besides getting an error about Visual Studio 2005 and 2008 not being installed I think it did its job.
I tried manually editing the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows
where I manually put CurrentInstallFolder as C:\Program Files\Microsoft SDKs\Windows\v7.1\ and CurrentVersion as 7.1.7600.0.30514. If I look at the project properties and click the different paths / variables in there -> more -> Macros, I can see that $(WindowsSdkDir) is correct.
Any idea as to what I should try? Never ran into this problem on the old development computer with Windows 7 and VS 2012.
L.E. as a note, if I try a new project with the v120 tools, it works, but I need the Windows7.1SDK tools.
When trying to compile a project with Platform Toolset to Windows7.1SDK...
That's not a valid selection in a "fresh" install for VS2013. Not very clear what you've been doing, it certainly isn't "fresh" anymore. Do treat Regedit.exe as a loaded weapon, the registry key set that configures VS has been getting pretty doggone convoluted as of late.
The compiler crashes with -1073741515 == 0xC0000135 == STATUS_DLL_NOT_FOUND. That's a pretty serious mishap of course, it should never occur when you target SDK 7.1 since that still uses the same compiler, only the SDK directory is changed. The compiler itself, as well as the DLLs it uses, are not part of the SDK and only are provided if the machine doesn't have VS installed. You can use SysInternals' Process Monitor to diagnose this, you'll see the CL.EXE process searching for a DLL and not finding it.
The correct way to target 7.1 is to use the v120_xp toolset selection. That builds programs that can still run on XP, it automatically also selects the 7.1A SDK that was installed on your machine. Do try to undo the changes you've made.
Referencing Yodans solution from
How to build with v90 platform toolset in VS2012 without VS2008, using Windows SDK?:
As pointed out by Hans Passant cl.exe looks for mspdb100.dll (among others) and does not find them.
The needed files are in the directory mentioned in 7. below:
My working setup:
VS2013 needs to use VS2010 libs
Using WinSDK 7.1 build tools (v100) in VS2013
clean install, uninstalling everything mentioned in the sdk release notes (can be downloaded at http://www.microsoft.com/en-us/download/details.aspx?id=8279 under category Details)
Microsoft Windows SDK for Windows 7 (7.1) (the Windows SDK core-component files)
Application Verifier
Debugging Tools for Windows
Windows Performance Toolkit
Microsoft Help Viewer 1.0
Microsoft Visual C++ 2010 Redistributable
Microsoft Visual C++ 2010 Standard Edition
Additionally removed all .NET and VC++ related MS Software (not tested if necessary)
choosing Windows7.1SDK as Platform Toolset in VS2013
error MSB6006: "CL.exe" exited with code -1073741515
cl.exe looks for one of msobj100.dll, mspdb100.dll, mspdbcore.dll and mspdbsrv.exe
Added to PATH: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
Build works and binary is usable!
A mistake I did:
copied files in 6. above to C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin, believing this directory is in PATH, but it was not!
So better do as sugested in 7. above or by Yodan in How to build with v90 platform toolset in VS2012 without VS2008, using Windows SDK?
The following steps work for me in VS 2017.
1.Close VS 2017.
2.Restart machine.
3.Open solution in VS 2017.
4.Build the project.
This time I didn't get following error and it builds successfully.
error msb6006 "link.exe" exited with code -1073741819.
I have recently acquired source code from a VS2005 project that uses the MFC library. Firstly I upgraded the project to VS2012 and I can now successfully build and run the software on Windows 8. Next, I wanted to deploy the software on a Windows XP machine.
I have set the Platform Toolset to build to Windows XP (using the v110_xp option) and I have installed the 'Visual C++ Redistributable for Visual Studio 2012 Update 1' on the target machine. When I run the software, nothing appears to happen. Via some logging functions I can determine that a call to LoadFrame(IDR_MAINFRAME) causes an exception in kernel32.dll. I can't debug any further in to LoadFrame as remote debugging on Windows XP is not available in VS2012.
Any ideas what may be going wrong? Is the Visual C++ Redistributable package the correct version to be installing on the target machine? What should I be trying next?
UPDATE
My project is already set up to use the 7.1 SDK and has minimum required version set to 5.01 in linker options.
If I use InstallShield to generate an installer and include the MFC, CRT and ATL redistributables, the installer works and my program now runs on Windows XP. My understanding of the redistributables is that they simply copy the relevant dll's in to the system32 folder (or equivalent)? Is that correct?
However, if I simply copy the files over, run the vsredist_x86.exe or use Inno Setup to install the software & dll's, my program no longer works.
I believe you have read this blog. In summary, you need to use the 7.1 SDK, and you need to set minimum required version to 5.01 in linker options.
Using the working InstallShield project and the not-working Inno project I was able to determine that the real culprit here was an unregistered msxml4.dll. The error I was receiving gave no real clue to this outcome but I got there eventually...
regsvr32 msxml4.dll