Blazor linking throws "Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object." #2896
Labels
Milestone
Comments
|
If I do a publish from Visual Studio I get some more information. Note that the app builds and runs fine without this trimming but is wooping 15 MB so I´m looking to get that a lot smaller... |
|
After finding out that I could add the following line
I got some more information (why isn´t this printed out when you are publishing?) Are these the reason I can´t apply trimming or something else? |
|
I just ran I installed the Project System Tools and recorded the build log (because it was to large for my terminal to record) and then tried to view them with the structured-log-viewer but that blew up also 🤦♂️ So here are the binlogs if they can help you help me 😅 |
|
The crash is a bug in the linker (IIRC @sbomer rewrote it). I guess in your case https://github.com/dotnet/linker/blob/release/6.0.x/src/linker/Linker/TypeReferenceWalker.cs#L212 is null. |
|
/cc @vitek-karas |
|
@sturlath thanks for reporting. I have tried publishing a project with a csproj similar to the one you shared but haven't been able to recreate the crash. If you could share some kind of repro that would be very helpful.
Those warnings are an indication that the trimmer can't statically reason about the code used by your app, and they could represent real issues. (https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming/fixing-warning has more info about the warnings in general). However these look unrelated to the crash, which is definitely a bug.
The Blazor SDK isn't fully trim-compatible - they only trim explicitly opted-in assemblies. They disable warnings by default to avoid noise since some of the potential issues are mitigated by partial trimming, but this is no guarantee that there aren't real issues. |
|
@sbomer it took me time but I got you a trimmed (removed basically everything while still getting the error) down version of my code https://www.dropbox.com/s/9cng52ywp0jujkf/MicrosoftLinkerErrorInBlazor.zip?dl=0 It has all the dll´s just in case you had some nuget issues. Let me know when you have used and I´ll remove the share from dropbox (saving size) Hope this helps |
|
@sturlath I really appreciate you taking the time, this helps a lot! This reproduces the issue for me. |
|
The linker is crashing on what looks like an invalid
This assembly looks like it has been obfuscated - maybe the obfuscation process created invalid IL. |
|
This is for sure obfuscated assembly. Trimming obfuscated assembly does not make sense, it would be great if you could issue a warning though. |
|
We could check for null in this particular case, but I doubt we will be able to make the linker end-to-end resilient to this without a lot of effort. Do you think a best-effort approach makes sense here (so just add a null check in this one place for now)? If there were some more reliable way to detect obfuscated assemblies I would be more inclined to do it, but I don't see any obvious indication like an assembly-level attribute in this example. |
|
@vitek-karas noticed that the assembly has |
Our position in .NET Native was that if the obfuscator doesn't produce outputs that could be legitimately produced by obfuscating the source code and then compiling that with a real compiler, it's unsupported. One thing is that obfuscators generate IL like this (where they put unreachable garbage in-between instructions). The other thing is they also produce malformed metadata in spots the runtime won't look at. It's hard to support that because it often exploits corner cases of the runtime implementation. David Wrighton could talk about all the corner cases of virtual resolution obfuscators tend to exploit. IL Linker can't even get the virtual resolution right for the cases that the C# compiler can generate. I have a hard time seeing obfuscators in general as something that can be supported with trimming. |
|
Sorry for not making the question clearer. I don't think anybody here is proposing to support obfuscated assemblies. What we're thinking about is detecting at least the most common obfuscators and reporting a warning. Basically trying to avoid repeating the work to debug a random failure in the linker, just to realize it's because of an obfuscated assembly. I vaguely remember that .NET Native had some code to detect the common obfuscators as well, so I was curious if you remember what it did. |
It looks at assembly-level custom attributes, looking for anything that contains |
|
(And it was a hard error, not a warning. Our experience was that people would do a support call, ignoring all warnings they got, and not mentioning the warning until we started investigating.) |
|
But I´m guess you will allow the rest of the code to be trimmed (add a null check and proceed)? This obfuscated dll is a bought one that I personally did not obfuscate and have no control over. |
|
Historically we've been avoiding trying to do anything with obfuscated assemblies - for example, we can't rely on the ability to read/write it without breaking it since it exploits runtimes ability to handle otherwise very invalid IL/metadata in some cases. There's also no real guarantee the assembly will actually work at runtime - especially in Blazor. The Blazor's client runtime is basically Mono, not CoreCLR. If the obfuscator makes use of things which work in CoreCLR, those same things may not work on Mono. All of this is exaggerated by presence of AOT compilers - for example Blazor now offers AOT compilation, which is effectively another implementation of the CLI reading spec, which may or may not understand the weird things obfuscator did. I would definitely suggest to mark these assemblies as "copy": https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming/trimming-options#trimmed-assemblies and add The general problem is that obfuscators often violate the CLI spec, so there's no reasonable way for us test our tooling against them. Even if we decided to invest into this. |
|
I understand. But please add some information in the logs about the offending dll. That makes it easier to find the the creators and ask them to make it trim friendly. |
|
@sbomer can you see what dll is causing this? We are having problem pinpointing it |
|
One of the problematic dlls is |
|
There's no plan to support obfuscated assemblies, but we should try to play nice. So we could use the known marks of an obfuscated assembly and when we detect an assembly like that, make the linker warn/error with some helpful message. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I run the following
dotnet publish --configuration Releaseon my Blazor WASM I get the error here below that doesn´t tell me anything usefulThis is the content of my csproj if that helps
This the whole error
The text was updated successfully, but these errors were encountered: