Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UWP with NetStandard2 on Net Native does not support Assembly.CodeBase + Handle native methods in StackTrace #2643

Merged
merged 2 commits into from
Apr 6, 2018

Conversation

snakefoot
Copy link
Contributor

@snakefoot snakefoot commented Apr 4, 2018

Throws PlatformNotSupportedException when Net Native. Resolves #2632

https://github.com/dotnet/corert/blob/master/src/System.Private.Reflection.Core/src/System/Reflection/Runtime/General/ThunkedApis.cs#L63

And also fixed an issue with GetCurrentClassLogger that returned wrong classname. And also fixed an issue with callsite that threw NullReferenceExceptions. Happy days with Net Native.

@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch 2 times, most recently from c15e476 to 2087eb9 Compare April 4, 2018 15:14
@snakefoot
Copy link
Contributor Author

snakefoot commented Apr 4, 2018

@304NotModified Any reason why NLog uses Assembly.CodeBase instead of Assembly.Location:

https://blogs.msdn.microsoft.com/suzcook/2003/06/26/assembly-codebase-vs-assembly-location/

Looks like that the Assembly.Location can be a "random" place when running unit-tests:

https://stackoverflow.com/a/283917/193178

@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch from 2087eb9 to 006ee51 Compare April 4, 2018 15:33
@codecov
Copy link

codecov bot commented Apr 4, 2018

Codecov Report

Merging #2643 into master will decrease coverage by <1%.
The diff coverage is 69%.

@@           Coverage Diff           @@
##           master   #2643    +/-   ##
=======================================
- Coverage      81%     81%   -<1%     
=======================================
  Files         326     326            
  Lines       24045   24070    +25     
  Branches     3040    3047     +7     
=======================================
+ Hits        19469   19483    +14     
- Misses       3752    3762    +10     
- Partials      824     825     +1

@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch from 006ee51 to eb243af Compare April 4, 2018 15:40
@304NotModified
Copy link
Member

I will check, there was a good reason.

@304NotModified
Copy link
Member

Related: #794

@snakefoot
Copy link
Contributor Author

I will check, there was a good reason.

You don't have to. Think the GAC and unit-test-frameworks are enough reasons not to keep Assembly.CodeBase. Though one could consider having fallback to Assembly.Location (when Assembly.CodeBase doesn't work), but that is a different PR.

@304NotModified
Copy link
Member

There was a fall back, but removed. See #29

@304NotModified
Copy link
Member

Any way, we need to check the unc path. Afaik there is no unit test for it.

@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch from eb243af to 0362f6f Compare April 4, 2018 18:16
@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch from 0362f6f to 73ac870 Compare April 4, 2018 18:32
@snakefoot
Copy link
Contributor Author

@304NotModified Discovered that StackTraces now are more optimized on UWP NetStandard2 with Net Native. Have added extra protection regarding callsite-lookup and current-class-logger-lookup.

Could be nice if this callsite/class-lookup logic could extracted to a separate NLog-package, and remove the StackTrace-dependency completely (Ex. for NLog ver. 6).

@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch 3 times, most recently from 3b40380 to 6fa69dc Compare April 4, 2018 21:49
@304NotModified
Copy link
Member

Could be nice if this callsite/class-lookup logic could extracted to a separate NLog-package, and remove the StackTrace-dependency completely (Ex. for NLog ver. 6).

Don't we need it for every platform?

@snakefoot
Copy link
Contributor Author

snakefoot commented Apr 4, 2018

Don't we need it for every platform?

Many people can live without having GetCurrentClassLogger() and Callsite (Just like they can live without WCF targets), especially when it means less dependencies and less overhead and less fuzzy logic. Do not recall seeing this enricher logic in the core of Serilog.

For those needing them, then they will just be a nuget-package away.

@304NotModified
Copy link
Member

Not sure about the currentClassLogger, https://mobile.twitter.com/NLogOfficial/status/758390118310875136

(Small poll, but better than no poll).

Of course having it optional is always nice, but a bit difficult as it's a static method (on logmanager).

@snakefoot
Copy link
Contributor Author

snakefoot commented Apr 4, 2018

(Small poll, but better than no poll).

Think those who voted, regret it now as it took 2 years to complete, and everyone was dead in the water :). The difference between nice-to-have, should-have and must-have is very vague for those standing on the side-line watching the others doing the digging.

optional is always nice, but a bit difficult as it's a static method (on logmanager).

Was thinking NLog 6.0 meant breaking old chains. A quick search and replace (and a recompile) should be something most programmers are capable of. Could probably have a default implementation of LogManager.GetCurrentClassLogger() that returns the calling assembly-name.

@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch 7 times, most recently from 4a729c9 to 809d9b8 Compare April 5, 2018 05:13
@snakefoot
Copy link
Contributor Author

snakefoot commented Apr 5, 2018

Another thing that should be moved out of the NLog-core is the automatic assembly loading. It has been a pain to maintain, and promiscuous assembly loading is not recommended by security specialists. Instead it should just be an extension to the internal configuration-loader (separate nuget-package).

@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch 2 times, most recently from 2dd2976 to ba7749e Compare April 5, 2018 07:06
@304NotModified
Copy link
Member

Any way, we need to check the unc path. Afaik there is no unit test for it.

Could you check if a config from UNC still works, or should I do that?

@304NotModified 304NotModified added this to the 4.5.2 milestone Apr 5, 2018
@snakefoot
Copy link
Contributor Author

Could you check if a config from UNC still works, or should I do that?

I have not changed anything in the assembly loading, besides handling the PlatformNotSupportedException. But please test away.

var entryAssembly = Assembly.GetEntryAssembly();
if (!string.IsNullOrEmpty(entryAssembly?.CodeBase))
var entryLocation = GetAssemblyFileLocation(Assembly.GetEntryAssembly());
if (!string.IsNullOrEmpty(entryLocation) && !string.Equals(entryLocation, assemblyLocation, StringComparison.OrdinalIgnoreCase))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good check for the string.Equals (saves us a GetNLogExtensionFiles) 👍

Uri assemblyCodeBase;
if (!Uri.TryCreate(assembly.CodeBase, UriKind.RelativeOrAbsolute, out assemblyCodeBase))
{
InternalLogger.Warn("No auto loading because assembly code base is unknown");
InternalLogger.Warn("Skipping auto loading location because code base is unknown: `{0}` ({1})", assembly.CodeBase, fullName);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not very important, but why the backticks and not quotes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

{
if (stackFrames.Length > i)
{
var nextStackFrame = stackFrames[i + 1];
var declaringType = nextStackFrame.GetMethod().DeclaringType;
var declaringType = nextStackFrame.GetMethod()?.DeclaringType;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.GetMethod() cannot return null now, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand. GetMethod() can return null, so free navigation can be dangerous. See the stackFrames[i + 1].

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, missed that, thanks!

@304NotModified 304NotModified changed the title UWP with NetStandard2 on Net Native does not support Assembly.CodeBase UWP with NetStandard2 on Net Native does not support Assembly.CodeBase + performance improvement for callstack-based operations Apr 5, 2018
@304NotModified
Copy link
Member

Also small performance improvement, isn't? Added it to the title :)

@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch from ba7749e to 4e2fa55 Compare April 5, 2018 14:27
@snakefoot
Copy link
Contributor Author

Also small performance improvement, isn't?

Don't think I have made any performance improvements on purpose. Mostly refactoring to improve the code-reuse for callsite-logic and GetCurrentClassLogger .

@snakefoot snakefoot changed the title UWP with NetStandard2 on Net Native does not support Assembly.CodeBase + performance improvement for callstack-based operations UWP with NetStandard2 on Net Native does not support Assembly.CodeBase + Handle native methods on callstack Apr 5, 2018
@snakefoot snakefoot changed the title UWP with NetStandard2 on Net Native does not support Assembly.CodeBase + Handle native methods on callstack UWP with NetStandard2 on Net Native does not support Assembly.CodeBase + Handle native methods in StackTrace Apr 5, 2018
@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch from 4e2fa55 to f8609aa Compare April 5, 2018 15:08
@snakefoot snakefoot force-pushed the UwpNetStandardAssemblyLookup branch from f8609aa to 58d93b2 Compare April 5, 2018 15:38
@304NotModified
Copy link
Member

I have not changed anything in the assembly loading, besides handling the PlatformNotSupportedException. But please test away.

tested it anyway, :) Thanks!

@snakefoot
Copy link
Contributor Author

@snakefoot I have not changed anything in the assembly loading,

@304NotModified Guess I can withdraw that statement and wait for #2830 to be merged :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants