-
Notifications
You must be signed in to change notification settings - Fork 23
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
switch to File Scope Namespace, and more #27
Conversation
AoshiW
commented
Jul 3, 2023
- switch to File Scope Namespace
- small performance improvement in webSocket
- little changes
@@ -1,7 +1,7 @@ | |||
<Project Sdk="Microsoft.NET.Sdk"> | |||
|
|||
<PropertyGroup> | |||
<TargetFramework>net7.0</TargetFramework> | |||
<TargetFrameworks>net7.0</TargetFrameworks> |
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.
After reverting multiple frameworks, this can be switched back to TargetFramework
, but it's not a big deal.
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 originally wanted to add a test for current LTS .NET6 but the test failed so I removed that test for now
and someone would change TargetFramework
to TargetFrameworks
anyway in the future, so I left it there.
@Syzuna @swiftyspiffy Can you please look at this? I would add it to 2.0 release. There's nothing major changing but it improved summary commands and fixes typos. I went through this whitespace moving hell for you guys and I don't see any issues. It's mostly just shifting spaces due to File Scope Namespaces what makes this really hard to review. Overal I think this is good to go. |
{ | ||
public string Data { get; } | ||
public Exception Exception { get; } | ||
public string Data { get; } |
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 use Message
in OnMessageEventArgs
, and the type here is still string. Should this be Message
instead of Data
?
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 have a strong opinion on it, so I can change it if you want
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 would keep it consistent yeah. either change both to Data or both to Message
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.
looks good to me, comments non-blocking.
Co-authored-by: neon-sunset <[email protected]>
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.
One small comment on sth Swifty already asked about but nothing really blocking