-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CNX-8397-DLL-Conflict-Handling in existing DUI2 connectors #3273
Conversation
</PropertyGroup> | ||
|
||
<ItemGroup> | ||
<PackageReference Include="System.Text.Json" Version="4.6.0" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to @BovineOx and my future self. We may want to consider using Speckle.Newtonsoft considering many more people will use System.Text.Json in varying versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ha, yeah that's interesting, because System.Text.Json is becoming the more mainstream package, though there are still gaps, but maybe so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been poking around this new feature in debug and I have a couple considerations:
- When a user sees this pop-up, it is unclear what they are expected to do about it.
- It is unclear what the consequences are of "not warning about this again"
- The checkbox to not warn will apply to each conflict individually, but users can't individually choose which ones to ignore
- From Matteo: We should have metrics on when does this pop-up get shown, how many conflicts we find or not, etc...
Further discussions may be needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was checking the data in MP:
- the
distinct_id
should either beundefined
or yours, but it has some other value - the
allDetectedConflicts
value should be a list of objects, but it's a list of strings identifiedConflictingAssemblyName
and some other props you're adding are null, not sure if this is correct?
the distinct id's that you're probably seeing are when I was using a fallback value that didn't come from the accounts (you should know that I pulled this fallback value from the existing Analytics class, so this alternate distinct_id may be being used already). I have changed this and have hard-coded an id of "undefined" for the "lite" version of the analytics. some system object types (System.Type, System.Reflection.AssemblyName, System.Reflection.Assembly) were throwing when attempting to be serialized so I just made a custom serialization to string. However, I have now implemented a data transfer object which has good serialization behavior, and I am sending that object instead of just a string. identifiedConflictingAssemblyName can be null if a single conflict was not identified to be the culprit of a thrown exception. Is there a more clear way to handle this? Here is an example of a couple events. The first is a "DllConflictsDetected" event and the second is a "DllConflictExceptionDialogShown" event |
For this we could have a blog post and a link to that. |
There's already a docs page about dll conflicts, if you want to link to it we can add some more explanation about the dialog... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see much blockers. Just one class that should be in it's own file, and a question about the autodesk specific method
ConnectorCore/DllConflictManagement/Analytics/AnalyticsWithoutDependencies.cs
Outdated
Show resolved
Hide resolved
[System.Diagnostics.CodeAnalysis.SuppressMessage( | ||
"Design", | ||
"CA1031:Do not catch general exception types", | ||
Justification = "Catching all exceptions to avoid an unobserved exception that could crash the host app" | ||
)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting... could we do something like IsFatal
here (though not directly that as it would require referencing something else)
private static string GetPathFromAutodeskOrFullPath(string fullPath) | ||
{ | ||
string[] splitOnAutodesk = fullPath.Split(separator, StringSplitOptions.None); | ||
|
||
if (splitOnAutodesk.Length == 2) | ||
{ | ||
return splitOnAutodesk[1]; | ||
} | ||
return fullPath; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Autodesk specific? 🤔 Ideally this project should work on any connector. Not a deal breaker, just found it weird.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're looking good! We should make a WIP to really test this in the wild (maybe ping some DPs and users we know have had conflicts in the past?)
My understanding is that Matteo has already given his blessing to this, though not officially through the PR. So I'm dismissing this to get it through
Description & motivation
Changes:
Added DllConlfictManagement project
DllConflictManager
DllConflictUserNotifier
DllConflictManagmentOptions
RevitExternalApplication
To-do before merge:
Questions to be answered (probably by @AlanRynne)
Where in appdata should I keep options.json file? Can this be the same for all c# connectors that use this?Currently I'm only trying to catch typeLoadException and MissingMethodException. Are there others that will be thrown when dll mismatch occurs?I'm only catching the above exceptions in the plugin initialization. I'm thinking we also want to catch these for the operations. Is this needed / is it okay to do?How to log while detecting plugin conflicts? Should I prioritize logger dependencies and then move to connector dependencies?I'm referencing the System.Text.Json nuget in the new project because it isn't built into .net standard. Should I reference a really new version or a really old version of this?Screenshots:
Validation of changes:
Checklist:
References