Alright, after doing a ton of research and trying almost every managed CPP Redist I can find as well as trying to copy my DLLs locally to the executing directory of the app I cannot figure out what dependencies i'm missing for this mixed mode library.
Basically I have a large C# application and I'm trying to use a mixed mode library I made. On the development machine it works perfect (of course) but deployed when the library needs to be loaded for use it exceptions out because of missing CRT dependencies (I assume).
I have used dependency walker to check all the DLLs referenced and ensured they exist on the deployment machine with no luck, I'm wondering if maybe it's some dependencies that need to be registered that I am missing, but i can't figure out what.
I get the following exception when code tries to instantiate a class from the mixed mode library.
Exception Detail:
System.IO.FileLoadException: Could not
load file or assembly 'USADSI.MAPI,
Version=1.0.3174.25238,
Culture=neutral, PublicKeyToken=null'
or one of its dependencies. This
application has failed to start
because the application configuration
is incorrect. Reinstalling the
application may fix this problem.
(Exception from HRESULT: 0x800736B1)
I am compiling the library using VS2008 SP1 with /clr:oldSyntax specified.
The intermediate manifest looks like this:
<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.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
I can provide any more information as needed, unfortunately i'm not well versed in making mixed mode libraries so this has thrown me off.
If anyone can offer any advice I would greatly appreciate it!
Did you deploy the CRT libraries on the target machine? Long shot: since you have a dependency on 32-bit code, you should set Target Platform in the Build property tab to x86.
EDIT: trouble-shoot side-by-side resolving problems with the Sxstrace.exe utility, available on Vista.
Typically I've found that the pragma comment style manifest decleration's to be much more error free, from a developer maintenence and an over all build action perspective. The XML manifest's are natoriously snafu.
The fimiluarity with how the linker operates and the usual compilation of C code and the fact that you simply tak this in, onto one of your source files, keeps everything a bit feeling more "together";
#pragma comment(linker, \
"\"/manifestdependency:type='Win32' "\
"name='Microsoft.Windows.Common-Controls' "\
"version='6.0.0.0' "\
"processorArchitecture='*' "\
"publicKeyToken='6595b64144ccf1df' "\
"language='*'\"")
I had a similar problem the first time I deployed a VS 2005 app on a target machine -- had to bring over the MSVCRT80 DLL. Are you saying you already have the 2008 VS runtime library there?
ETA: Also, dumb question, but are you sure you have both the CRT Runtime (linked to above) and the .NET Runtime, with the same version you compiled against (probably 3.5)? You probably already know this (especially considering your score) but they're 2 different things.
I found a solution that seems to work although I don't like it very much.
I had to copy the folders:
Microsoft.VC90.CRT & Microsoft.VC90.MFC
From: Program Files\Microsoft Visual Studio 9.0\VC\redist\x86
Into the deployed application directory, I just can't figure out why this seems to work and the redistributables did nothing.
EDIT: Looking at the manifest I probably don't need to copy the MFC directory
Best way to solve this problem is to download process monitor which is free from:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Add a filter to watch only your process and it will show you all file access the process tries. This will show you exactly which dll it can't find.
I always use this when faced with the same problem - if only microsoft filled in the filename in the thrown exception it would all be easier.
Related
I have an issue with these two famous warnings which are raised during compilation of our solution. There are many forums about these already and I read those, but they still don't solve my issue completely...
1. There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "XXX", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
2. Referenced assembly 'XXX' targets a different processor than the application.
The reason why these appear in our case is clear. Our solution is compiled as AnyCPU and we want to keep it this way, as we do not want to compile it twice (once as x86 and second as x64). However, we use external DLL which is either x86 or x64 (it is not delivered as AnyCPU).
We develop the application on 64bit windows, so we use the x64 DLL version as reference in the visual studio during development. When we deliver the application to end-users, the installer is customized to copy the proper DLL based on the platform of the target system, e.g. when it is installed on 64bit windows, it copies the x64 DLL version and when it is installed on 32bit windows, it copies the x86 DLL version. Therefore, we know that everything is finally ok, and we can ignore those messages. And therefore, I just want to make them disappear:-)
The first warning can be supressed by the following tag in the project file:
<PropertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
But I did not find anywhere how to get rid of the other message? Is this possible as well?
I know that this is just small issue and I can live with that. However, there is something like "Warning Free Build Initiative" going on in my company, so I'd like to get rid of all warnings we have.
Thank you in advance for any hints,
Tomas
I'm trying to profile a C++ project in Embarcadero RAD Studio 2010. To do this I wanted to use AQTime, but I'm running into a bit of a problem.
I can compile and run the application in release mode. But when I compile in debug mode, using the settings mentioned at http://smartbear.com/support/viewarticle/18053/, I get an access violation.
... faulted with message: 'access
violation at 0x062324bd: read of
address 0x62324bd'. Process stopped.
Use Step or Run to continue.
It seems to come when I load a bunch of dll's at the startup. But since it goes well in release mode I can't seem to figure out what could be the cause.
When the access violation occurs I get thrown out into assembly and that isn't one of the languages I'm fluent in ;)
EDIT : When scanning the .exe with Dependency Walker I get a message saying that the following files can't be found
CC32100MT.DLL
INET140.BPL
RTL140.BPL
VCL140.BPL
IESHIMS.DLL
Could this be the problem somehow? Are these debugspecific or is Dependency Walker not giving me correct information? The same files are said to be missing when I try a release compiled version to.
I'm running on Windows 7 x64, if that could be part of the issue. I have had problems before with the symlink-look-alike (user/AppData/Local...) that MS used for some folders. Notably when I ran an apache server and the htdocs folder actually wasn't located where the server thought it was (and where it appeared to be) :)
Have you tried disabling dynamic rtl which can be found in the C++ builder linker options pane?
I am building an application using Microsoft Visual C++ 2005. After a major update of libraries, I am getting the following entry in my manifest file:
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
However, when I look use the Dependency Walker on the resulting executable, I don't see MSVC80D.DLL in the list at all, which is a bit surprising to me.
I've also tried setting the linker to "verbose" mode, to see if it would tell me where the dependency indicated in the manifest is coming from. Alas, the information there doesn't shed any light on the problem.
I've also gone through all the libraries I'm linking to see if any of them use the debug CRT. As near as I can tell, none of them do.
How can I determine what library is causing this issue? When I distribute the executable as it is, I get a side-by-side error, presumably because of this entry in the auto-generated manifest.
Thanks so much for any help you can offer... After a few days of trying to figure out what's going on, I'm starting to get really frustrated with the problem.
I think I've found the solution to my problem. I decided to build a small test app, then add the libraries I'm using one at a time. Using this method, I isolated one library in particular that seemed to be causing the problem. I'm certain the library didn't show debug dependencies using dumpbin, but, on the other hand, I have been able to eliminate the unwanted manifest line by rebuilding that library.
I have a simple .exe written in C++ (built with Visual Studio 2005) that tests some hardware using a supplied API. It works fine on the Windows 7 machine I built it on, but when I copy it to another (Windows 7) machine and run it (from the command-line) I get:
The application has failed to start
because its side-by-side configuration
is incorrect. Please see the
application event log or use the
command-line sxstrace.exe tool for
more detail.
What is "side-by-side configuration"?
I ran sxstrace.exe and read the usage info. It appears I would need to instrument my exe to generate a log file for sxstrace.exe to be useful?
I imagine the problem is my exe requires DLLs that either don't exist on the other machine, or are the wrong version. How do I find out what DLLs my exe uses, and what versions it links to on my machine (where it works)? Any other advice on copying it to another machine and getting it running? Would more information help?
mfawzymkh's answer to the "application has failed to start because the side by side configauration is incorrect" question (linked to in the question spirulence linked to in his answer to this question) appears to apply to this question also. mfawzymkh writes:
You can resolve this issue by either
one of these 1- Install VC8 Debug CRT
2- Build you app as statically linked
And mfawzymkh's comment on that same answer explains how to build as statically linked:
when you build it in VS, go to
projects->settings->C/C++->Code
Generation and choose Runtime Lib
options to be /MTd instead of /MDd
I did that and the side-by-side configuration message is gone. (And after installing something else for the DLL I was using, my EXE works.)
For what it's worth, I encountered the same issue. In the Event Viewer I had an error message that read:
Activation context generation failed for "C:\\MyExe.exe".Error in manifest or policy file "C:\\MyExe.exe.Config" on line 12. Invalid Xml syntax.
Sure enough, I'd changed a connection string and left out the closing quote. Added that back in and it solved the issue.
"when you build it in VS, go to projects->settings->C/C++->Code Generation and choose Runtime Lib options to be /MTd instead of /MDd" worked for me, although I was interested in the Release version instead of the Debug version.
Microsofto says:
/MT Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.
/MD
Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR100.DLL, which must be available at run time to applications linked with MSVCRT.lib.
Are you suffering from the same issue as this guy? Side-by-side assemblies, Windows 7, and Visual Studio 2005
I need to add a dependency on a specific version of GDIPlus. This is the version of GDI+ that i want:
I want to be sure that I'm using this version for a specific compatibility reason.
I've added an assembly manifest to my executable, defining my dependancy on the version of GdiPlus:
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32" name="Microsoft.Windows.GdiPlus"
pubicKeyToken="6595b64144ccf1df"
version="5.1.3102.2180" processorArchitecture="x86"
language="*" />
</dependentAssembly>
</dependency>
Except when I run my application, Windows' fusion loader gives me some other version of gdiplus.dll from the Side-by-Side folder, which I can see in Process Explorer:
It's giving me version 5.02.6002.18005, rather than 5.1.3102.2180.
So the question is: How do I take a dependency on a specific version of a Windows dll?
Your "problem", such that it is, is that there is a policy file installed that specifies that requests for 5.1.3102.2180 can be redirected to 5.02.6002.18005
This is, usually, a good thing. it lets applications specify the version they were built against in their manifest, but when critical security fixes are introduced, the OS can redirect apps to compatible versions.
So, whats going to happen here is, your app is going to link against GDI+ 5.1 on any PC that has only 5.1 installed. but any PCs with the 5.2 GDI+, you will be redirected to that.
If you do have an honest to goodness reason why you want to use 5.1, even when 5.2 is available... I think you can use an application config file to manage that.
Create a file called, yourapp.exe.config - if the module in your app thats importing GDI+ is a dll, then it would be thedll.dll.2.config
I am unsure how to structure the bindingRedirect however. i.e. given the policy files redirection, im not sure if you need to redirect the old version back to itself, or the new version back to the old version. or what. some trial and error might be required.
The data in the .config file looks almost exactly like the data in the manifest file. Something like this (which mimics almost exactly the contents of the policy file installed in winsxs thats doing the redirection you dont want).
<configuration>
<windows>
<assemblyBinding xmlns=...>
<dependentAssembly name="GdiPlus...>
<bindingRedirect oldVersion="5.1.x.x" newVersion="5.1.x.x"/>
To make the choice of "oldVersion" easier, it supports a range syntax. so
oldVersion="5.0.0.0-5.3.0.0"
would be a simple way to ensure that a whole range of GdiPlus versions get redirected to a specific version.