.net 1.1
hi,
Though DT 4.2 does not support this version, a customer has an application written in this version. Since he already owns DT 4.2, I was wondering if there is a way to allow monitoring of such application and not force him to go to competitors.
Gil.
In theory they could use version 4.1 to monitor the app - but our support for that release is nearing its end (April 2013). Even then the support was limited, e.g. no auto sensors or thread tagging
What is the reason for still using 1.1? From what I recall the mainstream support for v1.1 ended in 2008 more than 4 years ago.
Best, Roman
Roman,
Unfortunately the customer (a large bank) has not yet upgraded several of his applications, hence the need for this framework.
I wonder, since the instrumentation is done via the collector, and because other J2EE applications should enjoy the benefits of 4.2,
Would it be enough to just have an agent or agent+collector or 4.1 to do the work ?
Gil.
You could try - but chances are this is a combination that has not been tested. Even if it works it would be a short-term band-aid as 4.1 is now on limited support for production issues and goes out of support in April of next year.
Best, Roman
Gil,
If a 4.1 Agent connects to a 4.2 dynaTrace Server, it automatically upgrades to 4.2.
Richard,
in that case it means that the customer will never be able to upgrade to 4.2 unless he upgrades his 1.1 framework applications or maintain two DT servers ...
any creative ideas to work around that ?
the approach with 4.1 agent & collector is absolutely valid but at the same time absolutely untested. 
however, you have to ensure that the bootstrap agent does not update the agent to 4.2.
so you'd have to go into the registry and replace the occurrences (registration) of dtagent.dll with dtagentcore.dll, so the bootstrap agent is replaced with the actual agent.
that's the easiest approach that comes into my mind, but again: untested and unsupported.
best,
Christian
Thanks Christian
This has worked perfectly and I'm able to see pure paths from this environment. Since the customer is upgrading from 3.2 he now comapres the new version to what he had and claimed that in 3.2 he didn't had to do any manual sensor placements for the .net application of 1.1, whereas now this was the only way we could have worked.
Gil.
hi Gil
i'm confused. so he claims to have more manual sensor placement to do with dynaTrace 4.x than with 3.x??
for .NET (where there's unfortunately no auto-sensors available), there should be hardly any changes concerning sensor placement.
does he have any specific examples?
best,
Christian
Hi Gil:
I see that you had a customer that Is (still) using .NET 1.1.
I made a similar discovery with a client of mine during an install last night.
From what you posted, it seemed the client got acceptable results using dT v4.1.
Can you share the current status please? Things still good with v4.1 monitoring a .NET 1.1 environment?
Thanks!
paul
Hi Paul,
While we were abl;e to see some results, and technology wise speaking the solution is working. we've seen taht the dashlets do not support the automatic grouping. For example, though we saw Execute Reader functions, they were not displayed in eth database dashlets. The same goes for the exceptions and errors dashlets. For that reason, we decided to propose the customer to migrate to 3.5 (he was on 3.2) and not get into any "patches" which will eventually cost more to support.
Community Member of the Month
September 2018
Announcing Dynatrace's Community Member of the Month for September 2018, Muthu P.! Click here to read more! Employee Member of the Month
September 2018
Announcing Dynatrace's Employee Member of the Month for September 2018, Kris Z.! Click here to read more!