When compiling a solution with many projects, if I make a compile time error in a project that many other projects use I'll get a flood of errors in the Error List window of visual studio:
Error 80 Metadata file
'C:\trunk\Projects\Libraries\K2DataBaseClient\bin\x64\Debug\CEPCortex.dll'
could not be found C:\trunk\Projects\TradeAiTeacher\CSC
These errors indicate that a project couldn't be built due to another project not being built. These types of errors cascade and don't really tell me anything useful as I know that its all due to a core project failing to build.
These errors often make it harder to find the actual error in the window.
Is there a way to tell visual studio to suppress this type of output and just show me the compile errors in cases like this to make it easy to find what actual code is broken?
Ideally it once the compile error has been fixed we can toggle this hiding off so I see all errors.
I had originally left this version agnostic but visual-studio 2013 is the version I am most concerned with.
No. The C# compiler categorically refuses to consider one error more "important" than another one. It cannot know how important an error can be, it doesn't know enough about the reason it had to produce the error. A missing reference assembly can produce a lot of errors because type definitions are missing. Of course the compiler cannot know the difference between them being undefined because of the missing assembly reference (ignore) or you mistyping a name (don't ignore).
Interpreting the Error List requires a massively parallel computing machine that's capable of high-speed correlation inference and pattern matching. With practical quantum computing still a distant future, you need to use the one that's readily available to any programmer, the one you have between your ears. Start at the top of the list. And work your way down, feeling less inclined to fix them as you progress down the list.
Never hesitate to rebuild before getting to the end of the list when you fixed a gross error. Like a missing assembly reference.
I've found the best way to work with existing the visual studio behavior is to use the advice in this link: and make the compiler stop after the first compile error.
This seems to get as close to solving my problem as you currently can.
Related
I have a Visual Studio linker error that popped up recently. I stumbled upon a workaround but it is driving me crazy that I can't figure out why it is happening in the first place. I need to learn how to better diagnose it.
So my question is not about how to fix it, but how to diagnose it better. In short what I'm trying to learn here is how to get the linker (or some other tool) to tell me more info about the problem. So this question is not about this particular enum or how I coded it exactly.
The project is a C++/CLI project I have a managed enum which I wanted to refer to in several other header files. So I tried to put a forward declaration of it in the shared file that I use for all my other forward declarations. That started giving me this error.
1>profileregioncli.obj : error LNK2022: metadata operation failed (801311E4) : Duplicate managed types have different visibilities.
OK, fine. My forward declaration probably looks different to the linker than the definition. But I cannot see how the declarations are different in code. And technically, since the linker doesn't even bother to tell me exactly what type is involved I cannot even be 100% sure it's this enum.
So how do I determine following two things?
Exactly what symbol is mismatching AND
Exactly what is the difference (to the linker) between the two versions.
Obviously the first item I probably know. The second, not at all.
What I have tried so far
I've tried setting linker output to full verbosity but it doesn't tell me anything new. Here is the full linker output
1>------ Build started: Project: Core.Sdk, Configuration: Release x64 ------
1>Generating code
1>0 of 1470 functions ( 0.0%) were compiled, the rest were copied from previous compilation.
1> 0 functions were new in current compilation
1> 0 functions had inline decision re-evaluated but remain unchanged
1>Finished generating code
1>profileregioncli.obj : error LNK2022: metadata operation failed (801311E4) : Duplicate managed types have different visibilities.
1>LINK : fatal error LNK1255: link failed because of metadata errors
1>Done building project "corecli_v16.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 10 up-to-date, 0 skipped ==========
ILDasm Microsoft recommends trying to use ILDasm for this error but that doesn't work. When I tried using it from the command line as they described, it tells me I have to use it interactive mode. When I then try to use it in interactive mode and open up the .OBJ file in question, it wants an .EXE or DLL, not an .OBJ
MAP File I tried changing the linker settings to generate a MAP file but it never does. So I'm guessing thats not generated unless linking is successful.
Change Something, anything Sometimes the best way to figure out an obscure linker error is to make a change -- any change -- to force the linker to give you a different error so I tried changing the managed enum type to derive from System:UInt32 (a valid thing to do which I do with some of my other managed enums) just to see if I would get a different error. And I did get it to tell me that there were two different definitions of the enum in question, but not what they were. But aside from that, no extra information
But this still leads me to want to see the two definitions side-by-side. Not in code but as the linker sees them. How do I do that?
I am getting some mysterious compiler type related errors in my ts code. I have another thread addressing them.
But I know there will be no adverse reactions to my code, so I would like to force it to compile and make my js files anyway so I can do some run-time debugging.
I have seen a comment or two about the project compiling despite some build errors. How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
I have VS2013 and TS 1.5.
Thanks, Brad
How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
Make sure that in your csproj you have noEmitOnError set to false.
The Crystal libraries referenced by our winform app cause errors in Code Analysis:
Warning 1 CA0060 : The indirectly-referenced assembly
'BusinessObjects.Licensing.KeycodeDecoder, Version=13.0.2000.0,
Culture=neutral, PublicKeyToken=692fbea5521e1304' could not be found.
This assembly is not required for analysis, however, analysis results
could be incomplete. This assembly was referenced by: C:\Program
Files\SAP BusinessObjects\Crystal Reports for .NET Framework
4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet\CrystalDecisions.CrystalReports.Engine.dll.
In a few different threads, SAP "support" has acknowledged that this is a problem on their end (http://scn.sap.com/thread/2153539), though they are quick to point out it doesn't impact their product directly, so fixing it is of low-priority. It's been assigned reference number ADAPT01629826, but it still seems up-in-the-air as to when they'll actually fix the issue on their end.
This is a Code Analysis Application Warning (http://msdn.microsoft.com/en-us/library/ms245349.aspx), rather than a normal Code Analysis Warning.
Because of that, Visual Studio doesn't provide the usual "Suppress Message(s)" context menu. I'm hoping there's a way to use GlobalSuppressions or something similar, but could use some help...
Even if SAP is right about the bad assembly reference not having a functional impact on their product, it still bothers me. Like the original poster, I don't want any errors/warnings from Code Analysis.
I'm sure others have run into this -- or at least something similar. How did you handle it? Is there a way to exclude this specific warning from Code Analysis, so it no longer shows?
While I don't like hard-coding exclusions, it seems like a more reliable solution than waiting around for SAP to actually push out a fix.
There is no way to suppress these without wrapping fxcpcmd or overwriting the code analysis targets to intercept the output and ignore the warning.
I recently added a new project to my Visual Studio 2008 solution. Now, as I make edits in the new project, I receive a ton (~50) of type checking errors - indicating that an assembly reference may be missing. However, when I actually build the solution, the errors go away. As best I can tell, my dependencies are set and the build order is correct. What could be wrong?
It doesn't prevent me from building and deploying, but it's a major nuisance. It makes it hard to tell when I actually have introduced new errors (until I do compile). Thus, it erodes the usefulness of having the error window do static analysis.
Example, one of the 50 errors is this:
"The type of namespace name 'PersonManager' does not exist in the namespace 'Gideon' (are you missing an assembly reference?"
In reference to this line of code:
Gideon.PersonManager pm = new Gideon.PersonManager()
PersonManager is underlined in both places, and when I right click the type and selected 'find all references' I get an alert box that says "Cannot navigate to PersonManager"
However, the references are definitely there, because when I build, it works.
One other detail is that there is a mixture of C# and VB.net code, though I don't think that should make a difference.
Well, yes, the IntelliSense parser is not an exact replica of the C# compiler. It has a very different job to do, it needs to do something meaningful while the code is utterly broken since you are editing it. Tough assignment, they did a tremendous job with it. But as a side-effect, it can fail to parse things that are actually legal. It's quite rare but not unheard of, seen it myself a few times.
This won't go anywhere concrete until you at least give us some idea of what kind of errors you are seeing, along with a snippet of the code that generates them. You didn't do so, I can only recommend that you select another window so you don't have to look at them.
I had the same problem. I had a project in my solution that was causing the problem - I removed the project from the solution, then added a reference to that project in the main solution and the errors went away. Strange that it only happened on 1 machine. Opening the solution on another machine was fine...
Is there a "call stack" for compiler errors in Visual Studio 2005 (C++)?
For example, I am using a boost::scoped_ptr as the value in a QHash. This is however causing the following compile error:
1>c:\qt\include\qtcore\../../src/corelib/tools/qhash.h(743) : error C2248: 'boost::scoped_ptr<T>::operator =' : cannot access private member declared in class 'boost::scoped_ptr<T>'
From the build output I know which of my source files is causing the error and the line number in the qhash.h that is causing the error but I am trying to track down the line number in my source file that is generating the error (hence the "call stack" idea).
Please note, I am not looking for the solution to the problem of using a scoped_ptr in a QHash but the problem of tracking down where compile errors are generated. This would also be useful for helping track down weird warnings. More often than not I run into this problem when using templated classes.
Thanks!
Sometimes with strange errors it helps to preprocess the file and look at that output. With VS look for "Generate Preprocessed File" under preprocessor settings (or set the /P switch). This will generate XXX.i from XXX.cpp which may help you figure out the problem.
Make sure you turn off the switch after, with this option turned on it won't generate an obj file.
If you look at the build output, you should see which project and which .cpp file was being compiled when this error occurred.
There is really no notion of "call stack" here, because the compiler processes one source file at a time. You have a compiler error in the header file, so you need to find out which source file including that header was being compiled.
These types of errors can be hard to track down. Usually I end up comment out code and finding the offending line and working from there. After doing it a while you will learn to better read the error messages and understand what tripped up the compiler. As it stands the compilers error messages are just horrible.
In this case it is saying that you have an object of type boost::scoped_ptr<T> that it is trying to copy but the class won't let you (operator= and the copy ctor are both hidden). So you need to look at how the class is used and see why it is trying to copy it. Maybe a scoped_ptr isn't what you need. Maybe you need a shared_ptr?