I am working with a VS2010 solution we have inherited. It has approx 300 projects. Medium term I will try to break this down into multiple solutions, but I can't do that immediately.
One immediate problem is that if I do 2 consecutive builds, the second still does a lot of work, which says to me that something is wrong with the "make" configuration. What is the best way of analysing the build config to determine incorrect dependencies or other problems?
Is there a tool for doing this or shall I try and make my own? Thanks.
(The solution was migrated through VS2005 and VS2008 before getting to VS2010 which probably didn't help the build config)
The 'lot of work' from the second build could be just actions in the PreBuild steps, which are always executed. Make sure you get at least 'normal' instead of 'minimal' build output (Tools->Options->Projects and Solutions->Build and Run). Just looking at the second output should give you the information you need. As far as I know there's no tool to compare to build log files, but it shouldn't be too hard to write it yourself.
Related
How can I make my code build to fail when ReSharper detects an "Error" after code inspection?
I am using C# in Visual Studio 2017 along with ReSharper. I have set the inspection severity of Possible 'System.NullReferenceException' to show as "Error". This setting only shows a red underline for erroneous code, however the VS build still succeeds if I just ignore it. I want to make the build to fail if developer ignores such errors detected by ReSharper inspection.
I'm afraid Resharper seems to not support this option for now.
1.In my opinion, the error level in C#\Potential Code Quality Issues is something like showing a red underline to indicate where there maybe has a risk to help improve your code. And red to indicate this issue deserves attention. Actually,it's something controlled by us, we determine to make them error(red line) or warning(blue line?).
But such a potential code issue can't be recognized by msbuild (build system in vs). So the build will ignore these potential issues and succeeds.
2.For build settings in Resharper, I tried msbuild settings and compiler settings like below:
I set every element in the Potential Code Quality Issues to error. Also, i set null reference related settings like below:
After that I create a simple null reference but the build ignores that and succeeds. Same result when I use Resharper build.(Resharper options=>Tools=>Build=>Build engine) So maybe it's a negative answer :(
This isn't an ideal solution, but JetBrains provide a command line tool called InspectCode which runs their code inspections on your solution and outputs the results in XML or other formats. You could add a custom MSBuild step which runs InspectCode.exe MySolution.sln -o=output.xml, examines output.xml for errors, and fails the build if any are found.
Unfortunately InspectCode is slow and even though the analyses seem to be cached across runs it still takes a significant amount of time. For example, on my solution of 700k lines of code the tool takes 60 seconds on the second run, i.e. with a warm cache. So I don't think this is a viable solution to run on developer machines on every build. It might be acceptable in an automated build system.
I am new to TFS. (using TFS 2012 and vs 2008)I may be asking some very basic questions. How to make the TFS build fail when number of warnings is increased compared to the last build? I am willing to write vbscript/perl for it.
Finally I also want track also is there a new warning type compared to the last build?
If some guidance is provided.
Will it better be integrated as postbuild event?
Do i need to create a new Build Quality(in msft jargon)?
Check below article explaining how to do that. It has link to the Xaml file as well.
http://blog.stangroome.com/2011/03/28/fail-a-build-when-the-warning-count-increases/
You might be able to use something similar for your second question about warning type as well.
I have a solution in Visual Studio. It contains about 500 projects. When I build the solution, I get a lot of output in the output window, and also the build log. Suppose, in the end I see
Rebuid All: 250 succeeded, 10 failed, 240 skipped.
If I want to know which projects failed to build, I usually search in the output window for 1 error(s), then 2 error(s), etc. then 9 error(s). If I haven't found the 10 projects that failed using this search, then I suppose that the error count was a multiple of 10. So I search for 10 error(s), 20 error(s), etc. I usually find all failed projects this way because it is highly unlikely that the project had a number of errors which is a multiple of 100.
Question 1: Am I an idiot? What I am doing seems really idiotic to me - there has to be a better way. Which is it?
But sometimes, a project can fail for some other reasons (I assume) because today I wasn't able to find the projects that failed to build - it said 10 failed, but there were only 3 projects that had x error(s) with nonzero x. I assume that there were some projects for which some post-build steps failed or something else
Question 2: How can I find which projects failed in this case?
I am using Visual Studio 2008 SP1
Thank you very much for your help.
Why don't you go to the Errors view and just look in the Projects column? Sort by that, and then scroll down it noting when the value changes.
As an aside, having 500 projects in a solution sounds like a really bad idea to me. I strongly suspect it would be worth either consolidating the projects or splitting into multiple solutions.
Another solution is to build your solution by MSBuild scripts instead of VS IDE. It is not necessary to write the script yourself. A visual tool such as MSBuild Sidekick may help you in generating the build scripts. You can configure your build script in such a way to break the process with the first build failure and log the project name somewhere for you.
I prefer using the "Output View" in Visual Studio in this case (show output from Build). The reason this is better is that you can see which project was the first that failed to build. The project that fails to build there probably has the code error.
At work I might have 20 projects failing to build and 20,000 errors, all because of one line of code. This is way easier than hunting through every project.
I'm not sure if this is specific to 2010. But, when I do a clean, I get several errors saying "Cannot unregister assembly XXX.dll. Could not load file or assembly XXX or one of its dependencies. The system cannot find the file specified." However, if I clean again, it works. Any ideas?
I ran into and posted about this recently and found that, from the sounds of things, this is an issue with MSBuild itself and the way it resolves dependencies. My situation is slightly different from yours, though: When I run Clean through the VS IDE, it goes off without a hitch, but when I run the Clean MSBuild task, I run into the error you opened this thread with.
In my case (I'm attempting to automate our build with MSBuild), the quick and dirty fix was to use the Exec task instead of the MSBuild task to clean (and build) the solution. For the Exec task's Command parameter, I use devenv instead of devenv.exe--although this still requires an installation of VS on the build machine, unfortunately.
I suppose another option (requiring more time than I have now) might be either to write a custom task that correctly determines dependencies and runs "Clean" against each in proper order, or write one which catches the "Could not load file...' exception and loops through the clean task until it the exception no longer pops up. (This latter seems more brute-force in approach, but might be quicker.) I'm kind of new to this, so both ideas might just be worth no more than a quick flushing.
In either case, if since starting this thread you've come up with a solution, I'd love to hear about it. Good luck.
How can I figure out, how many files needs to be recompiled before I start the build process.
Sometimes I don't remember how many basic header files I changed so a Rebuild All would be better than a simple build. There seams to be no option for this, but IMHO it must be possible (f.e. XCode give me this information).
Update:
My problem is not, that Visual Studio doesn't know what to compile. I need to know how much it will compile so that I can decide if I can make a quick test with my new code or if I should write more code till I start the "expensive" build process. Or if my boss ask "When can I have the new build?" the best answer is not "It is done when it is done!".
It's really helpful when the IDE can say "compile 200 of 589 files" instead of "compile x,y, ..."
Could your version control tell you this? For example in Subversion "Check for modifications" will list everything changed since your last checkin (although not since your last build)
Mind you, doesn't "build" automatically do exactly that? (build only what's changed)?
Usually Visual Studio is good at knowing what needs to be compiled for you.
If you have multiple projects in a solution then just make sure your solution dependencies are set up correctly and it should just work when you hit Build.