I've reported to a third party what I consider a very serious performance bug in a widely used product. Older versions worked fine. Newer versions are practically unusable except for what I consider trivial situations. I have provided test cases showing older version performance versus newer version performance.
After waiting a few weeks with no response, I was finally told this:
We appreciate you taking the time to report this problem. We are currently prioritizing problems that are impacting a broad set of our customers, so we may not be able to investigate this one immediately. We know this problem is important to you, so we will continue to monitor it.
Due to some recent upgrades to our development environment, it's very difficult to continue using the older version of this library. We use this library in many places, so completely ripping it out and replacing it would be hard to do. Plus, there aren't many options for another product.
My concerns are as follows:
Am I understanding how to use the new library correctly? Is my reproducible test case actually correct, or am I missing something?
What (if anything) can I do to convince this vendor to put more consideration into the problem?
If I can't get a resolution, what are my options? Revert to (really old) previous versions of the product? Replace this library with another product and end up rewriting a ton of battle hardened code?
So my thought on #1 is to get code reviews of my test case. I'm currently the senior software engineer at work. I supervise two other engineers, but only one is really qualified to review. I believe he has ran my test case and has not reported any issues with it. We've both been trying to understand the causes of the performance issues, though we have came to different conclusions. I thought about posting the test harness on here asking for a code review, but I'm not sure if that's the appropriate thing to do.
I should also note that I have two other bug reports with this vendor. Also with reproducible test cases. They also seem to be getting the same lackadaisical treatment, though this was the only one where they explicitly said it wasn't a priority.
So I'm just looking for guidance. I don't really see any great option as it is.
It was requested to make this more specific, so I will attempt to describe the problem itself...
Until recently, we had been using Visual Studio 2008 and ReportViewer 2008. Upgrading our environment has been planned for awhile. As a result of an unrelated (and as yet unfixed) bug in ReportViewer, we decided to go ahead with our upgrade, hoping that would fix the bug. It did not.
We kept ReportViewer 2008. Everything there works fine. However, newer versions of Visual Studio won't allow you to design reports for 2008. You either have to upgrade or you have to develop your reports in raw xml.
So the obvious choice was to just upgrade ReportViewer, all of our RDLC files, and everything should work. However, what I found was even the simplest of reports took twice as long to run. Other relatively short reports took 10x as long. Larger reports (though still what I consider reasonable) went from 30 seconds in ReportViewer 2008 to "never finishes" in every newer version I tried. I tried with 2012, 2015, and 2017, though I suspect 2010 has the same issue. I suppose it's more than just a performance bug, since a large enough report never finishes. And it also doesn't seem to give any kind of errors.
Other people have had similar issues with it taking 10x as long to run their reports. Suggestions include changing CAS security settings or changing dynamic grouping to static. I could not find any CAS settings that fixed the issue. As for grouping, my test case was using RowNumber as a group. I'm not sure whether that is considered dynamic since it takes a group name. As for the actual data in my report, everything else was static.
As for determining the problem, I have ran a profiler and determined newer ReportViewer versions do a massive amount of binary serialization. My other programmer seems to think vb expressions are causing an issue, though he hasn't explained why he thinks this. Not to say they aren't, but I think we need to know why.
My test harness was developed to run every combination of ReportViewer 2008, 2012, 2015, and 2017 against every .NET version of 3.5, 4.0, 4.5, 4.5.1, 4.5.2, 4.6 and 4.6.1. ReportViewer 2008 used a 2008 version of the RDLC. Everything else used the newer version.
The test harness showed the problem was connected to ReportViewer version, not .NET version. However, my other programmer keeps thinking it's .NET that is the issue.
As I see it, the options to weigh are:
Hope the vendor eventually looks at this, verifies there is an issue, and fixes it. Downside is in the mean time we have to either edit our reports directly in XML or work with them in VS2008, then pull them over to our current VS version (which is 2017)
Switch from ReportViewer to something else. The obvious one is Crystal. I have no experience with that product. This would require a massive amount of rewriting in our app, which I'm not fond of.
Revert back to VS2008/ReportViewer 2008. I'm ok with this, though that means converting some of our more recent code back to working with .NET 3.5. What bothers me about this route is future support from MS. Will ReportViewer 2008 continue to work on newer versions of Windows? Will .NET 3.5 continue to work?
First and foremost on my mind is making sure I'm not making a mistake. Maybe there's something I don't understand about newer ReportViewer versions. Maybe my understanding of the workarounds I've found is incorrect. Getting feedback from either my bug report to Microsoft or on the MSDN forums has been fruitless. I feel like I must be missing something, as this is such a widely used product that this should have been addressed a long time ago.
For those who are curious: