App Insights and .NET 4.6.1 in a Worker Role in emulator -- exception

[georgestevens99]

Hi,
First thanks for answering my question about NetMessagingBinding, etc.

I started with a worker role built targeting .NET 4.6.1 that successfully installs .NET 4.6.1 and can run OK in the emulator or in Azure.

Then I added app Insights Window Server assemblies via nuget to it, including manually upgrading App Insights Agent Intercept to 2.0.1 (in trying to get it to run). No luck. It crashes in the emulator with the following exception message:

System.IO.FileLoadException was unhandled
Message: An unhandled exception of type 'System.IO.FileLoadException' occurred in Microsoft.WindowsAzure.ServiceRuntime.dll
Additional information: Could not load file or assembly 'Microsoft.ApplicationInsights, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Then I removed all the App Insight assemblies via NuGet and reinstalled them and got the same error message.

Can you point me in the right direction to using .NET 4.6.1, and eventually using a worker role to host a WCF service using the NetMessagingBinding and .NET 4.6.1, plus use App Insights (which is quite useful!). FYI I have successfully done all of that except when I add the App Insights assemblies the emulator crashes!

Thanks,
George

[georgestevens99]

More Info -- This problem may only be with the Worker role. I have a WCF service that is successfully outputting Telemetry.TrackRequest() info to the Visual Studio console window, although they are not showing up in Azure.

[tomasr]

That exception message sounds like you've got mixed versions of assemblies targeting different versions. We had this problem in one specific version (#23 (comment)), but that should be fixed. Can you tell me what version of Microsoft.ApplicationInsights.dll is getting imported into your project? (look at the assembly version itself, maybe using a tool like ILSpy if necessary)

[georgestevens99]

Hi Tomas,

Thanks for your response. I looked at the assembly version of
Microsoft.ApplicationInsights.dll in References->Properties and it was
2.10. Is that version number the same as you'd get with ILSpy?

Thanks,
George
Georg

On Mon, Aug 29, 2016 at 9:30 AM, Tomas Restrepo notifications@github.com
wrote:

That exception message sounds like you've got mixed versions of assemblies
targeting different versions. We had this problem in one specific version (#23
(comment)
#23 (comment)),
but that should be fixed. Can you tell me what version of
Microsoft.ApplicationInsights.dll is getting imported into your project?
(look at the assembly version itself, maybe using a tool like ILSpy if
necessary)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGNznQ8l04Ji-4tKuP1XZA4sl1gwaErCks5qkt7ggaJpZM4JvcgY
.

[tomasr]

2.1.0 should be the right assembly version, but seems like something is requesting a different version for some reason. Any chance you could try running the service with a debugger attached and get the full exception and stack trace? (or event better, enable fusion logging to capture the entire assembly binding error message; the thread here has details on how to do it)

[georgestevens99]

Thanks for the suggestion. I have to deal with other things for a few
hours, and then will return to this issue. The problem is likely a
dependent assembly. I'll use your suggestions, plus try some other ideas.

Unfortunately the exception happens in the start method of WorkerRole.Run()
before the WCF service host is started and likely before the first line of
code in Run() gets executed.

I'll get back to you when I get things more pinned down.

Thanks,
George

On Mon, Aug 29, 2016 at 10:00 AM, Tomas Restrepo notifications@github.com
wrote:

2.1.0 should be the right assembly version, but seems like something is
requesting a different version for some reason. Any chance you could try
running the service with a debugger attached and get the full exception and
stack trace? (or event better, enable fusion logging to capture the entire
assembly binding error message; the thread here
http://stackoverflow.com/questions/7204889/is-there-anything-like-assembly-binding-log-viewer-on-windows-azure
has details on how to do it)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGNznd9ugL2oDSwBTvjVNG9Sq6o6HFhrks5qkuXmgaJpZM4JvcgY
.

[georgestevens99]

Tomas,
More info. The exception happens before the WorkerRole Start() method starts executing its code. Here is the complete exception info:

System.IO.FileLoadException was unhandled
Message: An unhandled exception of type 'System.IO.FileLoadException' occurred in Microsoft.WindowsAzure.ServiceRuntime.dll

Additional information: Could not load file or assembly 'Microsoft.ApplicationInsights, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I will continue with this later.
Thanks,
George

[georgestevens99]

Found the problem and fixed it.

I have 3 projects that use the Application Insights assemblies. 2 of them
were using ApplicationInsights.dll version 2.1.0 (latest stable), and one
was using 2.2.0 (beta). This caused assembly conflicts in the solution,
which showed up as compile time warnings.

When running the worker role Azure Runtime did not like the 2.2.0 assembly
that the assembly conflict resolver gave it and threw an exception in the
role StartUp() before any of my code was executed.

The way I figured this out was looking in the output window after doing
what this link says:

http://stackoverflow.com/questions/24772053/found-conflicts-between-different-versions-of-the-same-dependent-assembly-that-c,
including copying the contents of the output window into NotePad then Find
"conflict".

Once I found the assemblies in conflict I used the solution wide NuGet
Package Manager to see the actual assembly versions, and then the project
NuGet Package Manager to make the changes required to have all the same
assembly versions of ApplicationInsights.dll throughout the solution in all
3 projects that have telemetry instrumentation.

Now it runs in the emulator with no problems. Tomorrow I'll try running it
Azure.

Application Insights is an amazing productivity enhancer. 10 years ago I
did a major performance overhaul on some really slow software and got an
1800% speed up. Unreal! But it took me over a week to manually instrument
the code so as to pinpoint the slow areas and exactly what was causing it.
With Application Insights I can do much the same in a couple hours with the
code running in the environment it runs in in production -- Azure. For
that reason I like it even better than performance monitoring tools of 5
years ago (which were not bad).

Keep up the good work!
George

On Mon, Aug 29, 2016 at 10:47 AM, George Stevens georgiageorge99@gmail.com
wrote:

Thanks for the suggestion. I have to deal with other things for a few
hours, and then will return to this issue. The problem is likely a
dependent assembly. I'll use your suggestions, plus try some other ideas.

Unfortunately the exception happens in the start method of
WorkerRole.Run() before the WCF service host is started and likely before
the first line of code in Run() gets executed.

I'll get back to you when I get things more pinned down.

Thanks,
George

On Mon, Aug 29, 2016 at 10:00 AM, Tomas Restrepo <notifications@github.com

wrote:

2.1.0 should be the right assembly version, but seems like something is
requesting a different version for some reason. Any chance you could try
running the service with a debugger attached and get the full exception and
stack trace? (or event better, enable fusion logging to capture the entire
assembly binding error message; the thread here
http://stackoverflow.com/questions/7204889/is-there-anything-like-assembly-binding-log-viewer-on-windows-azure
has details on how to do it)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGNznd9ugL2oDSwBTvjVNG9Sq6o6HFhrks5qkuXmgaJpZM4JvcgY
.

[georgestevens99]

Found the problem and fixed it.

I have 3 projects that use the Application Insights assemblies. 2 of them
were using ApplicationInsights.dll version 2.1.0 (latest stable), and one
was using 2.2.0 (beta). This caused assembly conflicts in the solution,
which showed up as compile time warnings.

When running the worker role Azure Runtime did not like the 2.2.0 assembly
that the assembly conflict resolver gave it and threw an exception in the
role StartUp() before any of my code was executed.

The way I figured this out was looking in the output window after doing
what this link says:

http://stackoverflow.com/questions/24772053/found-
conflicts-between-different-versions-of-the-same-dependent-assembly-that-c,
including copying the contents of the output window into NotePad then Find
"conflict".

Once I found the assemblies in conflict I used the solution wide NuGet
Package Manager to see the actual assembly versions, and then the project
NuGet Package Manager to make the changes required to have all the same
assembly versions of ApplicationInsights.dll throughout the solution in all
3 projects that have telemetry instrumentation.

Now it runs in the emulator with no problems. Tomorrow I'll try running it
Azure.

Application Insights is an amazing productivity enhancer. 10 years ago I
did a major performance overhaul on some really slow software and got an
1800% speed up. Unreal! But it took me over a week to manually instrument
the code so as to pinpoint the slow areas and exactly what was causing it.
With Application Insights I can do much the same in a couple hours with the
code running in the environment it runs in in production -- Azure. For
that reason I like it even better than performance monitoring tools of 5
years ago (which were not bad).

Keep up the good work!
George

On Mon, Aug 29, 2016 at 10:47 AM, George Stevens georgiageorge99@gmail.com
wrote:

Thanks for the suggestion. I have to deal with other things for a few
hours, and then will return to this issue. The problem is likely a
dependent assembly. I'll use your suggestions, plus try some other ideas.

Unfortunately the exception happens in the start method of
WorkerRole.Run() before the WCF service host is started and likely before
the first line of code in Run() gets executed.

I'll get back to you when I get things more pinned down.

Thanks,
George

On Mon, Aug 29, 2016 at 10:00 AM, Tomas Restrepo <notifications@github.com

wrote:

2.1.0 should be the right assembly version, but seems like something is
requesting a different version for some reason. Any chance you could try
running the service with a debugger attached and get the full exception and
stack trace? (or event better, enable fusion logging to capture the entire
assembly binding error message; the thread here
http://stackoverflow.com/questions/7204889/is-there-anything-like-assembly-binding-log-viewer-on-windows-azure
has details on how to do it)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGNznd9ugL2oDSwBTvjVNG9Sq6o6HFhrks5qkuXmgaJpZM4JvcgY
.

[tomasr]

Glad you found out what was going on!

FYI, also had a moment to test the library with NetMessageBinding without issues. Here's one request tracked:

The Request URL base does look a bit weird; though not sure if it's significant in any way:

[georgestevens99]

Hi Tomas,
Thanks for checking out the NetMessagingBinding with the WCF Appllication
Insights support.

George

On Mon, Aug 29, 2016 at 9:33 PM, Tomas Restrepo notifications@github.com
wrote:

Glad you found out what was going on!

FYI, also had a moment to test the library with NetMessageBinding without
issues. Here's one request tracked:

[image: image]
https://cloud.githubusercontent.com/assets/16179/18072918/a895b0b6-6e27-11e6-8e16-8e31457ac09c.png

The Request URL base does look a bit weird; though not sure if it's
significant in any way:
[image: image]
https://cloud.githubusercontent.com/assets/16179/18072937/c790b1dc-6e27-11e6-891f-71db89b6d0d5.png

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGNznQ-U9gzUWfEfb4dU9H3_uRqhMkq9ks5qk4hggaJpZM4JvcgY
.

[georgestevens99]

Hi Tomas,

FYI here is a blog article I wrote about my experience with Application
Insights. Thanks again for your assistance.

https://dotnetsilverlightprism.wordpress.com/2016/09/11/azure-application-insights-quick-and-easy-service-performance-and-health-monitoring/

George

On Tue, Aug 30, 2016 at 5:52 PM, George Stevens georgiageorge99@gmail.com
wrote:

Hi Tomas,
Thanks for checking out the NetMessagingBinding with the WCF Appllication
Insights support.

George

On Mon, Aug 29, 2016 at 9:33 PM, Tomas Restrepo notifications@github.com
wrote:

Glad you found out what was going on!

FYI, also had a moment to test the library with NetMessageBinding without
issues. Here's one request tracked:

[image: image]
https://cloud.githubusercontent.com/assets/16179/18072918/a895b0b6-6e27-11e6-8e16-8e31457ac09c.png

The Request URL base does look a bit weird; though not sure if it's
significant in any way:
[image: image]
https://cloud.githubusercontent.com/assets/16179/18072937/c790b1dc-6e27-11e6-891f-71db89b6d0d5.png

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGNznQ-U9gzUWfEfb4dU9H3_uRqhMkq9ks5qk4hggaJpZM4JvcgY
.

[tomasr]

@georgestevens99 Nice blog post, thanks for sharing!