Does anyone have any clue as to what this might mean?
(ClCompile target) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): error MSB6006: "CL.exe" exited with code -1073741515.
It builds fine on my dev box but fails due to this error on our CI box. It's running on .NET 3.5.
Any help would be MUCH appreciated.
See this Microsoft Feedback report. From the article:
The error definitley needs to be a better one. What it should be telling you is that a tool failed. The issue is most likley that you don't have the Visual Studio 2008 bits on your box. So, when the project was re-targeted to the v90 platform toolset (which is the set of Visual Studio 2008 tools; can be installed with the proper version of the Windows SDK that goes with Visual Studio 2008 which I believe is v6.0A) and the tools were not installed, the build failed because it could not find the tools.
The reason that it re-targets to the v90 toolset is because that is the compiler that matches with the version that corresponded to the v2.0 CLR.
Based on where we are in the current cycle, we can't change the message. But, since we need to improve the error message in this scenario, I have resolved as postponed so that we can look at this in the next cycle.
I know this is an old question but I stumbled across a similar crash:
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): error MSB6006: "CL.exe" exited with code -1073740777.
Entirely reproducible and extremely annoying. In my case it seems to have been related to the insanely long include path list my client uses (over 16Kb of include path text, several hundred include paths to search) and when I cleaned this up and reduced the overall size the crash went away.
My suspicion is therefore that Microsoft have a 16Kb buffer somewhere in their compiler that when full simply bombs. Hope that helps someone.
Related
I have code for a software written in C++ with MFC in Visual Studio 2005. Now I need to migrate it to Visual Studio 2015. How can I do it and what are the challenges to be countered?
Like said in comments, open your solution, it will be converted. The issues I had when doing so:
Only blocking issue for compilation I had was to change the Unicode handling option in project options because one of the related options disapeared/changed its values. There is a report after the conversion is complete, read it!
All possible issues with such a huge gap in compilator versions are still possible then. So be carefull of the warnings (activate them if not done)
Running some code analysis may be a good idea to detect deprecated syntax/methods, I had some unexpected behaviour on old Microsoft methods that were a bit too permissive before (clearly it was my fault but for some reason the old compilator was kind with some of my mistakes).
I have .net project which I converted from VS 2010 to VS 2012. I am building a setup for the project through InstallShield Limited Edition but I get following error.
ISEXP : error : -5008: This 32-bit package cannot include 64-bit data. The 64-bit data may come from a merge module.
I have searched a lot but could not find any specific solution to my problem.
Any help will be appreciated.
I resolved this issue by removing the Visual C++ Runtime dependency on the project output. Here's how to do it:
(2)Specify applicaiton data / Files / right click on the primary output / dependencies from scan at build
There you can uncheck all dependencies that cause problem, Uncheck Visual C++ 10.0 CRT (x64)
Source
I also had a -6109 Internal Build error which was caused by a dependency. I just unchecked it there. It took me a whole business day to figure that cryptic stuff out. This is insane and frustrating for the least.
I've started testing VS11 beta for building Ocean 2011 plugins. It seems to work very well, and has enough advantages that I'm considering using it for daily work. (We will, of course, not make production builds with VS11 before Schlumberger recommends it.)
However, there is one blocking issue:
Projects which depend on InventorNet.dll fail to build, with the following messages:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1546,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "InventorNet", "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.
CSC : fatal error CS0008: Unexpected error reading metadata from file 'c:\Program Files\Schlumberger\Petrel 2011\InventorNet.dll' -- 'Index not found.'*
I think the first warning is harmless, as similar warnings are emitted from other dependencies, but I can't get past the error message (in bold). Both probably originate from stricter assembly verification in .NET 4.5 (also in beta) used by MSBuild. Our projects target .NET 3.5.
Does anyone know if the error can be fixed with some setting or other trick, or do we need updated assemblies from Schlumberger? (A Google search yields a few similar cases relating to VS2010, and indicates that the assembly provider does, indeed, need to rebuild the assembly to correct the issue.)
Alternatively, can someone indicate whether the issue will be remedied by Ocean 2012?
I just simply test your case for petre/ocean 2012 D9 snapshot version with OIV 9.0.0.0(for 2011, it is 8.1.2.2), it seems that it works fine(passed building with some warnings in visual studio 2011, and running OK in Petrel 2012 D9)。
Deng Feng
Just about warnings for Ocean 2012 in VS11beta: it can be "CPU mismatch" warning if your solution has "Any CPU" target and based on top of Petrel 64 (Because Inventor's DLLs are CPU dependent). And it will be no warnings if you select 64 bit CPU target for your project.
Alex
first warning can be eliminated by adding the following string to your .csproj file:
<PlatformTarget Condition=" '$(PlatformTarget)' == '' ">x86</PlatformTarget>
I added it inside node, after node
I develop an unmanaged DLL with Visual C++ which is part of my application. I have always had various problems with linking the VC runtime library. Somehow I managed with VS 2005, but since I moved to VS 2008, the release version of my DLL no longer works on any PC other than the one with my development tools (namely VS 2008).
I link the runtime library as multi-threaded DLL (/MD). I tried the /MT option but that causes a lot of error messages. I allow isolation of the manifest file, and of course installed the VC++ 2008 runtime (although I don't think it should be needed). I also tried the dependency walker to check what is missing. On my development PC (VS 2008 SP1 installed) three files are reported missing:
MSVCR90.DLL, GPSVC.DLL, IESHIMS.DLL
But that does not stop the application (and my DLL) from running.
On all other PCs I tried to install my application on, apart from these three, a fourth file is reported as missing by dep. walker: MSVCP90.DLL.
More importantly, my own DLL is not working as well.
I know this is nothing new and I tried to read everything I could find about SxS problems but I still don't know what to do. Hopefully my description of the 'phenomenon' is good enough for someone more experienced to give me some help.
Thanks in advance.
You may need to distribute and install Microsoft Visual C++ 2008 Redistributable, OR SP1 versionf of it.
This is the error Dependency Walker gives me on an executable that I am building with VC++ 2005 Express Edition. When trying to run the .exe, I get:
This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem.
(I am new to the manifest/SxS/etc. way of doing things post VC++ 2003.)
EDIT:
I am running on the same machine I am building the .exe with. In Event Viewer, I have the unhelpful:
Faulting application blah.exe, version 0.0.0.0, faulting module blah.exe,
version 0.0.0.0, fault address 0x004239b0.
Open the properties sheet for your project, go to the Configuration Properties -> C/C++ -> Code Generation page, and change the Runtime Library selection to /MT or /MTd so that your project does not use the DLL runtime libraries.
The C/C++ DLL runtimes used by VS2003 and up are not automatically distributed with the latest version of the OS and are a real pain to install and get working without this kind of problem. statically link the c-runtime and just avoid the total mess that is manifests and version specific runtime dlls.
I've had this problem. The solution has two steps:
1. Compile your program in "Release" mode instead of "Debug" mode (there's usually a combo-box in the toolbar)
2. Download from Microsoft their Redistributable Package of runtime components. Make sure to download the x86 edition for 32-bit computers and the x64 edition for 64-bit computers/OSes. Install this package on the target computer, and your application should run fine
P.S. This is a SxS thing
P.P.S. Alternatively, use a different compiler (like GCC, for example with Dev-Cpp) to compile your program's source, and your headaches will disappear.
Sorry to bump an old question, but I was able to get around this exact issue and thought I'd post a solution in case someone else needs it...
Even after installing Microsoft's redistributable DLLs I was getting this error, the fix was to copy the
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT
folder into the application's directory on the target PC. After that, no more problems.
BTW, the DLL that was giving me issues was a 3rd-party DLL that had never had problems before on over 100 other computers... go figure.
Run Event Viewer: it'll have more information.
Probably you've attempted to run your program on a machine that doesn't have the VC redistributables installed, or you're attempting to run a debug build on a machine that doesn't have Visual Studio installed (the debug libraries aren't redistributable).
I have had the same issue with VS 2008-built debug binaries on other winxp sp3 machines.
I first tried installing the client machine with vc redist package,as it seemed sensible. Annoyingly, it didn't work.
I tried copying all the dependent dlls to the application's directory - still didn't work
After being struck over this issue for hours, I found that the latest VS builds require manifests and policies to link with the dlls. After copying them into their respective "C:\WINDOWS\WinSxS\" folders, I got it working.
The problem was caused due to the fact that the vc redist package did not install debug versions of dlls, they somehow thought its up to the programmer to figure out.