I have developed an application for Windows CE (Bar Code Scanner Zebra MK500), I make a .cab installer and the installation was correct, but when I try to launch the app, I get this error.:
cannot find 'project' (or one of its components). Make sure the path and filename are correct and that all the required libraries are available.
NOTE: All the dll's are on the installer.
Could be any number of things, but the short of it is that the loader is unable to resolve a DLL that matches both the name and processor you're using.
Check to ensure that all of your directly referenced DLLs exist and they are built for the same processor (since you're using a Zebra scanner, all DLLs must be built for ARM).
Check to ensure indirectly referenced (so DLLs referenced by DLLs you reference) DLLs also exist (like frameworks).
Verify things like runtimes, SQL Server CE native bits - those are the common ones.
Related
Version 19.108
I'm getting this error when trying to install two customization projects. One project is extending a custom page in the other project. There are a few DLL's in play that are being referenced to call web API's. When I Google this error, I get hits for modifying the web.config but, I'm trying to install this in the cloud - acumatica.com
I've tried building all DLLs in x64 but, no dice.
I've got no problems on my local machine. This is only happening on a cloud install.
Any ideas?
TIA!
You might be mixing code that targets different platform (Mixed Platforms). Publishing one customization after the other can help (try both order). When publishing both at the same time it's possible that Any CPU chooses a default platform which isn't compatible with an assembly in the other customization.
Ideally all assemblies (DLL) included in the Files section of your customization project should target the same platform. It is preferred to choose Any CPU platform. Otherwise having only 64 bit assembly could work. If using third party libraries make sure you included the Any CPU version (preferred) or 64 bit version but not the 32 bit version.
You can change platform in the Configuration Manager in Visual Studio:
Reference: https://learn.microsoft.com/en-us/visualstudio/ide/how-to-configure-projects-to-target-platforms?view=vs-2019
I have a software that is coded in C#. It depends on two(!) third party dll which require Visual C++ 2008 and Visual C++ 2005 redistribute. Originally the installer was built in InnoSetup with all "vs200x_sp1_vcredist_x??.exe" embedded and run on install time. However since it lacks of some advanced features we decided to migrate to Wix Toolset.
The problem is, MSI was running in a more restricted environment, so I didn't figure out what is the best way to require those redistributable file being executed properly. I was tried to use merge modules instead but it didn't work - I can see that the files were installed but dependency walker shows that dll is still not link to the right version.
I think that WinSxS makes things worse at least in this case, since the software keep failing with some error message regarding "Windows Side by Side configiration (14001)" when I use the merge module approach.
So the question is:
Are there any way to build a MSI that runs a exe that install some prerequisites? I wouldn't mind those prerequisites being downloaded or just embedded.
I know that WinSxS information is stored in the manifest of the dll. So if I was permitted to remove the manifest information by the third party company, and use dynamic dll loading instead the problem could be resolved. However is this legitimate? Since I will then need to embedded the Microsoft dlls directally in the msi.
I have noticed one of the dll's manifest says its required version is "9.0.21022.8" but the one in my MSM file is "9.0.30729.6161". Is this the issue? If so can I resolve the issue by I modifying the manifest to allow the right version? I don't think this will cause the dll not working, anyway.
The msi file should install only your software. If you need to install pre-requisites, you should use a bootstrapper for it. Bootstrapper's responsibility is to install pre-requisites and it's not a task of your msi.
If you see that wix bootstrapper is complex you can try on a simple bootstrapper like the dotnet installer bootstraper. you can download it from
http://dblock.github.io/dotnetinstaller/
My Unmanaged VC++ MFC (No .NET used, No CLR support, Use MFC in shared DLL) application trying to deploy with visual C++ runtime files as private assemblies.
It is properly running on windows 7 fresh installed computer.
But I gives “This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.” error in fresh installed wondows XP sp3 computer.
I checked in application event logs. But there also no more details, just showing the same error.
Then I read these threads and surf around the internet.
Thread - 1
Thread - 2
Article -1
But couldn't find any solution clue or trouble shooting method. so here looking for some assist.
The easiest way to test is to install depends on the computer. Most likely, your application is built to use a later version of C++ runtime libraries, e.g. <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.4053' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />, but on the XP system it is an older version.
You would need to check what version of the runtime library used by analysing the program's manifest. Then check what depends is showing.
If the required version of runtime is missing, distribute it with the program's install.
On the side note, you could consider switching to the static link. The size of the binaries will be bigger, but these type of problems will be gone
Not sure if anyone else is having this issue.
I am attempting to create a windows forms library control. I need the control to run in an x86 environment. So, the first thing I do is go into the properties of the project and switch the platform target to x86.
I try running the application and I get the lovely error message referencing the assembly I am trying to create and stating: An attempt was made to load a program with an incorrect format.
I have not added any references nor any code, just trying to create a control in x86.
I am using a windows 7 64bit machine with VS2012 trying to write the app in .NET 4.5. I have to do the project in x86 because I am using some OCX that are x86 only.
Has anyone run into this?
go into the properties of the project and switch the platform target to x86
Well, that worked. Instead of a confusing COM exception (typically "Class not registered" which has several possible reasons) you get an early .NET exception that tells you that you are using the library wrong.
To test your library project, you needed to create an EXE project that had a reference to the library project. What you forgot to do is change the Platform target setting on that EXE project. Which matters because only the EXE project can determine what the bitness for the process will be. It is the one that loads first, a library project has no say. It can only veto the choice, the BadImageFormatException is that veto.
So you have to change the Platform target setting for the EXE project to x86 as well.
If I built my app against D3DX June2007_d3dx9_34 and the target system has a newer version Nov2007_d3dx9_36 should that be a problem?
I distribute D3DX DLLs using MS' redist-installer tool but I noticed one one 'clean' PC (no D3DX previously installed) I got an error about missing D3DX DLL. Before trying to figure out if the installer itself is not working, I wondered if maybe supplying a too-new version of the DLL is the problem - will the app be looking for a DLL with the exact name?
D3DX libraries are not backwards-compatible, and the API may change between versions. So the target system must have the same version of D3DX that you build your application with - a newer version won't work.
If you use Dependency Walker on your application, it should show you that there's a dependency on a DLL with the exact version number.
The redistributable in the DirectX SDK includes the whole history of the D3DX dlls. Installing the latest version of the DirectX redistributable should have your system end up with every version of these dlls. It is possible and allowed for applications to only install the files they need by deleting cab files out of the redistributable's directory structure, in order to reduce the size of the redistributable components, and this is how you can end up with having 43 of the dll but not 37 for instance.
If you remove the dependency of D3DX and D3DCOMPILER dll's from your application you can ensure the application will work as the d3d9 d3d10 and d3d11 core dlls are version-agnostic and are also tied to the windows service pack releases (i.e. D3D11 for Vista comes from Vista SP2 or Win7 stock installs for example).
Another possible way to remove the dependency and let the app startup is to make the dll a delay load module, so it is only loaded when needed (such as compiling shaders on a development environment). As long as you are sure the shaders exist on end-user machines properly it won't need to compile shaders and won't crash. Calling LoadLibrary and invoking the functions manually would be a safer choice with a way better error message of your choosing, but is a lot more work.