This is a follow up to this twitter thread. I've also provided some reading/suggestions in this gist. I figure this is a better text box than 280 characters at a time on twitter. 😊
I have some other tasks today that will keep me from digging in too much but maybe you can get lucky a bit given the notes below. Certainly let me know!
The Issue
The short answer is that the particular arrangement of libraries has caused .NET Native to lose it's mind and we'll need to write some hints about what types/members/namespaces can be safely ignored. Fortunately, the compiler is very generous about writing out artifacts at various stages that should make our lives easier. I'll dive into one in particular that should help us out.
The gist above describes "start with everything" and a "Start with nothing" approach. Given how things are interconnects I suspect it'll be better to "Start with everything". But how do you know where to start?
Reflection Log
After a build (even most failed ones), the compiler will generate a ton of information in obj\ARCHITECTURE\Release\ilc. The "In" folder is everything passed to the compiler at the start. The Intermediates are artifacts the compiler spits out as it move through various phases.
Analysis is one of the earliest phases and any algorithm running away there will cause huge issues downstream. It's the first place I like to check. The artifacts from analysis end up in the Intermediates\ILTransformed directory. You'll have .ildll and .ilpbd files which are your app binaries twiddled a bit to make them a bit more .NET Native friendly but more importantly you'll have a collection of .csv files:
- A closure file containing a list of all the dlls your app references
- .csv with pdb and assembly info
- A file to track all forwarded types
- A file showing the result of all the decisions about which types need to be saved/generated etc due to reflection analysis
The last file is the one we're after. It'll be named Designer.reflectionlog.csv.
Example Analysis
I was tracking down a similar issue where the latest versions of System.Reactive. Here's the reflogs for a couple of different compilations:
It immediately jumps out that something has changed in 4.3. Running a diff on the logs shows a TON of entries for generics using the System.Reactive.Concurrency namespace. The "big hammer" here would be to write a directive like:
<Namespace Name="System.Reactive.Concurrency" Dynamic="Excluded" />
I suspect this is a bit heavy handed and will lead to issues when the app is run but those one offs may be easier to chase down. If not, the next step would be to go look directly at System.Reactive.Concurrency and find a subset of things to disable.
Designer
The "good" news is that Designer seems to be suffering from the same issue. The reflog for designer isn't a few hundred megs... My build has it at a quite impressive 2.5 GIGS! It's also filled with a huge amount of System.Reactive.Concurrency elements and seems completely unreasonable.
This is a follow up to this twitter thread. I've also provided some reading/suggestions in this gist. I figure this is a better text box than 280 characters at a time on twitter. 😊
I have some other tasks today that will keep me from digging in too much but maybe you can get lucky a bit given the notes below. Certainly let me know!
The Issue
The short answer is that the particular arrangement of libraries has caused .NET Native to lose it's mind and we'll need to write some hints about what types/members/namespaces can be safely ignored. Fortunately, the compiler is very generous about writing out artifacts at various stages that should make our lives easier. I'll dive into one in particular that should help us out.
The gist above describes "start with everything" and a "Start with nothing" approach. Given how things are interconnects I suspect it'll be better to "Start with everything". But how do you know where to start?
Reflection Log
After a build (even most failed ones), the compiler will generate a ton of information in obj\ARCHITECTURE\Release\ilc. The "In" folder is everything passed to the compiler at the start. The Intermediates are artifacts the compiler spits out as it move through various phases.
Analysis is one of the earliest phases and any algorithm running away there will cause huge issues downstream. It's the first place I like to check. The artifacts from analysis end up in the Intermediates\ILTransformed directory. You'll have .ildll and .ilpbd files which are your app binaries twiddled a bit to make them a bit more .NET Native friendly but more importantly you'll have a collection of .csv files:
The last file is the one we're after. It'll be named Designer.reflectionlog.csv.
Example Analysis
I was tracking down a similar issue where the latest versions of System.Reactive. Here's the reflogs for a couple of different compilations:
It immediately jumps out that something has changed in 4.3. Running a diff on the logs shows a TON of entries for generics using the System.Reactive.Concurrency namespace. The "big hammer" here would be to write a directive like:
<Namespace Name="System.Reactive.Concurrency" Dynamic="Excluded" />I suspect this is a bit heavy handed and will lead to issues when the app is run but those one offs may be easier to chase down. If not, the next step would be to go look directly at System.Reactive.Concurrency and find a subset of things to disable.
Designer
The "good" news is that Designer seems to be suffering from the same issue. The reflog for designer isn't a few hundred megs... My build has it at a quite impressive 2.5 GIGS! It's also filled with a huge amount of System.Reactive.Concurrency elements and seems completely unreasonable.