I created two new C++ projects using VS2010, one is DLL and one is console app. I flagged the class in DLL for export and the console app reference the DLL project. Very simple things and it works.
But, when I changed the DLL toolset to v90 (VS2008 installed), I am getting Access violation reading location error.
It seems to me, the two C++ projects must be compiled by the same toolset v100 which both targets .NET4.0. If there is a mismatch between the two, it causes access violation error.
Does anyone know how to resolve this? I could move the source code from DLL project into the console app project, but, that's rather ugly.
Is this a limitation of lower version of .NET? Maybe higher version of .NET has better backward compatibility on C++ dlls?
Thank you
Related
I was super excited to see that the latest previews of .NET Core 3.1 and Visual Studio 2019 add support for managed C++/CLI projects, as such a project is the only think keeping a particular project on .NET Framework.
So, I installed Visual Studio Preview 16.4.0 Preview 4, along with the "C++/CLI support for v142..." options, and as expected I see the new C++ CLR templates and have .NET Core 3.1 preview 2 installed
I created a new project using the "CLR Class Library (.NET Core)" template, copied the files an old managed C++/CLI project, tweaked a little, and the assembly built - great!
However, when I try to use the assembly in a .NET Core 3.1, I get this fatal exception:
Unhandled exception. System.BadImageFormatException: Could not load file or assembly 'MyAssembly, Version=2019.0.1.0, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
File name: 'MyAssembly, Version=2019.0.1.0, Culture=neutral, PublicKeyToken=null'
at TestApp.Program.Main(String[] args)
Both the managed assembly and test app target X64. Any ideas what could be the problem?
Someone from Microsoft provided the solution over on the Github repo.
When the managed C++/CLI project is built, a file ijwhost.dll is placed in the output folder alongside the assembly - this file needs to be deployed with the app that uses the assembly.
After putting ijwhost.dll in the same folder as the app, it worked as expected.
As an aside, the old C++/CLI project that I built against .NET Core 3.1 preview is actually quite complex - I'm very pleasantly surprised that it basically "just worked"!
Hopefully a better error message will be used in future!
I am using .net 5.0 as the CLI runtime. I finally found that the problem I have is missing native dependency DLLs.
For native applications, there will be an error prompt telling you which DLL is missing. While in .net core C++/CLI, they only give you a BadImageFormatException.
My solution is, create a pure native console project, paste the code that will cause BadImageFormatException, run it and see which DLL is missing then add it back to C++/CLI project file list.
I just found some unexpected dependencies.
In my case c# Net 5.0 app loads managed C++ dll, which is wrapping around unmanaged C++ dll.I get this error every time i try to run on on machine with no Visual Studio installed. I debugged it with ProcessMonitor and figure out that it can't found VCRUNTIME140D.dll. Found these dlls in my dev PC, copied them (both 32 and 64 bit versions) from my dev machine to customer's one to corresponded folders, and it made the trick. Hope will help somebody. Cheers.
I've created my C++ aplication that loads 2 DLLs: 1 wrriten in MASM assembler and the second written in C++. It uses Windows Forms' UI and works fine, but only on my computer.
On computers of all of my friends it causes 0xc000007b error that I'm unable to solve. I read everything I found about this error. Nothing helps.
I tried to do anything with manifests options in linker section, I tried to add lot of different DLLs to folder with project, I tried to use Debug and Release versions, I tried to change it to x64 version (without success).
I used dependency walker, it shows lot of DLLs missing (even though on my computer program works.) - I don't know what to do with this.
Do you have any idea? In my application I use only Windows Forms, fstream, msclr\marshal_cppstd.h and my DLLs.
I have a simple application which reads a few text files does some calculations and writes a few text files. Works perfect on my development machine (Server2008R2 VC++ 2010). I can't get it to run on a Win7 machine even thought I have installed/run the vs2010 redistribute x86.
The first error I got was missing mfc100ud.dll (yes, I'm using debug, if I try the release it just crashes, as debug tells you what's wrong). I put mfc100ud.dll in the application's directory, now fgets asserts as shown below. str is not null and the file did open successfully.
What have I missed?
My goal here is to just run the MFC app on the Win7 machine without have to install vs2010.
Another consideration, the only reason I am using MFC is for the COleTimeDate functionality. I've looked for alternatives but haven' found anything workable or as simple to use.
Thanks.
Assertion Error
This error occures if the file stream pointer (provided by fopen) is NULL.
Is it possible that you don't have any error checking after you used fopen?
Basically use "static linking" to the MFC and CRT. Than there is no Need to install and copy any runtime files.
Redistributable assemblies are only available for release builds. If you really want to distribute a debug build, you have two options:
link your app statically, so you don't need any shared DLL (such as mfc100ud.dll)
distribute together with your app (in your app folder) all the dependent DLLs. you can check the dependencies with depends.exe
Im trying to deploy a C++ AMP application to another Windows 7 machine.
I have tried to include the vcamp110.dll in the same folder, and also compiled with /MT do get rid of dependency on msvcp110.dll and msvcr110.dll.
Also tried both x64 and win32 release of the application.
On the computers i have tried it on whitout VS11 installed, the program stops responding.
I tried to do a simple test with the hello world application and i have the same problems there.
The files can be downloaded from here http://www.2shared.com/file/IofZlrJs/amptest.html (source, binary and the dll).
Any suggestions to how this can be fixed?
Deployments like the one you tried are definitely supported – full details here:
http://blogs.msdn.com/b/nativeconcurrency/archive/2012/03/12/deploying-apps-built-with-c-amp.aspx
There are a few things you can do to diagnose the issue you are facing yourself:
The bitness of vcamp110.dll has to match the bitness of your app, so 32bit for one means 32bit for the other.
Ensure that there are no other instances of vcamp110.dll in some central location (e.g. system32)
Attach a debugger and see what DLLs are loaded and what exception gets thrown.
Most important of all, for all your apps, surround your parallel_for_each call with try…catch to see what runtime_exception you are getting. More on C++ AMP exceptions can be found here: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/02/01/c-amp-runtime-exceptions.aspx
For the specific repro you shared, we tried that under the debugger on a clean Windows 7 machine and indeed a rutime_exception is being thrown: “The binary for the parallel_for_each is incompatible with this version of runtime.”, which indicates a mismatched runtime version (either mixing bitness or mixing Developer Preview with Beta or something like that).
I have a C++ application (quite complex, multiple projects) in Visual Studio 2008, that produces a single dll. Recently I switched to Windows 7, but had previously been compiling under Windows XP. Suddenly the dll in question cannot be loaded by another application, i.e. on a machine running Windows 2003 Server.
I've been trying various things:
I've installed the VC9.0 redistributable package on the server
Also copied various .dll's from that package to the application folder
The project is of course compiled in release mode
When I run depends.exe on the client machine, I do get the following error:
"Error: The Side-by-Side configuration information for "my_dll.dll" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module."
and the icon for shlwapi.dll has a red overlay icon.
This didn't happen when I was compiling under WinXP, so I'm guessing that there really is no problem with the .dll's on the client machine, but somewhere there is a reference to that particular version of some dll.
Does anyone know what would be the best way to resolve this?
Regards,
Daníel
OK I found it, and it turns out to be the same problem as described here:
vcredist_x86.dll and version 8.0.50727.4053
I had to compare the resources of the old binary with the new one, to notice the difference.