Adding PropertyChange.Fody to WPF project results in various native memory issues

[timbilt]

First of all please pardon me if this format is a little bit off --- I am trying to stick to the format and provide as much info as possible.

I am using Visual Studio 2019 (MSBUILD 16.0) and have a solution that has a few projects.

2 Core base projects: .NET standard 2.0
All other projects: .NET Framework 4.7.2

Some of the base projects control hardware devices via SDKs

Base classes that implement INotifyPropertyChanged exist in both .NET Standard 2.0 projects.

Intermediate base classes exist in a .NET Framework 4.7.2 project

All concrete implementations are in the main WPF project which is .NET Framework 4.7.2

1. Install PropertyChanged.Fody via NuGet package manager ONLY in the WPF main project
2. (Optional) Add [assembly: PropertyChanged.FilterType("My.Specific.OptIn.Namespace.")] to disable injection
3. Start application
4. Calls to 3rd party library that uses native memory start to fail with random memory errors consistently.

Due to the nature of the hardware projects that are failing, it's hard to reproduce in a sample app. Does this have something to do with the fact that 2 base projects are .NET Standard 2.0? Do I have to use specific versions of PropertyChanged.Fody in each project?

[SimonCropp]

can u re read the issue template and take all the required steps https://github.com/Fody/.github/blob/master/.github/ISSUE_TEMPLATE/bug_report.md

[timbilt]

can u re read the issue template and take all the required steps https://github.com/Fody/.github/blob/master/.github/ISSUE_TEMPLATE/bug_report.md

Sorry. Updated --- trying to do the best format. What's annoying is that even if I essentially disable the weaver via the filter attribute by specifying only a non-existing namespace, the hardware projects still throw exceptions.

[SimonCropp]

can you share a minimal stand alone solution that reproduces this issue?

[timbilt]

I will try. But in the mean time can I at least get a suggestion?

[BrunoJuchli]

Suggestion: compare the IL of your assembly when PropertyChanged.Fody is enabled and when it's disabled. Check to see if anything else than your ViewModels is affected.
The opt out might not work ([assembly: PropertyChanged.FilterType("My.Specific.OptIn.Namespace.")]).

Another idea: somehow the lifecycle of your native memory stuff is associated with the View Models. Adding property changed notifications might keep VM's from being garbage collected (even if they should be) and this might lead to errors (though in that case I'd rather expected out-of-memory than anything else).

One more would be that WPF accesses properties which in turn access native memory after you've freed the memory.
(Again, the opt-out might now have worked/be buggy?)

[timbilt]

Taking a look with a memory profiler, I found something very interesting. When the process builds normally without PropertyChanged.Fody, the maximum addressable memory is 4GB, however with PropertyChanged.Fody it is 2GB. The application btw is compiled with ANYCPU + Prefer32 bit which I think adds the /LARGEADDRESSAWARE build flag by default. This process needs to address 4GB. How do I get the package to make sure that happens?

Btw, I found this out by simply draining the memory to see at what level the app crashes. So 4GB without Fody, 2GB with Fody.

[timbilt]

I have confirmed that PropertyChanged.Fody does in fact affect the flags that the application get's compiled with.

Before (ANYCPU + Prefer 32)

After (with Fody)

My workaround was to install the LargeAddressAware NuGet package and add the following properties to my .csproj
<PropertyGroup> <LargeAddressAware>true</LargeAddressAware> <LargeAddressAwareAfterTargets>FodyTarget</LargeAddressAwareAfterTargets> </PropertyGroup>
The target from this Nuget Package only runs if you set your Platform Target to x86 in your project properties.

It would however be nice if Fody would not have led to this unexpected change to begin with. Please fix.

[SimonCropp]

@timbilt this looks like a bug in cecil. can u raise an issue here https://github.com/jbevain/cecil

[SimonCropp]

@jbevain fyi

[tom-englert]

Looks like this is already reported: jbevain/cecil#620

[SimonCropp]

ok given this is tracked upstream, i will close this