.NET Core 3.0 WPF app crashing after using illink #595
Comments
|
Thanks for the report @tomrus88. This should be fixed in the next preview, where we're making the default a bit more conservative, but you're likely to see other issues similar to this due to missing analysis for more complex apps. I'll keep this issue open until we get a build with the fix. |
|
Using dotnet core 3.0.100-preview6-012162 Which makes sense, the Greenshot.Addon.ExternalCommand.dll file (and some others) is not in the extracted directory (the Greenshot.Addon.ExternalCommand.dll.config is!!). It works fine without PublishTrimmed enabled. I need to add that although the main Greenshot csproj references addon projects there is no direct code dependency to them, it's done via reflection and dependency injection. Can I mark projects/assemblies somehow so they are not trimmed? |
|
The linker isn't catching your use of reflection. We'll have docs for solving these kinds of problems soon. In the meantime, try adding the following to your project: edit: I should have mentioned earlier - there are a few more changes incoming that will basically do the above for you for non-framework assemblies (i.e., the default will be pretty conservative). We will probably get a build later today with that behavior (waiting for dotnet/installer#2236 to merge). |
|
@sbomer Thanks for the hint, but this somehow doesn't work. I also tried specifying true via the Directory.Build.props and with the information here: https://github.com/dotnet/standard/blob/release/2.0.0/Microsoft.Packaging.Tools.Trimming/docs/trimming.md I can look at the next build, and it would be nice if things work out of the box. But would like to be able to control this... |
|
@Lakritzator my apologies, I initially wrote the above thinking that the change had made it in. The PR I linked has the change that enables use of |
|
@sbomer no problem 😄 it comes when it comes. The only thing I would like to know, is how to figure out what issues / PRs are in which dotnet core version. Even when something is closed or merged, it doesn't mean that I can download and install it... |
|
With 3.0.100-preview7-012260 the result already looks a lot better 😄, though it's a lot bigger as it was before (which makes sense but still 😢 ) Still there are issues, I currently get an error as netstandard.dll is missing. As long as I use Windows Forms, all is okay, but as soon as System.Windows.Media.FontFamily comes into play I get exceptions like: Or (depending from where I come): As that part of the code works fine without trimming and this seems to be an internal thing, it's a bit out of my influence. Additionally I noticed that System.Windows.Forms seems to be reduced by linking, but one of the assemblies I really would like to see reduced MahApps.Metro.IconPacks.dll is not. This DLL is 14MB but I probably use around 500KB... any way to see what happened and influence this? About the resulting size, which is already a discussion elsewhere, but I did want to mention it: |
|
@Lakritzator: That exception looks like a dup of dotnet/wpf#771 its probably not linker related? Fyi I agree that the size after trimming is just way too big in my opinion. A simple hello world program trimmed shouldn't be larger than 10mb. |
|
@Symbai For the rest: Interesting side note: |
|
@Lakritzator thanks again for reporting back! I filed a new issue about the error you get when trying to root an unreference assembly. It's not obvious what is missing that's causing the About MahApps.Metro.IconPacks.dll: currently dlls from external nuget packages are always rooted (not reduced). We may consider adding the option to mark packages as trimmable if it's a common request - just note that this will likely cause further breakage if that package is activated by reflection or uses reflection itself. I've filed an issue to track this at dotnet/sdk#3302. |
|
I'm not 100% sure, but I don'T think that I use reflection in this case. The stack trace seems to be a single dotnet stack, except for the initial startup. I will check what is referencing the netstandard, maybe it's me somewhere. But why it's removed would be hard to tell... With 3.0.100-preview7-012267 it seems my single exe doesn't start at all, I don't get an error. |
|
I found the issue why my application doesn't start up: With 3.0.100-preview7-012282 the following issue still happens: Even though there were some fixes made here: dotnet/wpf#771 |
|
I'm seeing something similar to @Lakritzator Project file: <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<UseWPF>true</UseWPF>
<PublishTrimmed>true</PublishTrimmed>
<PublishSingleFile>true</PublishSingleFile>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
</Project>Then publish the app to a single-exe. This works great with an empty app, But the moment you add this to your xaml, the app fails to launch. I see the same stack trace as above in EventViewer: <TextBlock Text="Helvetica" FontFamily="Comic Sans" />Event viewer log: |
|
DirectWriteForwarder is a C++/CLI DLL compiled as clr:pure. I am not sure if that has any influence on the ILLinker and what trimming it does, but this does seem very specific to single exe publishing + trimming. @sbomer Is there anything WPF can give you to help fix this? |
|
Looking through the exception stack, this stands out: This is just a guess - I suspect that illink could be tripping on a compiler bug. The C++/CLI compiler emits a few bad type-refs into For e.g., it points |
|
/cc @tgani-msft |
|
Thanks @jkoritzinsky. Closing this because it has a few separate issues, some of which are fixed. Tracking the |
Create and publish WPF app
Run published app and see it crashing with following error (without PublishTrimmed switch app works fine)
The text was updated successfully, but these errors were encountered: