line-level times are not showing

[adbourdages]

Good day,

I have done two profiling sessions. In one I have all the line-level information in the source code view and in the other I only have method-level information.

They were both recorded using the same project, one lasted ~20 sec while the other one lasted ~15 minutes.

How can I get ANTS to display the line-level data on longer profiling sessions?

Alain-Daniel

[swythan]

I'm having the same problem yesterday (on an eval license). I'm just getting the timings for the whole method displayed next to the first (executable) line in the source.

Any hints for debugging the issue?

[StephenC]

Hi,

sorry for the trouble you are having. There have been a couple of reports of this but we don't have very much information as yet about what might be the cause of it.

Can you please double check that you have selected the line level timing mode from the opening project dialog. I did have one report and it turned out he had changed the setting and forgotten so i want to rule out the most obvious before we proceed.

Can I ask:

1) what type of applications are you running
2) Framework versions
3) Visual Studio version
4) Does this happen with all of your applications?
5) Is there anything different about the applications in which it does happen with?

If at all possible you can create a small "Hello World" style application that demonstrates the issue that would be great. You can send it to support@red-gate.com and reference this post.

Regards,

Stephen

[adbourdages]

I have the standard version, so there is no other option than line-level!

1) It is an asp.net application, profiled on Cassini, using EntityFramework and NHibernate.
2) 3.5
3) Team 2008
4) I've tried with the only one application I'm working on. Can't help here.
5) n/a

I saved the profiling results. If they can be useful, tell me where I can send them. It is 75M.

To further help you out and clarify what is happening: If I profile the project twice, once with lots of request, the other only with a few, the small profile will have all the line-level data but not the large one.

I'll try to create a small application as you mentioned, but since your development team hasn't been able to reproduce the error (as you imply), I doubt I'll have any success.

Do you have an estimate on how long it will take to fix? (days, weeks or months?) Because right now, it makes ants pretty useless and I have to decide if I wait for the fix or move on to other tools/solution. I would appreciate if I can get an answer to this.

Alain-Daniel

[swythan]

My problem seems to have been running unit tests through the MbUnit GUI. (I was doing a quick demo of ANTS to a colleague.) Running the same tests through the MbUnit console works fine. Maybe it's something to do with the MbUnit GUI running the tests in a different AppDomain?

This is using Vista or XP, .Net 3.5 SP1, VS2008 SP1 (not used during test) & MbUnit 2.41.232.0.

[StephenC]

We discovered an issue with NUnit a while ago where the PDB files were not being shadow copied along with the other files. It resulted in the same sort of behaviour you are describing.

The work around for NUnit was to obviously turn off shadow copying but i'm not sure if this is possible with MbUnit. You could try manually copying the PDB files to the directory where the files are being copied to and give that a go as long as the directory isn't being cleaned when the files are being copied.

It shouldn't have anything to do with AppDomains.

Stephen

[swythan]

Cheers, Stephen.

Alain-Daniel: Sorry for hijacking your thread. It looks like your issue is more complex than mine!

[StephenC]

James, sounds like the issue you were having has been resolved (or at least to an extent). I know some one very involved with the MbUnit project and will try and confirm with him what's going on.


Alain-Daniel,

if you could give me some more details about the scenario and settings etc... we will try and get to the bottom of it too.

Maybe a screen shot would be helpful as well.

Regards,

Stephen

[adbourdages]

Hi,

I am not using any kind of test environment setup, simply running the website in Cassini and interacting with it in IE.

You can see the setting I use to start the project:
http://71.6.196.213:82/ForRedGate/settings.png

and the source code view:
http://71.6.196.213:82/ForRedGate/line-level-without-time.png

I know that if I drill down far enough in a call tree that the interface will start telling me that 'Simplified stack traces'. Maybe you are shedding the line-level times when you reach that point?

I don't know what to say, if you have any specific data you want, I can sent it. Actually, let me just put that profile result file out there for you to load:

http://71.6.196.213:82/ForRedGate/adb-profile.zip

Alain-Daniel

[StephenC]

Hi,

regarding the 'Simplified stack traces'. If you go to 'Tools' -> Options; before starting profiling and then uncheck the "Simplify very complex stack traces to save memory" option you won't get that in the tree view. It may however lead to higher memory usage while profiling.

Thanks for the info, we will try and get to the bottom of this and will post back with more questions or things to try when there are some ideas of what may be causing this.

Stephen

[JasonC]

Can you please also ensure that debug="true" in your web.config? This is necessary for line-level timing.
_________________
Jason Crease
Red Gate Software

[MikeW]

Has this been resolved... I am having this issue with version 4.1, SOMETIMES it will show the line-level times and (with the same setup) sometimes it wont. It seems after stopping and compiling the asp.net app again it gets flaky, if it even worked to begin with. It appears to show method level timings even though it explicitly says "Line-level Timings". Things to note, this is a .Net 2.0 website, VS2005, Vista64

[Brian Donahue]

I don't believe that we have identified any "bug" that would cause the line-level to work sometimes and sometimes not.

It may be useful to know what you mean by "after stopping and compiling" the web app, as web applications are typically dynamically compiled. If you are doing a static compilation using aspnet_compiler.exe, the settings that you use may be wrong somehow.
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521

[MikeW]

Its a standard visual studio web site compile, nothing strange about it... default settings. The site setup has 1 website, and 2 other project dll's that get compiled (as dependencies) along with it. To answer your question... and to make sure we don't focus on the wrong issue, "after stopping and compiling" was only referring to a case i ran into. That case being, It fired up and it actually ran the line-level timings and it all showed up correctly. After recompiling, it simply stopped showing line-level and appeared to show method level. This leads me to believe it has issues resolving the debug files. It seems the norm for me is that line-level hardly ever works, very frustrating. Now i will not rule out that im failing to do something very obvious maybe, but I cant seem to spot anything. Read above,and note that it does in fact read "Line-level timing", but it looks exactly like a method level report.

[Brian Donahue]

Surely this has everything to do with the PDBs and their availability and/or correctness. The whole mechanism for resolving source code is supplied by the Visual C++ runtime (far as I know) and we don't have much control over whether the source code location is turned over to ANTS Profiler by the runtime or not.

One thing that may make the process more reliable for you could be to, first of all, make sure that debugging information is generated for all builds, and that if you have to deploy the website files to a staging server, to ensure the PDBs are also copied to the right places. You could also consider creating some post-build events in Visual Studio to copy the PDBs to the "global" symbols location used by the VC++ Runtime.
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521