Trying to build a project that uses managed C++/CLI and it compiles successfully when in the 64-bit build config. When I switch to Win32 config it fails siting the managed C++/CLI dll is not a strong named assembly. When switching configs I have verified that both have the Project -> Configuration Properties -> Linker -> Advanced -> Key File entry has the proper path to the snk file ($(SolutionDir)key.snk)
Not sure if I'm missing something here. I haven't been able to find anything on Google...
[UPDATE]
If I use a post build event in the C++/CLI project the output window shows the following error:
c:\path\file.dll does not represent a strongly named assembly
I'm using the following post build event:
sn -Ra "$(TargetPath)" "$(SolutionDir)key.snk"
Again - the above post build event works on the x64 config but not the win32. (I have tried compiling on both 32-bit & 64-bit machines w/ same result)
Just ran into the same problem today, after some digging it looks like this is caused by a bug introduced in Microsoft Visual Studio 2010 SP 1.
A description of what caused the bug and a workaround can be found at the following link:
http://blogs.msdn.com/b/vcblog/archive/2011/03/11/10140139.aspx
Related
A VC++ 2008 win32 console application uses some MFC functions, it can run without problem in 'Debug' mode within the VC++ 2008 environment. Also, the debug executable can ran on any computer with full version of visual studio 2008 installed.
But that same debug executable won't run on systems that don't have the visual studio 2008 installed, it gives the following error message:
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.
The initial search for this problem leads to MSN recommendation to install the VC++ 2008 x86 redistributable SP1. But this failed to resolve the problem.
Then, the win32 console application is recompiled for 'Release' mode and it gives the following error message:
fatal error C1189:#error: Building MFC application with /MD[d](CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
this error happens in afx.h header.
I tried to actually #define _AFXDLL in preprocessor, but it created new errors about unable to convert MFC type of string to char* etc
I also tried 'Use of MFC' settings: in static library and shared DLL, both create more errors
The thing is, the original program was created in VC++ 6.0 and it used a lot of MFC functions (especially string and CObject), but after recompile in VC++ 2008 in a win32 console app, it somehow can work in debug mode, but can't be stand-alone exe in release mode, which is kinda what I need to have a stand-alone exe that can run on newer windows (7 or 8)
Could anyone help. Thanks.
Yes. Don't build in Debug mode. Build for Release. You can't legally distribute the Debug DLLs. You can build a Release version with Debugging information in it--via PDB files.
This may also happen if your release build has dependencies against some debug libraries, link against non debug ones.
After moving my build server I get the following error:
C:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft.Common.targets (1682): Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR2" and architecture "x64". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "MSBuildTaskHost.exe" exists and can be run.
My configuration says this:
<ConfigurationToBuild Include="Release|Any CPU">
<FlavorToBuild>Release</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
What am I missing?
To resolve this, Go to your .csproj file and open with notepad.
Add the following line under the default property group:
<PropertyGroup>
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
Project should compile now.
In my case, I received that error message when trying to build a solution on a 32-bit Windows 7 machine. The way to resolve the error for me was to right-click on the project in VS, choose properties, then go to the Build tab. In here I changed the "Platform target" from "Any CPU" to "x86". HTH
Another approach is to do the following
Click Start ->> right-click Computer ->> Properties ->> Advanced system settings ->> click Environment Variables button to open the dialog,
then under the System variables section, click New… button, type the
Variable name = DISABLEOUTOFPROCTASKHOST, and type the Variable value = 1,
then click Ok.
This should suppress this error.
You need to install .NET SDK for the version of .NET that you are using.
Here is a link for .NET 3.5
Where is the .net 3.5 SDK?
and here is a link for 4.0
http://www.microsoft.com/en-us/download/details.aspx?id=8279
Installing Visual Studio will install the right SDK as well, but may not be a good option for you.
I hope that helps.
The core problem is the fact that an 64-bit executable can not load a 32-bit dll and vice-versa.
"Auto" means that . NET assembly will switch at runtime between the platforms, depending on what platform is on the machine it is currently running on.
So having a .NET assembly compiled with "Auto" loading an 32-bit dll is a problem waiting to happen, and this is what this error is all about.
To correct it, if you are NOT using any native dlls, go to the properties of the project for every managed project and set "target CPU" to be the same as currently selected "Platform", for all available platforms.
If you are using native dlls, you have to define 2 build configurations one for 32 bit and one for 64 bit, link (refer) the correct versions of the dlls and install according to the target computer platform.
I resolved this issue by opening VS2010 as administrator.
I am trying to use the gloox library (C++) to create a Windows XMPP application. It seems simple enough, except I don't know how to import gloox into Visual Studio 2010 so I can include it in my application project.
I've looked at the instructions provided in the read-me (shown below), but when I try to compile the library, I get this error:
Cannot open source file: 'src\tlsgnutlsserver.cpp': No such file or directory
Instructions provided in the read-me file:
Building gloox on MSVC++
use the included project file or create your own
adjust include + library paths if necessary
to receive any debug output you should use the LogSink facilities (this is not win32-specific)
build
Does anyone have experience using Gloox with VS10? If yes, can you please help me out? Thanks!
I assume you're using the official 1.0 tarball? I had the same problem (missing source file) and had to acquire the source from SVN instead. I used the 1.0 branch.
I encountered a few other build problems, namely
the release build configuration was set to build an Application (.exe) instead of Dynamic library (.dll) (Project->Properties->General->Configuration Type)
I needed to add DLL_EXPORT to the preprocessor definitions (Project->Properties->Configuration Properties->C/C++ ->Properties->Preprocessor)
src\atomicrefcount.cpp needed to be added to the project's source files. (Project->Add Existing Item)
This worked for me in express editions of both VC++ 2010 and VC++ 2008.
Hopefully it helps you as well.
I was given some files that were built in Visual Studio 2005 version.
When I tried to convert the .sln file to use in VS 2010 Express C++, however, I run into problems.
The error gives out the path and says that the file was not found even though the file is there. I know there shouldn't be any compatibility issues between the two unless I am missing something. Has anyone run into this type of problems?
The exact error message is:
"Conversion Report - GeoM\GeoM.vcproj: Converting project file
'C:\Users...\GeoM\GeoM.vcproj'. File 'C:\Users...\GeoM\GeoM.vcproj' was not found. \
Project upgrade failed.
The most likely explanation is that your C++ project has been configured to support compilation for a platform other than x86 (such as x64 or IA-64).
This is explained on the Visual C++ blog, in the Visual Studio 2010 C++ Project Upgrade Guide:
Make sure you have the required platforms installed before doing upgrade
Converting a project on a machine without all the available platforms for the project will result in a conversion error. For example, if you try to convert a project with Itanium Platform on Visual Studio Professional SKU, which does not support the Itanium platform, you will see a conversion error like the following:
Failed to upgrade 'Debug|<Itanium>'. Please make sure you have the
corresponding platform installed under '%vctargetspath%\platforms\Itanium'.
Cannot load the project due to a corrupt project file. The following error
has occurred during XML parsing:
File: D:\Sample\ConsoleApp\ConsoleApp.vcproj
Line: 28
Column: 5
Error Message:
System error: -2147154677.
The file 'D:\Sample\ConsoleApp\ConsoleApp.vcproj' has failed to load.
This is by design as the conversion needs to evaluate the properties in the missing platforms to do a successful conversion. You can verify which platforms are installed on your machine by looking in the following directories: %ProgramFiles%\MSBuild\Microsoft.cpp\V4.0\Platforms (or %ProgramFiles(x86)%\MSBuild\Microsoft.cpp\V4.0\Platforms on x64 machine) for the Platforms installed on the machine.
Since the Express version does not support compiling C++ applications for either of these platforms, the upgrade wizard is failing to convert your project and returning the described error message.
The only way this upgrade is going to succeed is if you use a full version of Visual Studio (with the appropriate platform compiler tools installed), or if you edit the solution/project files that you have to remove any mention of a non-x86 configuration. You should be able to do this with a simple text editor like Notepad, but as always, back up first in case you destroy something irreplaceable.
I made a program in Visual Studio 2010 on Windows 7 64-bit.
When I try to run it on Windows XP 32-bit I got message that msvcr100.dll is missing. When I try to copy that file from Win7 to WInXP I got message that msvcr100.dll is wrong.
How to set building in VS so msvcr100.dll would not be necessary?
First you need to make sure you're building a 32 bit executable - 64 bit ones won't run on 32 bit Windows.
Then you can either...
Ship the 32 bit redistributables with your application.
Remove the runtime dependency altogether and link statically to the C++ runtimes. To do this, set Project -> Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library to Multi-threaded (/MT).
Linking the runtime libraries statically should help. Go to Project Options -> C/C++ -> Code Generation -> Runtime Library and change the value to Multithreaded or Multithreaded Debug and recompile. This way your application shouldn't depend on the runtime DLLs.
Also don't forget to build a 32bit executable.
The answers above helped me along, but I was still getting the error:
fatal error C1189: #error : Please use the /MD switch for _AFXDLL builds
So to help other who may have, like me, spent way too much time stumbling around in search of a clear solution, I'd like to add the bit of information that solved this issue for me. As it turns out, my project had the wrong "Use of MFC" setting to make use of the answer above.
To put it in clear terms:
Open up the project properties (alt-F7 or Project-menu -> [My Project] Properties) and go to Project -> Properties -> Configuration Properties
If General -> Use of MFC is set to Use MFC in a Static Library
you must set
C/C++ -> Code Generation -> Runtime Library
to either Multi-threaded Debug (/MTd) or Multi-threaded (/MT)
and if
General -> Use of MFC is set to Use MFC in a Shared DLL
you must set
C/C++ -> Code Generation -> Runtime Library
to either Multi-threaded DLL (/MD) or Multi-threaded Debug DLL
I got this answer from the Microsoft community answers website and all credit should go to David Wilkinson.
The keyword here is "redistributable" since this error message may occur when attempting to run a .exe that was not developed on the end-user's PC.
The following is a good (and trusted) source to download redistributables without having to download the entire VC++ package or patch:
https://visualstudio.microsoft.com/vs/older-downloads/#microsoft-build-tools-2015-update-3
In my case I needed the "Visual Studio 2010 VC++ Redistributable" even though we are in year 2022.
enter image description here
Step 1.: Go to this website dll-files.com.
enter image description here
dll-files.com is a great repository of Windows DLL files and has almost all the DLL files that are existent on Windows.
Step 2. Now type there your DLL error in the search window of the website.
Step 3. DLL-Files.com will immediately list out the zip file containing that particular DLL file. Download this zip file to your computer and extract it. The extracted folder will contain the DLL error file.
enter image description here
Step 4. Copy the download DLL file (Only that file) and paste this file in your default system folder based on your operating systems below.
C:WindowsSystem (Windows 95/98/Me)
C:WINNT\System32 (Windows NT/2000)
C:\Windows\System32 (Windows XP, Vista, Windows 7/Windows 8.1/Windows 10)
Windows will ask you whether you want to replace the existing DLL file with the new one. Say yes and let Windows copy the file. Restart your computer and voila, you can now run the game/app that was not opening and giving the DLL error, easily.
There are many other websites which will give you DLL files that you want