I am moving a solution with multiple projects to VS 2015. The base project builds just fine in VS 2013. But when I try to build in VS 2015 I get the error below.
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.VisualBasic.Core.targets(56,5): error MSB6006: "vbc.exe" exited with code -2146232797.
Need help please
I talked with MS Tech Support. It's a confirmed bug in the VB compiler. They say it will be fixed in the next update.
In the mean time the work around is to install a Nuget package.
Please follow these instructions to install Nuget package.
Open the affected project in Visual Studio
Open the Package Manager Console (Tools -> NuGet Package Manager ->
Package Manager Console)
Run:
Install-package Microsoft.Net.Compilers -version 1.1.1
I had a large solution that was failing to build after updating to VS 2015 Update 1 RTM. In my case, there were a number of warnings of
Namespace or type specified in the Imports '<import name>' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
that occurred right before "vbc.exe" crashed. Once I removed those extra, unnecessary Imports, the solution build correctly.
This issue is resolved in the latest Visual Studio 2015 servicing update. The relevant download is KB 3110221 which is discussed in this KB article.
In my case, I found that an import was causing the issue. Specifically, after trying a lot of other suggestions, removing the Microsoft.Office.Interop.Excel import from a file, finally got my project to built.
I had the same issue after installing Update 1 to VS 2015.
I've download Microsoft.Net.Compilers NuGet package as Brien King suggested in his answer. This fixed the issue for one project. And then:
"c:\Program Files (x86)\MSBuild\14.0\Bin\vbc.exe" had version 1.1.0.51109
...userprofile.nuget\packages\Microsoft.Net.Compilers\1.1.1\tools\vbc.exe had higher version 1.1.0.51202
So I've copied entire "1.1.1\tools" directory into "14.0\Bin" directory and overrided 27 existing files.
This fixed it for all projects. Remember to create backup before you do this.
After trying both Microsoft.Net.Compilers -version 1.1.1 and KB3110221, my solution was still failing to compile with the same error. Only later I noticed that the error was accompanied by a warning which was letting me know that one of the libraries referenced by the solution was compiled against .NET Framework 4.5.2 while my solution was compiling against .NET Framework 4.5. I recompiled the said library against .NET Framework 4.5 and the solution compiled fine.
Now that my issue was solved after trying three fixes, I can't tell whether the last one alone would have done, but I hope it'll be of help.
I fixed the issue by opening all my .vb files are removing extra imports. Do this for all files and then rebuild. This should work.
I started getting this immediately upon installing vs2015 due to a licensing disagreement w/ MS , which I lost. :-(
Freshly back to work, i encounter this issue.
I tried doing the NUGET suggested by Brien King. Problem persisted.
I tried doing the KN suggested by Teodor Constantinescu. Problem persisted.
I tried a new trivial web app and things were fine, so I did not uninstall vs2013 or vs2015.
I chose to back up my project (3 times, once on a usb stick i put in the other room) and delete groups of files and compile after each group was pulled out.
Ultimately, when I got close to the end (nearly an empty project) it compiled.
By adding groups of files back, I identified the single file that causes this issue. I can recreate the issue by uncommenting a single line.
Further commenting out code, I isolated the problem to 4 lines of code. Beautiful.
Explanation is this...
I have 2 web references that reference ssrs
THese are currently defined in my project as
SSRS_reportservice2010
and SSRS_ReportExecution2005
I struggled getting these to work, so over time i had different names as i deleted and readded the web references. (Padawan)
For whatever reason, a file that was EXCLUDED, got INCLUDED today (2013--> 2015 issue, or greg mouse farting issue? we will never know)
In that (mistakenly included) file, there was a pair of old references
'1 Imports SSRS_ReportingService2010
'2 Imports SSRS = SSRS_ReportingService2010
'3 Imports SSRS_ReportExecution
'4 Imports SSRS_E = SSRS_ReportExecution
Line 1 used to reference the WS now named in my app as SSRS_reportservice2010
You can unComment that and things compile and run. Note that you do get a warning that you are referencing an empty namespace.
Line 2 is of course an alias to the long name, because I am an extremely lazy typer, plus I insist my code be readable and long names stink IMHO.
Line 2, if uncommented , cause vbc error -2146232797
Note that uncommenting 2 , or 1 & 2 cause the error. Its something about the bad alias that causes compiler upchuck.
Repeat the above discussion with lines 3 and 4 which have to do with the webservice currenlty named SSRS_ReportExecution2005
So there you have it.
This took me 8 hours to debug. hope it helps someone.
Many of the other posts, comments, etc also mention Import/Using Statements. The root bug probably lies somewhere in there.... (yes, this is a bug in the compiler)
PS - one thing that was interesting is that the offending file's name started w/ a W so was one of the first to come out.
Nothing improved when I took that file out of the project all together.
I can not explain why the app did not compile as soon as I took the offending file out.
I can offer that I took the webservices out very late in the process, I just didnt think they were the issue.
It baffles me that the file could be gone and I was still getting the issue when I can now simply comment out 4 lines and things work perfectly.
Apologies for the second answer, but this one is much simpler.
I got the error again in a different project 8 days after last time.
This time, I started the day by giving a better name to a class.
I had a class named conversionFactors and I renamed that class to constants to better represent what the class held.
Immediately got the error
vbc.exe" exited with code -2146232797. SizingEngine
tracked it down to this line. I should have used the rename utility. yes. No argument. The compiler should also be more robust. Tsk tsk Microsoft.
Imports cf = SizingEngine.conversionFactors
so steps to reproduce
1. create a new project
2. create a class named Foo
3. create a class named Bar
in Bar, add the following line
imports bar_ = project1.NoClassByThisNameExists
click f5
listen for pac man wilting sound
ps - VS does not report any updates ready for download today. Im sure this will get fixed at some point.
I've just had this same issue. Mine was caused by having a class that had an event inside. I'd referenced this in another class as a shared property. The shared property was causing the compiler to fail. I removed the "shared" declaration and it compiles fine now
I encountered this error when I had a post build event that was throwing an error.
There was no indication this was the problem, just the -2146232797 error.
So check this in the property pages of the project. Go to Compile -> Build Events ... and check the Post-build event command line field. I suppose this might happen with a Pre-build event so check that as well.
The problem may be related with some utilized function in .NET Framework. Try to change the project framework to 4.0 and see if the problem persists.
After building with CMAKE for visual studio 2015, I found that there were some build errors that required me to edit the code. I feel that this should not be necessary and would like to know if I might have done something wrong in build process to make these errors surface
Firstly I had to correct the compiler name from vc130 to vc140 in the files include/CGAL/auto-link/auto-link.h and cmake/module/CGAL_GeneratorSpecificSettings.cmake. I assume that this is simply because it has not been tested VS2015 and someone just assumed that vc130 would follow vc120.
The other issue I ran into was that eight functions that did not compile. These were the functions
Segment_2<R_>::min
Segment_2<R_>::max
Segment_2<R_>::vertex
Segment_2<R_>::point
Segment_2<R_>::operator[]
Segment_3<R_>::min
Segment_3<R_>::max
The issue seemed to be that the type signature of the implementation did not match that of the declaration. I tried fixing the type signature, but was unable to get it to match exactly. To fix this I ended up moving the implementation of these functions into the declaration. I would like why this is apparently necessary as presumably it compiles for other people. Sloriot commented that it was because the VS2015 compiler was more recent than the one CGAL is tested with. It is however my understanding that the visual studio compilers are backwards compatible, an thus it should not break the code to update the compiler.
The first version of CGAL officially compatible with VS2015 will be CGAL 4.7.
It seems that the new version of the Microsoft has some issues compiling valid C++ code it was accepting before. This explains why the release 4.6 of CGAL (or prior versions) has some compilation issues with that new compiler.
Background
I am exploring using the Google Maps iOS SDK in an application that will also tightly depend on another statically linked C++ library. I have accomplished Google's prescribed Hello World program successfully with one caveat: using the -ObjC linker flag causes linker errors with my other library. To remedy this, I've been using the -force_load /path/to/GoogleMaps instead in order to only target the GoogleMaps framework, which seems to work well.
The Problem
When I reference certain (not all) classes inside the static library in custom C++ classes in my app (even if I don't instantiate those classes in the app itself) I repeatably see this strange runtime error:
ClientParametersRequest failed, 3 attempts remaining (0 vs 5). (null)
ClientParametersRequest failed, 2 attempts remaining (0 vs 5). (null)
ClientParametersRequest failed, 1 attempts remaining (0 vs 5). (null)
ClientParametersRequest failed, 0 attempts remaining (0 vs 5). (null)
The result in the app is that the pin and default off-white google background appear, but no maps are downloaded.
If I delete the app from the simulator or device and comment out the static library code and run the app, the maps load and everything works fine. Then, if I add those lines back in and run the app, I don't see these errors and the maps still load fine.
If I delete the app and leave those lines in for the firstrun of the app, I get these errors, but if I then comment out the library code and re-run it, the maps begin to load and all is well. Adding back in the library code does not cause the error messages/runtime issue to come back.
This leads me to believe that the error is occurring in some sort of initialization routine that is never subsequently called. I checked the files in the app sandbox and some are missing until the maps load properly, which makes me think this is correct.
I have access to the source for the static library but obviously don't have access to the GoogleMaps SDK. There does not appear to be any clear documentation about what this error means, especially in my case where (null) is the final piece.
A few final notes that may or may not be relevant:
C++ Language Dialect: C++11 [-std=c++11]
C++ Standard Library: libc++
Thanks in advance for any help!
I have an application which relies on several libraries built by other people in my organization, one of which has stopped working. I get this error in the command-line:
Unhandled Exception: System.IO.FileLoadException: A procedure imported by 'XXX.dll' could not be loaded.
I opened up Dependency Walker to try and track down the source of the problem, although I should say that I am brand-new to Dependency Walker and I don't really know what I'm doing. Here's what I see in the log window:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Which seems straightforward, except:
Due to my unfamiliarity with DW, I can't seem to find what module this error is actually referring to
The same DLL that ships with old version of the application, which still works, shows the same thing in Dependency Walker
The only difference I can find between the old and new DLL is that KERNEL32.DLL shows up as red in the newer one, and the function K32EnumProcessModules appears as red (not exported). This same function does not appear at all (green or otherwise) for the old DLL.
To summarize so far: one DLL works and the other doesn't; both show up as 'bad' in Dependency Walker, but in only one does the function K32EnumProcessModules appear as no good. I do not know if this function is what is causing the "unresolved import" error and would like to find out.
The only change in the application I have made that I think could've caused this is upgrading the runtime from .NET 2.5 to .NET 4. This upgrade was made for reasons unrelated to this DLL, and should not affect it: the DLL does not make any calls to .NET components higher than 2.5, and other people in my organization using the same library have reported that it works fine with .NET 4.
I realize I'm providing sparse information, mostly because I'm not sure what information will help troubleshoot this problem. Please let me know if there are tests you'd like me to perform to find out more.
Probably releated to this https://blogs.msdn.microsoft.com/vcblog/2009/08/27/windows-sdk-v7-0v7-0a-incompatibility-workaround/
Defining PSAPI_VERSION=1 might help.
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.