I am posting this in the hope that it will save someone else the time and effort of figuring this one out:
My current setup is VS2015 against TFS 2013.4
Problem
My old PC setup had VS2013, and I had been using the Microsoft.TeamFoundation.WorkItemTracking.Client namespace to get some Work Item information from TFS.
I recently had to rebuild my PC, and continued development of a program that gets this information.
To my dismay, I kept getting an error:
Unable to load DLL 'Microsoft.WITDataStore32.dll'
You don't need to install the TFS object model/Team Explorer anymore. You can use the NuGet package
Also with the NuGet package, you may run into the same issue that your application cannot find the native DLL.
The text below is copied from
https://connect.microsoft.com/VisualStudio/feedback/details/1695433/team-foundation-server-2015-sdk-missing-microsoft-witdatastore64-dll
Microsoft.WITDataStore*.dll is part of the ExtendedClient package, they are native dlls and cannot be referenced in managed project.
You will need to manually copy the dll into your bin folder for runtime resolution.
Microsoft.WITDataStore32.dll is in ..\Microsoft.TeamFoundationServer.ExtendedClient.14.83.1\lib\native\x86
Microsoft.WITDataStore64.dll is in ..\Microsoft.TeamFoundationServer.ExtendedClient.14.83.1\lib\native\amd64
(note these paths point to the NuGet package folder)
In the end, the following stackoverflow threads gave me the answer:
where is the tfs 2010 api dll microsoft teamfoundation framework server dll
what do i need to install to get microsoft teamfoundation workitemtracking client
The VS2015 dll's are not compatible with TFS 2013, so don't go looking for the dll's in Microsoft Visual Studio 14.0\ Common7 \ IDE !
You HAVE to install Team Explorer 2013 if you work against TFS 2013
It's small (just 130 MB), and it contains the correct DLLs.
After installation, you need to Browse... for the references here:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies
If you are getting Microsoft.WITDataStore32.dll issue while dealing with TFS/ VSTS ie. getting project name or fetching test case id in Visual Studio 2015 then you can simply redirect the Team Foundation dlls to version 12.0.0.0 from 14.0.0.0 as 14 version dlls create issue while retrieving such data and we use to get such error.
I have faced issue "Unable to load DLL 'Microsoft.WITDataStore32.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)" while running my Coded UI test script after migration from "TFS 2012 and VS2013" to "VSTS and VS2015" respectively.
The issue got resolved when i redirected the referenced 14 versions dll to 12 version in the App config as shown below:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.TeamFoundation.Common" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="14.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.TeamFoundation.TestManagement.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="14.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.TeamFoundation.WorkItemTracking.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="14.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
Regards,
Prasidh
My case was that I needed to add NuGet reference directly in the test project (my custom attribute was situated in another project and dll was not copied to the test project).
I'm posting this information w.r.t. Visual Studio 2017 in case it helps someone:
Please check whether you have 'Microsoft.WITDataStore32.dll' in the
path below:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team
Explorer
If not, please try to install team explorer for vs 2017 , download it
from this blog:
https://blogs.msdn.microsoft.com/bharry/2017/04/05/team-explorer-for-tfs-2017/
Then find Microsoft.WITDataStore32.dll in team explorer folders and
copy it to the path above.
Source: MSDN
Related
I am running into an weird issue where my build works perfectly on local machine but almost always fails on Visual Studio Team Services build agent. I say almost always the same code sometimes builds fine on VSTS build agent.
The error is that for a project in my solution, the compiler could not find System.Web.Http.dll, which is referenced in Microsoft.AspNet.WebApi.Core NuGet package. I've checked the reference and it is there. I've removed the NuGet and re-added it to fix any potential NuGet hiccup.
The exact error is this:
Error CS0234: The type or namespace name 'Http' does not exist in the namespace 'System.Web' (are you missing an assembly reference?)
The reference is in the csproj file:
<Reference Include="System.Web.Http, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\Microsoft.AspNet.Cors.5.2.3\lib\net45\System.Web.Cors.dll</HintPath>
</Reference>
The NuGet restore task from VSTS suggested that all NuGet packages were installed, but the build still failed.
I then did a diff between the command lines of the successful build and failed build, both from Visual Studio Team Services build agent and found that the failed build CoreCompile task was missing some assembly references.
CoreCompile gets the assemblies to reference from ResolveAssemblyReferences. But ResolveAssemblyReferences claims that it could not find System.Web.Http.dll.
For SearchPath "{HintPathFromItem}".
Considered "....\Microsoft.AspNet.WebApi.Core.5.2.2\lib\net45\System.Web.Http.dll", but it didn't exist.
Is there any known issue with NuGet restore from VSO? We are using NuGet 4.0.
UPDATE:
Visual Studio Team Services support came back to me. I had my own nuget.config which had the following 2 lines. This interfered with the global NuGet cache on the build agents. Once I removed these 2 lines everything went smoothly as expected.
<add key="globalPackagesFolder" value="..\nupkgs" />
<add key="PackageSaveMode" value="nuspec" />
It looks like, at some point, this reference was added manually, and the relative paths match up on your local PC.
In every valid nuget reference I've seen, those relative paths are prefixed with "packages". Try deleting the nuget package, and delete this reference, then reinstall it.
Here is the answer to the issue I ran into.
Visual Studio Team Services support came back to me. I had my own nuget.config which had the following 2 lines. This interfered with the global NuGet cache on build agents. Once I removed these 2 lines everything went smoothly as expected.
<add key="globalPackagesFolder" value="..\nupkgs" />
<add key="PackageSaveMode" value="nuspec" />
Issue
I wrote a C++ project called 'Foo' using Microsoft Visual Studio 2005 Verison 8.0.50727.762 (SP.050727-7600) on Windows XP Professional Version 2002 Service Pack 3. I built the project into Foo.exe. Then, I copied the file Foo.exe to a Windows Server 2003 Enterprise Edition Service Pack 2. When I tried to run it, it failed with this error,
C:\foo.exe
The application has failed to start because the application configuration is incorrect.
Reinstalling the application may fix the problem.
In Event Viewer > System, three events were logged.
Event ID: 32; Source: SideBySide
Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was
The referenced assembly is not installed on your system.
Event ID: 59; Source: SideBySide
Resolve Partial Assembly failed for Microsoft.VC80.CRT.
Reference error message: The referenced assembly is not installed on your system.
Event ID: 59; Source: SideBySide
Generate Activation Context failed for C:\foo\Foo.exe.
Reference error message: The referenced assembly is not installed on your system.
Installing Microsoft Visual C++ 2005 Redistributable didn't fix it
Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=3387
Installed it. The installer created a folder called C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd.
The version of this software as found from 'Add or Remove Programs' was '8.0.50727.42'.
On trying to run C:\foo\foo.exe, I got the same errors I described above.
Installing Microsoft Visual C++ 2005 SP1 Redistributable didn't fix it
Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=5638
Installed it. The installer created a folder called: C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.
The version of this software as found from 'Add or Remove Programs' was '8.0.56336'.
On trying to run C:\foo\foo.exe, I got the same errors I described above.
Copying CRT DLLs and manifest from the same machine (where I'm running the EXE) didn't fix it.
I copied msvcm80.dll, msvcp80.dll and msvcr80.dll from
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd
to C:\foo.
Next, I copied
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd.manifest
to C:\foo and renamed it to Microsoft.VC80.CRT.manifest.
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.42"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
When I tried running C:\foo\foo.exe this time, it didn't work. I repeated this thing again with the DLLs in C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 and the corresponding manifest file. It didn't help as well. I got the same error.
In both cases, I got the following errors in Event Viewer > System.
Event ID: 34; Source: SideBySide
Component identity found in manifest does not match the identity of the component requested
Event ID: 58; Source: SideBySide
Syntax error in manifest or policy file "C:\foo\Microsoft.VC80.CRT.MANIFEST" on line 4.
Event ID: 59; Source: SideBySide
Generate Activation Context failed for C:\foo\Foo.exe. Reference error message: The manifest file contains one or more syntax errors.
Copying CRT DLLs and manifest from the Windows XP machine (where I built the EXE) didn't fix it.
I copied msvcm80.dll, msvcp80.dll and msvcr80.dll from
C:\winnt\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 of Windows XP machine (where I developed and built foo.exe)
to C:\foo of Windows Server 2003 (where I am trying to run foo.exe).
Next, I copied
C:\winnt\winsxs\Manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.manifest
to C:\foo and renamed it to Microsoft.VC80.CRT.manifest.
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
On trying to run C:\foo\foo.exe now I got the same errors mentioned in the previous section.
Copying CRT DLLs and manifest from Visual Studio folder fixed it.
Copied msvcm80.dll, msvcp80.dll, msvcr80.dll and Microsoft.VC80.CRT.manifest from C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT of Windows XP machine (where I developed and built foo.exe) to C:\foo of Windows Server 2003 machine (where I am trying to run it).
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.6195"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
This time I could run C:\foo\foo.exe without any issues.
Question
I was expecting that installing 'Microsoft Visual C++ 2005 SP1 Redistributable' (vcredist_x86.exe) as described in the second approach would fix it. But it didn't. Copying the DLLs and manifest files from the C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT folder of the development machine fixed it. Why was it so?
Build options
In case, it helps you to answer my question. Here is the compiler and linker options I picked up from Visual Studio project properties:
Configuration properties > C/C++ > Command Line:
/O2 /GL /D "_MBCS" /FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt
Configuration properties > Linker > Command Line:
/OUT:"C:\MixedBag\Release\Foo.exe" /NOLOGO /MANIFEST /MANIFESTFILE:"Release\Foo.exe.intermediate.manifest" /DEBUG /PDB:"c:\MixedBag\release\Foo.pdb" /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
I'll answer my own question. Comments to the question by Hans Passant and Luke helped.
I downloaded Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update and installed it on the system where I was trying to run C:\foo\foo.exe. The EXE ran fine after this.
The installer placed the CRT DLLs in C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86. So, yes, 8.0.50727.6195 was the version of the CRT DLLs I was looking for as Hans Passant rightly said.
The easiest way to figure this version was by looking at the manifest file generated by Visual Studio while building my project on the development system. Mine was located at C:\Foo\Release\Foo.exe.intermediate.manifest. It had a tag like this:
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.6195'
processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
So, this is a clue that I needed 8.0.50727.6195 version of the DLLs. The rest was a matter of searching for the right vcredist_x86.exe which happened to be in the URL I have mentioned in the second paragraph. The page in that URL contains a link to KB2538242 which shows the version numbers of the DLLs that would be installed by the installer.
Note: As Elie has mentioned in a different answer to this question, since this is a 32-bit application, it is necessary to install vcredist_x86.exe (not vcredist_x64.exe) on the system where this application is supposed to be run irrespective of whether that system is a 32-bit Windows system or a 64-bit Windows system. Once again, the .manifest file provides this clue in the processorArchitecture attribute.
You have to install "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update" which is here: http://www.microsoft.com/en-us/download/details.aspx?id=26347
Here is how you fix this issue:
You WILL STILL Get the sidebyside errors If the application being used is 32 bit and you try running it on a 64 bit OS which has the VC_REDISTx64 installed.
Simple solution, you MUST ALSO LOAD THE VC_REDISTx86 on the 64 bit os
I had a somewhat related problem. Two development XP machines with VS2005 installed, call them A and B. I developed, built and ran on A. Then I copied the whole project to B. Built there. Tried to run and got the same error messages mentioned by SusamPal. I realized that on B's WinSxS there were the x86_Microsoft.VC80.CRT_xxx manifests (and folders) but not the corresponding x86_Microsoft.VC80.DebugCRT_xxx ones (and why?!). I tried several of the dances and incantations described by SusamPal to no avail. I solved the problem by copying the appropriate folders from the WinSxS of A to B AND the appropriate manifests from the WinSxs\Manifests.
Although my application was
developed on Win 2k8 R2 x64 with vs2008 (which has msvcm90.dll, msvcp90.dll and msvcr90.dll in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT)
and ran on win 2k3 SP2 x64,
but the msvcm80.dll, msvcp80.dll and msvcr80.dll are needed.
After install Microsoft Visual C++ 2005 SP1 Redistributable Package (x86), the application can be installed and ran rightly.
For me the side by side error went just by chabging the under the setting c/c++ ->CodeGeneration->RuntimeLibrary ,make it MTD that is multi-Thread Debug
We have really following problem here: the application executable references dlls using manifest machinery. In the deep past application authors just copied required dll's into system directories. Unfortunately this caused so called "dll hell" problem when overwriting older dll versions by incompatible newer one could make applications stop working. MS then came up with with versioning idea (winsxs).
Unfortunately this is quite complex machinery and it is definitely not a good idea to try manually installing dlls (assemblies) into the sxs folder. Installing so called "redistributable packages" is not a perfect solution either.
Additionally, this cannot help when we want debug versions. As MS prohibits distribution of debug versions of supporting dlls, "redistributable packages" won't install them. (Note that the assembly id depends on current subversion of VS2005 and is related to installed supporting libraries.)
Usually, the VS installer adds the required assemblies to the system, but after some time installation of updates or newer SDK's and tools may damage this correct state.
Let's assume we have this situation - our debug libraries are no longer integrated into system. Suppose we have given workspace with project A and active debug configuration giving not working application. We can then create installer project, say C in current workspace, add our application (or strictly, project with active configuration) to it. Setup installer project to put our executable in some place (desktop is the right place regarding this situation) enable dependencies check and some other minor properties. Then build project C and run installer (or "install" from VS using context menu). Now your application and other created with debug dll libraries start to work.
Beware when you run installer with "remove" option you came to previous situation. Here is good article related to distribution topic: http://blogs.msdn.com/b/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx.
If you have some other applications and want to deploy them simply by copying, maybe on non development machine without installed VS, you may create dummy project together with appropriate configuration and installer for it . You then install it once on each machine and then copy executable(s) you are working on.
I recently reformated which led me to install MSVC 2010. Everything seemed okay, except this time around I had Windows x64. I went ahead and rebuilt all of the dependencies for my project as x32 as some of them have issues with x64, but I am having this error message popup before my application even starts as debug build (it crashes immediately in release)
"This application has failed to start because its side-by-side configuration is incorrect."
I believe this is caused due to either my main project being written in MSVC9 and converted to MSVC2010 and/or my GUI library (CEGUI) doing the same thing.
Here is what my manifest looks like for my project...
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
I don't know how to fix this, so any help would be great, thank you.
Yup - this is because your project manifest is specifying the VC90 CRT, and you've build and linked your application with the VC10 import libraries.
I'd fix this by creating a dummy VC2010 C++ project that uses the DLL version of the CRT, and copy the CRT section(s) from it's manifest to your project manifest.
We are currently taking VS2010 for a testdrive and so far we are a little stumped with how it just won't cooperate with our existing Team Foundation Server 2008.
We still have all our projects on .NET 3.5 and whenever we are now building a solution that contains a unit test project (which automatically builds in .NET 4.0) the TFS won't build it.
The .NET 4.0 framework is installed on the TFS 2008.
The error we're receiving is:
[Any CPU/Release] c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(0,0): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
As a temporary workaround we are now forced to remove all our test projects in order for our solutions to build.
You need to install VS2010 on your build machine.
I'v just been trying to build V4.0 solutions on TFS2008, and altered the C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\tfsbuildservice.exe.config file:
<add key="MSBuildPath" value="" />
to
<add key="MSBuildPath" value="c:\Windows\Microsoft.NET\Framework\v4.0.30319\" />
The build of v3.5 and v4.0 solutions did succeed. But the unittest of the v3.5 solutions did not work.
Read about installing VS2010 on the build server, but read somewhere else: ( http://www.richard-banks.org/2009/11/how-to-build-vs2010-solutions-using.html ) that it is possible without installing VS2010.
: Text from that website:
This worked for us allowing a TFS 2008 build agent compile VS 2010 solution/project files without installing VS 2010:
Install .NET Framework 4.0 and .NET Framework 3.51 SP1 (for some reason, SP1 wasn't included with 4.0?)
Install Windows SDK 7.0A. When I'm writing this the SDK is still not released so we had to:
From a computer with VS 2010 installed, copy the SDK folder from %programfiles%\Microsoft SDKs\Windows\v7.0A and registry settings from HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\7.0A to the build machine.
Copy %programfiles%\MSBuild\Microsoft\VisualStudio\v10.0 to the build machine
Change ToolsVersion from 3.5 to 4.0 in your TFSbuild.proj file.
I think that was all. There was no need to change the build agent's configuration file.
Hopefully this will work.
Install "Agents for Visual Studio 2012"
http://www.microsoft.com/en-us/download/details.aspx?id=38186
I found MSVCR90D.dll not found in debug mode with Visual C++ 2008 question but none of given answers really gives answer to the question. Most of them point to turning off incremental linking but don't explain the true cause of the error and how it can be fixed without turning off incremental linking.
I'd like to mention that my situation is a little different than the one in the original question. I am using C++ compiler from Visual Studio 2008 but within Qt Creator not within Visual Studio.
Anyone?
Simply installing VS2008 Service Pack 1 will fix the problem, if it's an error where the Debug CRT is totally missing from the sxs folder.
I had this happen to me with a fresh install of VS2008 on 64 bit Windows 7 and a solution containing a VC++ project. The debug build would crash when the C++ assembly was loaded at runtime, with a side-by-side error.
On Vista and Win7 (but not XP) the SxS error gives details about exactly what assembly it tried and failed to load - in this case it was VC90.DebugCRT 9.0.22.19. I checked the (embedded) manifest for the VC assembly and sure enough, it included a reference to this assembly and version.
Checking the sxs directory (%System Drive%\Windows\WinSxS) showed that there was no VC90 DebugCRT installed in side-by-side at all! I had installed the VC++ runtimes, but these don't include a debug runtime. VS2008 is meant to install a debug runtime, but it wasn't there.
Turns out the original release of VS2008 doesn't install a 64 bit VC++ DebugCRT, but installing SP1 does. Once I'd done this, no more runtime exceptions and side-by-side errors.
You could use Dependency Walker to find out what version of msvcr90d.dll you program tries to find. May be some 3rd-party component linked to some version of msvcr90d.dll which you don't have.
You should check manifest.xml file. Try to remove all unnecessary dependencies.
Below is output from compiler. It's strange that running build the second time succeeds. However I suspect the problem might be due to this error with running mt.exe which is responsible for embedding information from manifest into executable...
Generating Code...
link /LIBPATH:"c:\Qt\4.5.2-vc\lib" /NOLOGO /DEBUG /MANIFEST /MANIFESTFILE:"debug\formExtractor.intermediate.manifest" /SUBSYSTEM:WINDOWS "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /OUT:debug\formExtractor.exe #.\nmD932.tmp
mt.exe -nologo -manifest "debug\formExtractor.intermediate.manifest" -outputresource:debug\formExtractor.exe;1
'mt.exe' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'mt.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Exited with code 2.
UPDATE
Failing to run mt.exe during the linking process was indeed the cause of the problem. I added path to Windows SDK (C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin) to the PATH environment variable and I'm able to run executable now.
Comments to various answers;
#Shay
Output txt file from sxstrace is empty. Have no idea why. However there's the following information in the application log:
Faulting application formExtractor.exe, version 0.0.0.0, time stamp 0x4a638ee1, faulting module MSVCR90D.dll, version 6.0.6002.18005, time stamp 0x49e03824, exception code 0xc0000135, fault offset 0x0006f04e, process id 0xf68, application start time 0x01ca08ba801ac5cf.
Version 6.0.6002.18005?
What the heck is this?
#Kirill V. Lyadvinsky
Dependency Walker finds msvcr90d.dll used by qtwebkit4.dll file in
c:\windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\MSVCR90D.DLL
but doesn't find (the other version of?) msvcr90d.dll file linked directly by the executable. However DW doesn't seem to show it's version anywhere, does it?
Contest of formExtractor.intermediate.manifest file
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*' />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
From the manifest file it looks like the executable is being linked to a different version of msvcr90d.dll than the qtwebkit4.dll. What's strange is the fact that both versions of msvcr90d.dll are present in c:\windows\winsxs folder in the following sub folders
x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.21022.8_none_96748342450f6aa2
and
x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb
Any ideas?
#knight666
I'm using Qt framework which I compiled using exactly the compiler I'm using now so I think there's no mismatch here. Additionally Dependency Walker shows the missing msvcr90d.dll file is linked directly to the executable so it's not a fault of any 3rd party library I think.
Disclaimer: I'm no real a Win32 master :)
I never used Qt Creator, but does it create a proper manifest for the exe?
maybe the manifest is for a different version (SP1 for example) and you have only the RTM version.
Are you using Vista? you can try to run SxsTrace to diagnose side by side issues.
update: in my case, i found that vc++ 2008 express has a 'Use FAT32 Work-around' (found in the configuration properties' "manifest tool" page); this resolves the problem. The help info for this option explains that FAT32 drives/partitions has a 2-second latency in the time stamp that prevents mt.exe from working properly. This seems to explain the somewhat random behavior of the problem.
Is it possible you have a version mis-match? I had a similar thing with Ogre, I had to recompile the SDK using the latest version of the third party library for it to compile.
i have the same problem with msvcr90d.dll not found in vs2008 c++ express ed.
The embedded manifest in the output .exe looks like this, when incremental link is enabled:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
</assembly>
No wonder msvcr90d.dll could not be found!
i tried 2 things:
A. using a hex editor, the above is overwritten with the <assembly> contents found in ./Debug/XXX.embed.manifest
B. use mt.exe -manifest ./Debug/XXX.embed.manifest -outputresource:./Debug/XXX.exe
Both methods seem to work. i used the 2nd method as a post-build event command:
mt.exe -verbose -manifest ./$(ConfigurationName)/$(TargetFileName).embed.manifest -outputresource:./$(ConfigurationName)/$(TargetFileName)
i don't know why the 'wrong' manifest is embedded in the 1st place when incremental link is enabled. if anyone knows why, please post.
Thanks!
lex