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.
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! 🤗
I am trying to find some sort of setting in Visual Studio that controls whether it Builds all the report in the solution before letting the user Preview a report.
Currently, I am updating an old report. When I try to preview, the Visual Studio preview goes blank white for about 10 minutes then gives a bunch of errors about issues with different reports.
The report preview failed because the report could not be built.
Unfortunately, Microsoft's MSDN is pretty much useless when searching for something (or anytime you want actual information and not theory). I've looked through every item in the Visual Studio menu but haven't found anything that sounds close to what I want.
It did not build all reports last week when I made changes to another report. I have other solutions which do not currently have the problem (it would make more sense if they did, tho). What setting did I change to make this stupid functionality?
I would recommend opening that report in Report Builder. It's a free download. You can use the 3.0 version or 2016. That way it will not be bogged down by the other reports, it has simpler error handling, and it has pretty much all the same editing capabilities. Once you're done making any changes, you can continue to manage it from within Visual Studio SSDT.
This is not intended as an answer but too long for a comment.
If a report has not been successfully built previously, it will be built when you preview any report. Once the build completes, reports are skipped unless they have been changed since the last succesful build.
Usually when you preview a report, it builds just that report and skips the others.
You can prove this by going to a 'working' solution/project, right-clicking the solution and choosing Clean Solution. This will delete the build info for all the reports, next time you preview any report, every report will be rebuilt, you can see this in the Output window.
Once this is complete, preview any report and in the Output windows you will see Skipping 'report name.rdl'. Item is up to date.
I 'think' the status of each report is held in the project user options file (*.rptpoj.user) but I don't have anything that I can read the file sensibly with so I'm not 100% certain.
You may have to create new project and copy each report in one at a time fixing them as you go, I can't think of anything else, but hopefully somebody know more than me.
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 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 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.