Open abock opened 7 years ago
Thanks for the workaround, ran head first into this one on OS X/Mono.
We also ran into this issue on 12/12/2018, using the latest versions. Still a blocker on VS for Mac.
Our preview NuGet packages contain NetStandard versions of our libraries. The call from the stack trace above to EventActivityIdControl does not exist in our NetStandard version of this assembly. The net45 version of the binary is meant for windows only, so use the NetStandard version for all other operating systems.
Not sure if this is the best place to report an issue in the base VSTS .NET libraries, but here goes!
We're starting to use the .NET VSTS API at Xamarin for cross-CI integration on macOS and immediately ran into an issue where anything using
Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase
(e.g. everything) results in an exception when run on macOS (Mono):It would be great if this call could be avoided on non-Windows systems as it is not necessary to the functionality of the .NET VSTS API at all.
The call is made at the end of
VssRequestTimerTrace.TraceRequest (HttpRequestMessage)
. It'd be great to just guard it with a check againstEnvironment.OSVersion.Platform
or similar (e.g. on macOS this will bePlatformID.Unix
on Mono and possiblyPlatformID.MacOSX
on another runtime (.NET Core?)).I'd probably also guard the call itself as well by catching
DllNotFoundException
, however an explicit platform check will be much faster than performing the P/Invoke and catching the failure (Mono will attempt to resolve many different patterns of native library names before giving up).Workaround
As a workaround, I mocked a
libADVAPI32.DLL.dylib
to ensure the P/Invoke succeeds:ADVAPI32.c:
Compile:
Run my test tool:
In other words, if we can just avoid this P/Invoke on non-Windows systems, the libraries work (for at least our current use case: build queueing and monitoring) just fine!