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.
Related
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
I have ported a project from Win32 to x64 platform. I changed all dependencies so I can build the project smoothly. However, as soon I start the executable I'm getting an error (0xc000007b).
Using the dependency walker I can see, that at a certain point the ComCTL32.dll is loaded but the x86 and not the x64 as expected.
As soon I turn of the manifest generation (linker->Manifestfile), it works. But that's not a solution.
So my question is: Where in Visual Studio 2010 can I set the path to the correct DLL ComCtl32.dll.
Well, the manifest matters. An example of a bad one that could cause this problem would look like this:
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
The processerArchitecture attribute value matters. A good one uses *, which means compatible or amd64, which means 64-bit.
You don't set the path anywhere. You specify a manifest to indicate which version of ComCtrl you want, and then it is up to the OS to find it, like any other DLL. The error you are seeing means a 64bit process is trying to load a 32bit DLL, or vice versa. That could be a search path issue, that could be a dependancy issue. Use a tool like DependancyWalker to find the culprit.
I have a C++/CLI project that was created in VS2005. I'm hoping to run this in VS2010 (or 2012) as that is my main IDE and I need to modify some things in the C++/CLI project as well and its irritating to have to switch back and forth to vs2005 to recompile, copy etc.
The other important reason is my projects running in VS2010/2012 are in .NET4 so there is no option to move everything on to VS2005.
The project has dependencies on unmanaged third party libraries that themselves have dependencies on the debug versions of the c++ redistributable libraries (msvcr80.dll, msvcm80.dll, msvcp80.dll)
When I first ran the upgraded project I received 'specified module could not be found' -
It was then I noticed the cli project is being compiled against the later versions of msvc (msvcr90.dll)
cli assembly dependencies as per depends; vs2005 on left vs 2008 on right
Is there any way to make a later version of VS compile using the 2005 libraries?
update its not vital which one it compiles against (and may not be possible anyway) but is it possible to run and debug both side by side?
When I try to run the compiled project I get this error message:
I've tried copying the manifest file from the vs2005 project to the vs2010 project but this does not work (same error message). I also disabled the embedded manifest and replaced the generated .manifest file with the one from vs2005 and this does not work either.
update2 I've got past this error by specifying the msvcr libraries in the manifest:
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
however now when I run my application one of the third party libraries throws an AccessViolationException - Attempted to read or write protected memory when I try to use one of the methods. This code otherwise works fine in vs2005.
I have since discovered Daffodil for Visual Studio which does exactly what I need, namely compile against vc80 in visual studio 2010. After installation the Platform Toolset dropdown gets a few more options:
nb, you still need to have the relevant version of Visual Studio installed, eg if targeting vc80 you need vs2005.
nb2, Intellisense is broken in vs2010 for cli/c++ which is a major letdown after the amount of time researching getting the project to work on vs2010
From http://www.davidlenihan.com/2007/07/winsxs.html
"So how does an application know what version of a DLL it needs to load? That is where a "manifest" comes into play. A manifest is an XML file that contains information used to create the directory in C:\Windows\winsxs so that a particular DLL can be loaded."
Have you considered making a manifest for the application? I mean, the error message says that the problem is that the manifest is lacking, so perhaps it will be sufficient to create a manifest (either through the project settings) or adding a hand written one?
See: Problem loading RT without Manifest
I've developed a 64 bit dll using C++ and Visual Studio 2008 and i'm trying to register it on a target machine using 'regsvr32.exe'. I've checked the manifest file and it clearly states what version of CRT is needed:
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='amd64' publicKeyToken='1fc8b3b9a1e18e3b' />
When i try to register the file i always get a side-by-side error message stating that the application settings are incorrect and that i should reinstall it.
Log Error: Generate Activation Context
failed... Reference error message: The
referenced assembly is not installed
on your system.
The target machine runs Windows Xp Professional 64 bit. I've tried to install the corresponding VC++ redistributable package( VC++ 2008 Redist x86 and x64 ), create a setup and include the corresponding merge module ( microsoft_vc90_crt_x86_x64.msm ), install all VC++ redistributable packages etc. No matter what's installed it will always fail.
If i check for the dependent files and they are correctly located inside the WinSxS folder, but if i run Dependency Walker on the file it will complain too that the files from the VC9 CRT could not be found.
If i build the file for 32 bit it will correctly register on a 32 bit OS. I'm running out of ideas so any help is very appreciated.
Thanks,
Adrian.
EDIT *This is reproductible only on Win XP 64, all works fine on Windows 7 64 bit.
I'm no expert in installers but have you thought about distributing the redistributable's in the root folder of your application?
As for me, I've never heard of using regsvr32.exe to install crt redist's.
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' ...
shouldn't it be
<assemblyIdentity type='win64' name='Microsoft.VC90.CRT' ...
?
You need the 64-bit runtime
It sounds like despite the app is 64 bit it's looking for the 32bit crt dlls. Did you try to install the 32bit redistributable package?
Here is a good description on how to track down SideBySide failures:
http://blogs.msdn.com/b/junfeng/archive/2006/04/14/576314.aspx
In the end I've managed to fix this by including a newer version of C++ redistributable merge modules into the setup along with all the required policy merge modules in order to redirect the calls to any old version to the new one that's available.
Most important thing here is that the exe redistributable include the policy files and the merge modules don't so they need to be separately added.
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