|
PIEBALDconsult wrote: I have never gone near NuGet.
Do you only write code for mainframes and Commodore 64s?
Honestly, I don't know how you could create much code even over a lifetime as a software developer doing this? I mean there really isn't enough time to create Complete Products without using others' libraries, I don't think.
I am a minimalist though too & things like npm really pain me since I started out "back in the day" writing Win3.1 / Win95 Windows SDK programs.
And, none of this is meant as a knock, I'm just saying I don't know how a dev could create Complete Solutions without using OPC (other people's code).
Came Back for EDIT
Oh, I'm guessing that you are actually an embedded software dev, right?
Again, just curious.
Edit 2
I took a look at some of your articles. Very interesting stuff & I see that you're doing C# work.
I was thinking you meant that even C# libraries weren't something you were using so I was confused.
But now I see that you're saying you use the BCL (base class libraries) the stuff "included" in the box but not the other stuff from other authors out on nuget. Makes sense now.
modified 5-Dec-22 16:14pm.
|
|
|
|
|
raddevus wrote: I mean there really isn't enough time to create Complete Products without using others' libraries
If you're staring from scratch, I would agree. But like I said, I have my own framework with dozens of classes that handle almost all the generic/repeatable code. So for me, creating a new app is mostly app-specific stuff.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: I have my own framework with dozens of classes that handle almost all the generic/repeatable code. So for me, creating a new app is mostly app-specific stuff.
That's very cool.
What stack do you use...for example...
OS: Windows
IDE: Visual Studio Code
Language: C#
Platform: Windows Forms
OS: macOS
IDE: XCode
Language: Swift
Platform: iPhone apps
OS: Linux
IDE: AndroidStudio
Language: Kotlin
Platform: Android apps
OS: Linux
IDE: Visual Studio Code
Language: JavaScript, HTML, CSS
Front-End Lib: React
Back-End: C# ASP.NET Core WebAPI
Platform: PWA (Progressive Web Apps)
Just curious.
|
|
|
|
|
Primarily
OS: Windows
IDE: Visual Studio Code
Language: C#
Platform: WPF
Secondary
I'm learning .Net MAUI, so I've started a framework for that also
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
raddevus wrote: Do you only write code for mainframes and Commodore 64s?
|
|
|
|
|
Because if I try to place a NuGet package in anything that goes onto a vehicle I get fired, if someone approves it in the codebase he gets fired too and so on.
Also, the Log4J clownshow apparently didn't teach anything.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Mostly, I roll my own.
But ... Nuget packages I do use include the HTML Agility pack and Newtonsoft.Json - brilliant stuff that saves weeks of work. There are others, but I don't have VS on my Surface ATM so I can't easily check what they are.
It's like anything else: there are good packs and bad packs, good games and bad games, good libraries and bad libraries, good YouTube videos and absolutely terrible. All you can do is try to pick out the diamonds from a sea of dross.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: HTML Agility pack
I tried using that for something once. Once. It didn't solve any problems I had. I didn't get it from NuGet.
If I recall correctly, it was because I was (am?) receiving some very broken HTML which I couldn't read as XML. I think I wrote my own repair tool to convert broken the HTML to well-formed XHTML. I may have posted a question about it at the time.
OriginalGriff wrote: Newtonsoft.Json
I've seen it mentioned, but I'm waiting for Microsoft's version, which will also likely not solve any problems I have.
Basically, for JSON, all I want is something to convert JSON to XML on-the-fly, I absolutely positively do not want it to create an -ton of "objects" which I have no use for.
In both cases, I can then send the XML to SQL Server for further processing.
|
|
|
|
|
The vast majority of my work stuff is self-rolled. The exceptions are things too complicated to implement myself and are unequivocally free for use in a commercial setting. This is mostly so I don't have to deal with the corporate legal folks.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: so I don't have to deal with the corporate legal folk
Oh, yeah, I forgot about that. Any "packages" would have to be vetted by security.
rant-mode=on
There is a team for desktop and a team for server, and they cannot be relied on to agree on which one version of something to approve.
One of our sources was (is?) using MySQL, and we had downloaded the .net Connector (not from NuGet) and it was good.
Then the server team decided we needed a newer version and the desktop team said they were still working on approving it, but by the time they did they had approved yet a newer version. We have had no access to that data since February of 2018 because of idiotic corporate policy.
|
|
|
|
|
PIEBALDconsult wrote: no access to that data since February of 2018 That definitely out-stupids my bunch.
Software Zen: delete this;
|
|
|
|
|
Nuget - so we don't reinvent the wheel.
Roll our own if it is specific only for our applications and websites, etc.
|
|
|
|
|
Slacker007 wrote: Nuget - so we don't reinvent the wheel.
My concern with using NuGet is that there are a lot of 'wheels' out there. We've all seen apps that are inundated with 3rd party assemblies/source code. It can be overwhelming to manage and bloat & security are concerns.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I also have decades of libraries. By writing my own I maintain backwards compatibility with older code as well. I'll even not use the generated code from VS for WinForms apps as this code is buggy and doesn't handle edge cases worth a darn.
|
|
|
|
|
Being a solo developer I don't mind using NuGet packages. As other have said it saves time and not reinventing the wheel.
I don't need many, I use MailKit for email functions, Newtonsoft.Json which has been a live saver, and there's no way I could have written anything like Sharepoint.CSOM.
But then I didn't use CloseXML, I preferred developing my own libraries when doing OpenXMl.
// TODO: Insert something here Top ten reasons why I'm lazy
1.
|
|
|
|
|
I never Nuget.
No insecure libraries in my codebase, nor does my product sink if a nuget-dev dies.
No dependencies. Ask Joel.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I never use NuGet.
Most of the code I write is application-specific, therefore roll-you-own. In the few cases that I download code (e.g. for hash calculations etc., where compatibility with other code it critical), I will download it from a reliable source, preferably one that uses the MIT license (or similar).
Viral licenses such as GPL are absolutely forbidden at work for anything that might go to a customer.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
NuGet is definitely useful for some areas such as Newtonsoft for dealing with JSON and APIs.
At work we have our own NuGet repository so that we can use our own standard libraries.
With my personal projects I make use of NuGet if I know that there is an area already covered that I don't need to rewrite such as Newtonsoft.
I would probably use it more in a personal capacity, but much of my personal work is with Typescript and React where I do make extensive use of npm and have to be careful because using the wrong version of an npm library can break everything else.
βThat which can be asserted without evidence, can be dismissed without evidence.β
β Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: At work we have our own NuGet repository
Same here for our home grown assemblies.
|
|
|
|
|
Why not both? You can publish your own packages to a private NuGet feed, which avoids having to reference them from a relative path (prone to breakage) or install them in the GAC (which no longer exists in .NET Core/5/6/7/...).
If you don't want to host your own server, you can set up an "artifacts" feed on Azure DevOps and publish to that.
Azure Artifacts | Microsoft Azure[^]
But from your question, I'm guess you're actually asking "do you use third-party code or roll your own", which is a different question.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I do bunch of Azure functions work. Although microsoft last 5 something years they really driven the splitting up packages, so something which was 1 like storage, is now 3.
go tos because used to, and easy to explain to juniors to use
MOQ, fluent assertions
Newtonsoft I try to replace in existing projects where I can, the defaults for System.Text.Json just ahh I understand why but I dont want it like that.
ftp/sftp/email (like some other protocols as well) - use a package if need interaction, I do not want to repeat relearning mistakes with handling these things reliably.
most other things, logging Im fine and prefer defaults provided, azure logging π. Logging to a file: handful of methods in a class file I would prefer over log4X, by which at deploy find that some setting not working. Package functionally, sounds great, I want it the same format across all things so all them bells just dead weight
As someone else pointed, sounds like most OP work embedded systems, which just a whole different level of wow to me, and would see looking at a 10kb package add to do something which only need one functionality from, could write in under a 1kb class.
Webpage work, very much been trying to write in browser games with own code, no 5MB of packages.
|
|
|
|
|
I don't like NuGets, but I have to use them. Microsoft stuff, Newtonsoft, Oracle, Informix, proprietarily libraries etc.
In my previous job NuGets were the bread and the butter. Here is the rant: The Lounge[^]
There is only one Vera Farmiga and Salma Hayek is her prophet!
Advertise here β minimum three posts per day are guaranteed.
|
|
|
|
|
I use NuGet quite a bit. I think carefully about what dependencies are worth adding to a project. I'll never add a package carelessly. I think being productive in .NET means using NuGet packages wisely. If you want to be a senior or principal level developer in a typical corporate environment, it's not a good use of your time to re-invent stuff like logging or an IoC container or security/authorization IMO.
There is a time and place for doing low-level invention when it helps you think through a fundamental problem, and get some insight or appreciation for how certain low-level services work. ORM is a good example, and one area where I'm a hypocrite. (This came from legit unhappiness with Entity Framework.)
>>Sometimes someone refers me to a package from some developer, and I think "What's in this? Is it secure? What benefit do I get from adding another assembly versus use code I already have?<<
Certainly it depends on the package, but I think you have to be honest with yourself about how much time you have and how much you're trying to achieve. I would be very surprised/skpetical if a lone developer believes he has code already written for every single problem he encounters. Just yesterday I was implementing html email. This typically requires inlining CSS because typical mail clients don't respect stylesheets. A package like Premailer.Net makes this very easy. There is no reason to invent this myself. I could think of a dozen situations like this.
I have a few NuGet packages myself, as there are a few areas where I was truly unhappy with the status quo and wanted to offer my own solution. But I've made quite a number of ridiculous packages also, if you go through my public packages. (They are a bit hard to delete on NuGet.org.)
|
|
|
|
|
I may pull a NuGet package while working out the early stages of something - fast. But I agree with you, I want something
to do what it is supposed to do and nothing more. No need
having tons of options I don't need (do I really need my
logging process to receive emails?). In the end if I do not
already have a utility process then I will write it.
|
|
|
|
|
A combination of both, including publishing my own libraries to nuget.org so I don't have to rewrite the same thing over and over, or, equally bad: copy-paste code between projects. The latter comes back to bite you when project diverge and you can't share fixes / enhancements any more (I've seen this on copy-pasted code at my work).
My first nuget packages literally were so that I wouldn't have to write the same code twice - and that legacy continues. I don't think any of my packages have been used in only one place, and not having a central source of truth that can be fixed and easily propagated seems like a crazy idea to me.
Libraries that I've made & found immensely useful across multiple apps include:
- a duck-typer (duck-type objects or dictionaries to well-defined interfaces)
- an ini file reader/writer
- a management class for windows services (start/stop/restart/install/uninstall, etc)
- container/manager for spinning up temporary databases for testing (mssql, mysql, sqlite, sqlce) & cleaning up once disposed
- temporary http server, again for unit testing - spin up, add handlers, disposable pattern
- an easy-to-use commandline arguments parser / mapper-to-an-object (because there was one that I liked, and the dev updated & broke things, and I thought "nuts, I can make that and have control over it"
- miscellaneous utils like auto-deleting (via disposable pattern) temp files/folders, common reflection-based functionality, easy parallelisation, easy interaction with a sub-process (esp the I/O part), and some more
For testing, I would imagine that you're either not rolling your own unit test & assertion frameworks every time, or you're just not testing. I wanted smarter assertions that felt similar to JS-land ones, so I wrote NExpect.
I'm happy to use nuget packages that are well-maintained & documented. I don't think anyone can do web work these days without nuget - I really don't think anyone is writing web servers from the ground up? Surely?
------------------------------------------------
If you say that getting the money
is the most important thing
You will spend your life
completely wasting your time
You will be doing things
you don't like doing
In order to go on living
That is, to go on doing things
you don't like doing
Which is stupid.
|
|
|
|
|