search

okta / okta-sdk-dotnet

A .NET SDK for interacting with the Okta management API, enabling server-side code to manage Okta users, groups, applications, and more.
Other
158 stars 100 forks source link

AmbiguousMatchException: Multiple custom attributes of the same type found #296

Closed justinhelgerson closed 5 years ago

justinhelgerson commented 5 years ago

I'm experiencing a runtime issue with this library and I was hoping someone might be able to provide some guidance. It looks to be caused by this line in the UserAgentBuilder class. I'm running an ASP.NET (not Core) application on .NET Framework. The runtime exception isn't an issue when running on .NET Core.

I'm not able to reproduce the issue on my Windows 10 machine, but in our test & production environments (Windows Server 2012) we do experience the runtime exception. I tried bumping up the version of .NET Framework on our test server (to match my development environment), but no dice.

I realize this isn't exactly an issue with the Okta library and it's likely a netstandard vs netframework topic, but I suspect someone else may run into this issue as well. I've already downgraded one application to the older Okta.Core.Client library to address this issue. I'd like to keep using this library, and unfortunately the issue is caused by the user agent telemetry data being collected which isn't relevant to what I'm trying to do. 

System.Reflection.AmbiguousMatchException: Multiple custom attributes of the same type found.
   at System.Attribute.GetCustomAttribute(Assembly element, Type attributeType, Boolean inherit)
   at System.Runtime.InteropServices.RuntimeInformation.get_FrameworkDescription()
   at Okta.Sdk.Internal.UserAgentBuilder.Generate()
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.LazyInitValue()
laura-rodriguez commented 5 years ago

Hi @justinhelgerson, Sorry for the inconvenience. Are you experiencing this issue with both the ASP.NET SDK and the Okta management SDK? Can you tell me the version of the SDK's you are using?

justinhelgerson commented 5 years ago

I'm experiencing this with the Okta.Sdk package in both versions 1.1.0 and 1.2.0.

nbarbettini commented 5 years ago

I bet it is related to: https://github.com/Azure/autorest/issues/1542

That thread seems to imply that disabling or updating Application Insights solves the problem, but regardless of that - @laura-rodriguez I think we should add some extra checks to the user agent builder so that if any part of the telemetry code fails, it doesn't cause a fatal error. It's better for us to send no telemetry than blow up the application.

justinhelgerson commented 5 years ago

@nbarbettini That would be a welcome change. I definitely understand the desire for that type of data, but I think foregoing it and letting the Okta operation succeed could be a good change.

I read through that thread as well. We're not using Azure or Application Insights. I've been stumped trying to track down the issue since early this morning, unfortunately no progress.

laura-rodriguez commented 5 years ago

Agree with you @nbarbettini. Regardless it seems to be an external issue; we need to cover any fail in the agent builder to avoid fatal errors.

Thanks for bringing this up @justinhelgerson!

justinhelgerson commented 5 years ago

Thanks for your responses both of you. As baffling as it is, it seems like an official Microsoft performance & monitoring agent breaks that .NET Framework API call. I was able to prove that removing the SCOM agent from our server resolved the issue. Unfortunately this is a standard tool used by out IT folks for collecting data on our servers.

So it looks like I'm going back to Okta.Core.Client in the meantime. @nbarbettini @laura-rodriguez I'd be happy to put together a PR if that would help. Otherwise I'll keep an eye out on a change from you so I can switch back.

nbarbettini commented 5 years ago

@justinhelgerson PRs are definitely welcome! (You'd need to sign our CLA if you haven't already)

Regardless of who works on it, some try/catches around the critical code should do it. I'd like to see the UserAgentBuilder resilient enough that even if any of the string manipulation fails (for some reason), it will simply return an empty string or the bare minimum info it has.

justinhelgerson commented 5 years ago

@nbarbettini Any idea when you'll be pushing an updated NuGet package?

laura-rodriguez commented 5 years ago

Hi @justinhelgerson, thanks for your contribution 🎉 . We will be working on a minor internal task these days and, we want to include it as part of the same patch. We are expecting to publish an updated NuGet package by the end of next week.

justinhelgerson commented 5 years ago

Awesome. Thanks Laura!

On Thu, Jan 10, 2019, 6:43 PM Laura Rodríguez <notifications@github.com wrote:

Hi @justinhelgerson https://github.com/justinhelgerson, thanks for your contribution 🎉 . We will be working on a minor internal task these days and, we want to include it as part of the same patch. We are expecting to publish an updated NuGet package by the end of next week.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/okta/okta-sdk-dotnet/issues/296#issuecomment-453321279, or mute the thread https://github.com/notifications/unsubscribe-auth/ABQZRhXXlJ0OHAbZkz5cwqLzNO24EuJNks5vB94qgaJpZM4Zj_jR .

laura-rodriguez commented 5 years ago

Hi @justinhelgerson, your contribution is on NuGet 🎉