Profiler starts IIS apppool in .NET 2.0 for .NET 4.0 app

adamfox

Hi,

I am trying to profile a .NET 4.0 web application with IIS 7.5 on Windows Server 2008 R2 Standard with ANTS Performance Profiler 7.0.

The web application I am profiling is up and running properly through IE 8 on the server and is correctly configured.

When I try to start profiling with "ASP.NET Web Application (IIS)" option, I see that ANTS is starting up its own IIS process then I see a configuration error "Unrecognized attribute 'targetFramework'" for the line

<compilation debug="true" targetFramework="4.0" />

in the applications web.config file ... the error page also displays the following

Version Information: Microsoft .NET Framework Version:2.0.50727.4927; ASP.NET Version:2.0.50727.4927

This error obviously makes sense as it is an invalid attribute for .NET 2.0, what is not obvious is why it is running under .NET 2.0 framework.

This is unusual as the ANTS configuration file seems to indicate it is inheriting from the configured application pools on the server but all application pools on the server are configured for .NET 4.0.

Anyone seen this behaviour before? Have any ideas about remedying?

We have reinstalled the software but are seeing the same result.

Thanks in advance for any help you can give

Chris.Allen

Hi - sorry about this; it's a regression (PP-1950). We're looking into it. Are you able to try version 6? You can download from here (you'll need to uninstall 7 first):

http://www.red-gate.com/supportcenter/g ... d_versions

adamfox

Hi Chris,

Thanks for your response.

We tried downgrading to 6.3 and received the same error.

We tried downgrading to 6.0 and received this exception (looks like the System.Network.Sockets assembly is still .NET 2.0):

Could not start IIS.
RedGate.Profiler.Engine.Exceptions.CannotStartSessionException
at

Chris.Allen

Hopefully, this will help:

http://www.red-gate.com/supportcenter/C ... _start_iis

We have tried to collate the major things that can go wrong with IIS profiling.

joe123

Any further news on this? we have the same issue, and it makes Ants profiler next to useless. We can still attach to process but then you only have method-level timing. we have tried the early access preview builds and they too seem to suffer from the same issue, as does 6.3...

I ask because this was last looked at in amrch and there doesnt seem to have been any resolution...

adamfox

Still no resolution ... we still face this issue.

Chris.Allen

I have only just recently found out the workaround to this bug:

edit the applicationHost.config by hand and add the managedRuntimeVersion attribute.

Please see:

http://technet.microsoft.com/en-us/libr ... 23(v=WS.10).aspx

for offical docs on this attribute

Laura Morley

OK, we think we've fixed this in our latest nightly build: you can download a free 14-day trial of the new build from http://help.red-gate.com/help/ANTSPerfo ... d_eap.html . Does the problem still occur for you with this build?

Assuming the fix works, we should be able to roll it out in the 7.3 release.

judymay47

I was having the same problem, but I didn't know what it was and was looking for help. The EAB fixed it.

joe123

There seems to have been a reversion in the release of 7.3, as they fixed this in the EAP if I remember - although the app pool launches in .net 4 mode, when restarting the IIS application on the same port, it does not seem to respect the original application pool's integration mode. As an aside, my trial expired while I was helping test the EAP, and now when the program starts (7.2) because the trial has expired it doesn't check for updates which means I cannot try the new version. I experienced this bug on a different machine.

Summary:
It appears APP 7.3 launches its IIS application pool with integrated security as opposed to classic, which prevent it from functioning, as dlls that require httpcontext.current return null.

Brian Donahue

The problem was that if the app pool config didn't explicitly state the .net runtime version, ANTS would not get the configuration from the application pool defaults. I am guessing the .NET team fixed that for the supportedRuntime, but not the pipeline mode. I'll try to get someone to look at that.

dom.smith

Hi Joe,

Sorry; we did introduce a regression which means that the bug fix in v7.2 didn't get into v7.3. Thanks for letting us know.

I am arranging for our Product Support team to send you a private build of v7.3 with the fix in it.

If anyone else reading this thread has the same problem with APP 7.3, please let me know. We've taken steps to ensure that the bug is fixed for everyone in the next version of ANTS Performance Profiler.

Dom.

Brian Donahue

If you're using ANTS Performance Profiler 7.x, please apply this patch and it should fix the problem.
ftp://support.red-gate.com/patches/ANTS ... .3.1.2.zip

joe123

Hi Dom,

Although your product team hasn't gotten around to it yet, I was able to try the patch Brian posted on another colleagues machine and it seems to be working OK again.

My red-gate evangelism campaign internally in the company is going well, and hopefully we should be able to place an order soon.

However we are also very interested in the continuous profiling aspect, which I notice is still in beta/EAP. Obviously on individual machines, the full blown experience is preferable, but am I correct in understanding the continuous profiling mode can be installed on a production server, and with history, if say a server experiences problems at 4am, the next day we would still be able to see the methods causing the issue the next day?

Does it offer the same level of detail (I.E. line-level timings? ) And what is the overall impact of actually having the profiler running permanently?

Finally, what are the licensing options? Is it paid on a per serv basis, or per the single developer assigned to work on N servers?

dom.smith

Hi Joe,

Thanks for your response and for letting us know that the patch from Brian is working.

To stop this thread from getting off-topic, I've answered your other questions by email.

Dom.

James B

As a followup, another user reported being able to workaround this issue by amending the default App Pool to use .net 4.0 - hopefully this information may be of use to others who come across this thread.