Changing GUIDs in app.config is not recommended

[mzomparelli]

I see now why you modify app.config manually. It's not always this easy and I think this is why you got stuck on the 22621.2215 change.

If the underlying interface changes in such a way (members added or removed) then simply changing app.config will not fix it. Usually when the GUIDs change then there is an underlying interface change we should examine.

While changing app.config might work sometimes, it may not and could lead to a MemoryAccessViolation due to the interface offsets being different due to a change in members.

app.config is created during the build process and the info is take from Settings.settings.

I recommend removing this part and encouraging users to open an issue so we can investigate. This way we hear about it and can check for changes to ensure it'll work.

[mzomparelli]

No user should be presented with a MemoryAccessViolation and having them modify the GUIDs could lead to that.

[mzomparelli]

The best solution would be to always test insider builds and catch changes before they are in the public releases. This way the DLL always works and users never have to search for GUIDs. Probably only need the beta build (whatever that one is), the insider closest to the public release.

[mzomparelli]

Even if the new GUIDs work, then you could still get undesired results. When a member is changed or removed in the middle of the interface then a new GUID might work but it might not be aligned correctly. In a rare scenario this could lead to calling where you think the member is but it's actually not there. It's 4 bytes down now. This could lead to bad results like unintentionally calling a member when you meant to call a different one.

I do not recommend changing the GUIDs until you examine the changes in the interface. If the GUIDs changed then something changed in the interface. If added to the end then you're ok. This is not always the case though as the 22621.2215 proved.

[Slion]

I see now why you modify app.config manually. It's not always this easy and I think this is why you got stuck on the 22621.2215 change.

I got stuck because I had broken assembly generation when first implementing minor OS Build version support.

[Slion]

I think the key to get settings wizard to generate proper app.config is to specify the type as System.Collections.Specialized.StringCollection.

[Slion]

If the underlying interface changes in such a way (members added or removed) then simply changing app.config will not fix it. Usually when the GUIDs change then there is an underlying interface change we should examine.

While changing app.config might work sometimes, it may not and could lead to a MemoryAccessViolation due to the interface offsets being different due to a change in members.

Very true, if you only change the UIDs when adding support for a new version then you can only hope that the changed interfaces remain somewhat compatible. The proper way to do it is indeed to provide the new interfaces signatures after reverse engineering.

[Slion]

I recommend removing this part and encouraging users to open an issue so we can investigate. This way we hear about it and can check for changes to ensure it'll work.

The part about obtaining the Windows version should remain somewhere.

The part about getting the UIDs from the registry should ideally be replaced with the proper reverse engineering documentation. This is about documenting how to get it done for ourselves and possible future maintainers. Ideally I would love to see that Python script ported to C# and incorporated in the project itself so as to make it easier to get the job done. Obviously it would be great if we could automate the whole process of generating the C# interface files for a new version of Windows but I understand that could be rather challenging and time consuming.

[mzomparelli]

The python script is good enough, but I will see if I can convert to c#. My fork of that is already better as I dump the IApplicationView vftable even though IApplicationView has not changed since Win10 1809. It did show me the names of all those Unknowns everyone had. I'll try to document the reverse engineering steps so we can add to the readme.

Hasn't settings been System.Collections.Specialized.StringCollection the entire time? Or was it just an ordinary StringCollection?

[mzomparelli]

We could probably do away with Settings.settings and only use app.config manually modified by us.

[Slion]

Hasn't settings been System.Collections.Specialized.StringCollection the entire time? Or was it just an ordinary StringCollection?

I think you get the HTML entities in app.config when you set them as strings in the settings. Which for some reason won't even run properly on my PC. It throws an exception when trying to cast them to StringCollection.

We could probably do away with Settings.settings and only use app.config manually modified by us.

I don't mind. I'm ok with what we have ATM. Not perfect but ok. I know I have to keep an eye open for scrambled app.config to make sure the diffs are readable and ensure code review can be effective in such critical part of the system.

[mzomparelli]

[mzomparelli]

Even though is says String it is in fact XML

[mzomparelli]

pretty please add me as an Author on your next commit

[Slion]

pretty please add me as an Author on your next commit

Done