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.
Related
I am trying to run msbuild command line, but, I am getting in the last step of it, the error below (it is in portuguese, but is the same error in the title.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Xamarin\iOS\Xamarin.Shared.targets(227,3): erro
r MSB4044: A tarefa "GetMinimumOSVersion" não recebeu um valor para o parâmetro obrigatório "SdkVersion". [E:\2-PROJETO
S\_ALGORIX\Projetos\ACCORD\SOLUTION\AppAlgorix\AppAlgorix.iOS\AppAlgorix.iOS.csproj]
My msbuild command is:
msbuild AppAlgorix.sln /p:Configuration=AppStore;Platform=iPhone /p:CFBundleVersion=1 /p:CFBundleShortVersionString=2.3.1 /p:ServerAddress={mac ip address} /p:ServerUser={mac user} /p:ServerPassword={mac pwd} /p:BuildIpa=true /p:IpaPackageDir="E:\8-IPAS\ACCORD" /t:Clean;Build /p:ArchiveOnBuild=false /p:IsAppDistribution=false /p:CodesignKey="{App ID identifier}" /p:CodesignProvision="{App Provisioning Profile}"
All the {} data are confidential, so I cropped them.
This command was working one day, but I don´t know when, but after some VS 2019 update, the command, stops working.
I have found some articles about it, but I can´t find a way to resolve this problem.
Onw of those articles is this:
https://www.gitmemory.com/issue/xamarin/xamarin-macios/10109/729614745
My VS 2019 is updated in version 16.8.4.
I have here, about 40 apps to build and get the ipa. I was running a dosbat to resolve it, and get those ipas, more quickly. Not having this msbuild command line working, will take me to a big problem, cause I almost every week have some updates in my apps, and build one by one, will not be a great idea.
And one more thing is.. I can build inside VS 2019, without any problem. The problem happens only via msbuild command line.
I used the post Visual Studio update (16.8.1) lead to CI build failures to resolve the error.
"This has reared it's head again in Visual Studio 2019 version 16.8.3.
Looks like they've moved the problem to: \MSBuild\Xamarin\iOS\Xamarin.Messaging.targets I was able to get
my builds running again by removing the _SayGoodbye dependency on line
52 for the _DisconnectAfterClean target."
Although I have resolved the error, now I cant generate the ios.ipa package. Now, I get only the file projectName.iOS.exe, instead of projectName.iOS.ipa.
I dont know if this workaround is the final solution for this bug, yet.
We resolved this by running the build twice in-a-row. (continue on error - ignore the failed first build)
The first time always fails with the error in the question title, but it must somehow sets things up so that the second build has what it needs to succeed. The IPA is generated, etc.
IMPORTANT: DO NOT CLEAN BETWEEN THE TWO BUILDS
I know this solution is a hack workaround, but I prefer it to manually making changes to the .targets files as I have seen suggested elsewhere (those suggestions did not work in our case anyway). Making changes like that without knowing the internals of the build process intimately could result in unintended side-effects.
NOTE: As this solution involves an expected failed partial first build, it does add to the build time, but it was only about a minute or two longer per build, and at least it works reliably.
Hope this is helpful to someone! 🤗
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.
When I start live unit testing in Visual Studio 2015 (15.4.2) I have a message in the output window saying
Build completed(failed)
But if I try to build the the unit test project separately it will build without any warnings and errors.
All in all it says "Live unit tests started". But i don't get "blue" lines which indicate missing unit testing.
The issues was with post build actions. I have removed them and it working fine.
Just ran into a very similar issue myself in Visual Studio 2019, wanted to leave down my solution for those who may be searching for it later down the road.
To get to the actual issue, navigate to the following
Test -> Live Unit Testing -> Options...
Then change the Logging level to Verbose. The next time you build, open the output window (View -> Output or Ctrl + Alt + O), and use the dropdown at the top of the window to select "Live Unit Testing" (Note: you may want to clear this log and run it again to in order to make it easier to interpret). Near the start of the log will be your build events, hopefully including the error you've received.
In my particular case, my error was due to the length of my .csproj path exceeding the 260 character limit. In order to fix this with TFVC, I had to re-map my workspace to a shorter name then build again and my tests appeared and worked fine.
Hopefully this can help save someone else a bit of searching in the future
Ran into a similar issue and indeed the problem seems to be long path limitations.
See #MichaelM's answer, and turn on verbose logging -> this should point you to the project failing to build/ reference.
Suggestions:
try to reduce your path by remapping your project to a shorter path (e.g. D:\x)
try to rename your project name to a shorter version (e.g. CompanyX.FeatureY.ComponentZ.csproj -> Y.CompZ.csproj)
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.
I got a solution with multiple projects. Three of the projects are setup projects and they are the ones producing the error.
Each time I build the project I get multiple warnings saying "The command you are attempting cannot be completed since XXX.vdproj is under source control and is not checked out".
How can I get rid of those messageboxes?
Why isn't the warning(s) added a to the "Error list" as all other errors/warnings are?
(Edit: checking out the setup projects will of course work, but I want to get rid of that messagebox without having to do a checkout every time)
I would suggest creating a solution configuration in which the setup project is included in the build, and remove it from the regular Debug and Release configurations. That way you can (on a build server or in another context) build the setup when it makes sense.