-
Notifications
You must be signed in to change notification settings - Fork 9
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
Target .Net Standard 2.0 #33
Conversation
Codecov Report
@@ Coverage Diff @@
## master #33 +/- ##
==========================================
- Coverage 47.86% 47.73% -0.13%
==========================================
Files 26 26
Lines 796 796
==========================================
- Hits 381 380 -1
- Misses 415 416 +1
Continue to review full report at Codecov.
|
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.
Is there anything left TODO here? Since this is a draft PR
Thanks. No, there shouldn't be anything left to do. I created it only as draft because I thought you might want me to make some changes after first review. I've marked my other 2 PRs as ready for review now as well. |
5a029cc
to
c6d9a92
Compare
Thanks, awesome size reduction! |
Hmm, it seems like newer versions of the PowerShell SDK are not compatible with .netstandard but only .netcore? https://travis-ci.org/felixfbecker/PSKubectl/builds/567063841#L745 |
I would not update the PS SDK until 6.1 is deprecated. You don't need to reference 6.2 for it to work on 6.2. One would only need to reference it if you use APIs that are only available in newer versions. I can take a look at the issue briefly but I think you might be able to dump the SDK and replace it with SMA but I cannot say that for sure until I've looked at what APIs you use |
Ah, makes sense. |
System.Management.Automation |
Would it help to add some commands to build.ps1? E.g. delete unneeded DLLs |
Usually one just takes the output from |
Hmm I don't know if it's worth the maintenance burden. Is module size really a concern? |
module size means slower installation and generally just lots of space that accumulates. We optimised already 90MB away with the .Net Standard2.0 tweak, so one could argue that we should follow the 80-20 rule and stop here since the additional improvement of is much smaller now. I'll try to see if there is a way using |
🎉 This PR is included in version 0.11.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
API's are nearly the same in terms of behaviour, the only lost functionality to cancel the async reading of the file.
This also highly reduced the size of the module from around 160 MB to 10MB
In practice one could even look at it in detail and exclude most DLLs (as PowerShell provides most of them therefore only DLLs from the project itself and it's NuGet packages are technically needed.