On a related note, this is a change in behavior from the ActivationFactory PR. Does it matter what Assembly we pass here?

"this is a change in behavior from the ActivationFactory PR. Does it matter what Assembly we pass here?"

Yeah I think that PR did change the behavior there. I can't really imagine what difference that would make though, other than... Maybe like, you have an app that's dynamically loading some plugin .dll that's in some other folder, and that .dll tries to activate some WinRT type that's in a .dll that's next to that .dll, and not to your app's .dll? Not sure if that matters? 🤔

"this is a change in behavior from the ActivationFactory PR. Does it matter what Assembly we pass here?"

Yeah I think that PR did change the behavior there. I can't really imagine what difference that would make though, other than... Maybe like, you have an app that's dynamically loading some plugin .dll that's in some other folder, and that .dll tries to activate some WinRT type that's in a .dll that's next to that .dll, and not to your app's .dll? Not sure if that matters? 🤔

Yea I can see maybe some plugin scenarios being impacted. Will need to monitor for any failures or reports. The change to AppContext.BaseDirectory from several releases ago was more likely to run into similar issues here but never got any reports there.