NuGet vs Write Your Own
-
I'm curious how many people use NuGet versus write your own. I've had my own framework for 20+ years that contains a lot of things in it like Logging, Security, Event Aggregators, Service Locator, IoC Container, VM Locator, etc. I wrote these a long time ago and they're tested and in production. But a lot of these types of packages that you get off of NuGet seem to be bloated with 'features' that I don't care for or need. For example, I remember when the GalaSoft WPF Light Toolkit was truly 'light' and was the Go To package for working in WPF. Now it seems to be full of stuff I'd never use. You can eventually end up with dozens of 3rd party assemblies in your app that could end up with the 'feature bloat' and end up compiling in packages just to use 10% of it. Yet, there's value in using NuGet. If you get your packages from well known authors, like MS for example, you can be reasonably sure the package is tested in secure. You get consistency and only have to learn it once, 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? What's your thoughts?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
I'm curious how many people use NuGet versus write your own. I've had my own framework for 20+ years that contains a lot of things in it like Logging, Security, Event Aggregators, Service Locator, IoC Container, VM Locator, etc. I wrote these a long time ago and they're tested and in production. But a lot of these types of packages that you get off of NuGet seem to be bloated with 'features' that I don't care for or need. For example, I remember when the GalaSoft WPF Light Toolkit was truly 'light' and was the Go To package for working in WPF. Now it seems to be full of stuff I'd never use. You can eventually end up with dozens of 3rd party assemblies in your app that could end up with the 'feature bloat' and end up compiling in packages just to use 10% of it. Yet, there's value in using NuGet. If you get your packages from well known authors, like MS for example, you can be reasonably sure the package is tested in secure. You get consistency and only have to learn it once, 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? What's your thoughts?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
In most cases I will roll my own. I have never gone near NuGet. I rarely download and use code from CP or other places. One time I downloaded some code and used it pretty much as it was with some re-formatting -- it's really just a wrapper around a .net class. With a note about who wrote it, etc. Two other times I downloaded some code as examples of how to interact with an API, but eventually I rolled my own. P.S. Downloading a compiled DLL or similar is not the same as downloading code. When Microsoft provides some add-on as download/install compiled code, that might be OK.
-
In most cases I will roll my own. I have never gone near NuGet. I rarely download and use code from CP or other places. One time I downloaded some code and used it pretty much as it was with some re-formatting -- it's really just a wrapper around a .net class. With a note about who wrote it, etc. Two other times I downloaded some code as examples of how to interact with an API, but eventually I rolled my own. P.S. Downloading a compiled DLL or similar is not the same as downloading code. When Microsoft provides some add-on as download/install compiled code, that might be OK.
PIEBALDconsult wrote:
I have never gone near NuGet.
Do you only write code for mainframes and Commodore 64s? :rolleyes: 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? :thumbsup: 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.
-
In most cases I will roll my own. I have never gone near NuGet. I rarely download and use code from CP or other places. One time I downloaded some code and used it pretty much as it was with some re-formatting -- it's really just a wrapper around a .net class. With a note about who wrote it, etc. Two other times I downloaded some code as examples of how to interact with an API, but eventually I rolled my own. P.S. Downloading a compiled DLL or similar is not the same as downloading code. When Microsoft provides some add-on as download/install compiled code, that might be OK.
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. :-D
"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!
-
I'm curious how many people use NuGet versus write your own. I've had my own framework for 20+ years that contains a lot of things in it like Logging, Security, Event Aggregators, Service Locator, IoC Container, VM Locator, etc. I wrote these a long time ago and they're tested and in production. But a lot of these types of packages that you get off of NuGet seem to be bloated with 'features' that I don't care for or need. For example, I remember when the GalaSoft WPF Light Toolkit was truly 'light' and was the Go To package for working in WPF. Now it seems to be full of stuff I'd never use. You can eventually end up with dozens of 3rd party assemblies in your app that could end up with the 'feature bloat' and end up compiling in packages just to use 10% of it. Yet, there's value in using NuGet. If you get your packages from well known authors, like MS for example, you can be reasonably sure the package is tested in secure. You get consistency and only have to learn it once, 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? What's your thoughts?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
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. :-D
"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!
-
PIEBALDconsult wrote:
I have never gone near NuGet.
Do you only write code for mainframes and Commodore 64s? :rolleyes: 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? :thumbsup: 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.
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.
-
I'm curious how many people use NuGet versus write your own. I've had my own framework for 20+ years that contains a lot of things in it like Logging, Security, Event Aggregators, Service Locator, IoC Container, VM Locator, etc. I wrote these a long time ago and they're tested and in production. But a lot of these types of packages that you get off of NuGet seem to be bloated with 'features' that I don't care for or need. For example, I remember when the GalaSoft WPF Light Toolkit was truly 'light' and was the Go To package for working in WPF. Now it seems to be full of stuff I'd never use. You can eventually end up with dozens of 3rd party assemblies in your app that could end up with the 'feature bloat' and end up compiling in packages just to use 10% of it. Yet, there's value in using NuGet. If you get your packages from well known authors, like MS for example, you can be reasonably sure the package is tested in secure. You get consistency and only have to learn it once, 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? What's your thoughts?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
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; -
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.
-
PIEBALDconsult wrote:
I have never gone near NuGet.
Do you only write code for mainframes and Commodore 64s? :rolleyes: 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? :thumbsup: 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.
raddevus wrote:
Do you only write code for mainframes and Commodore 64s?
:laugh: :thumbsup:
-
I'm curious how many people use NuGet versus write your own. I've had my own framework for 20+ years that contains a lot of things in it like Logging, Security, Event Aggregators, Service Locator, IoC Container, VM Locator, etc. I wrote these a long time ago and they're tested and in production. But a lot of these types of packages that you get off of NuGet seem to be bloated with 'features' that I don't care for or need. For example, I remember when the GalaSoft WPF Light Toolkit was truly 'light' and was the Go To package for working in WPF. Now it seems to be full of stuff I'd never use. You can eventually end up with dozens of 3rd party assemblies in your app that could end up with the 'feature bloat' and end up compiling in packages just to use 10% of it. Yet, there's value in using NuGet. If you get your packages from well known authors, like MS for example, you can be reasonably sure the package is tested in secure. You get consistency and only have to learn it once, 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? What's your thoughts?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Nuget - so we don't reinvent the wheel. Roll our own if it is specific only for our applications and websites, etc.
-
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. :-D
"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 :elephant:-ton of "objects" which I have no use for. In both cases, I can then send the XML to SQL Server for further processing.
-
I'm curious how many people use NuGet versus write your own. I've had my own framework for 20+ years that contains a lot of things in it like Logging, Security, Event Aggregators, Service Locator, IoC Container, VM Locator, etc. I wrote these a long time ago and they're tested and in production. But a lot of these types of packages that you get off of NuGet seem to be bloated with 'features' that I don't care for or need. For example, I remember when the GalaSoft WPF Light Toolkit was truly 'light' and was the Go To package for working in WPF. Now it seems to be full of stuff I'd never use. You can eventually end up with dozens of 3rd party assemblies in your app that could end up with the 'feature bloat' and end up compiling in packages just to use 10% of it. Yet, there's value in using NuGet. If you get your packages from well known authors, like MS for example, you can be reasonably sure the package is tested in secure. You get consistency and only have to learn it once, 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? What's your thoughts?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
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=onThere 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. -
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=onThere 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; -
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.
-
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'm curious how many people use NuGet versus write your own. I've had my own framework for 20+ years that contains a lot of things in it like Logging, Security, Event Aggregators, Service Locator, IoC Container, VM Locator, etc. I wrote these a long time ago and they're tested and in production. But a lot of these types of packages that you get off of NuGet seem to be bloated with 'features' that I don't care for or need. For example, I remember when the GalaSoft WPF Light Toolkit was truly 'light' and was the Go To package for working in WPF. Now it seems to be full of stuff I'd never use. You can eventually end up with dozens of 3rd party assemblies in your app that could end up with the 'feature bloat' and end up compiling in packages just to use 10% of it. Yet, there's value in using NuGet. If you get your packages from well known authors, like MS for example, you can be reasonably sure the package is tested in secure. You get consistency and only have to learn it once, 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? What's your thoughts?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
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'm curious how many people use NuGet versus write your own. I've had my own framework for 20+ years that contains a lot of things in it like Logging, Security, Event Aggregators, Service Locator, IoC Container, VM Locator, etc. I wrote these a long time ago and they're tested and in production. But a lot of these types of packages that you get off of NuGet seem to be bloated with 'features' that I don't care for or need. For example, I remember when the GalaSoft WPF Light Toolkit was truly 'light' and was the Go To package for working in WPF. Now it seems to be full of stuff I'd never use. You can eventually end up with dozens of 3rd party assemblies in your app that could end up with the 'feature bloat' and end up compiling in packages just to use 10% of it. Yet, there's value in using NuGet. If you get your packages from well known authors, like MS for example, you can be reasonably sure the package is tested in secure. You get consistency and only have to learn it once, 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? What's your thoughts?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
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 :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
PIEBALDconsult wrote:
I have never gone near NuGet.
Do you only write code for mainframes and Commodore 64s? :rolleyes: 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? :thumbsup: 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.
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
-
I'm curious how many people use NuGet versus write your own. I've had my own framework for 20+ years that contains a lot of things in it like Logging, Security, Event Aggregators, Service Locator, IoC Container, VM Locator, etc. I wrote these a long time ago and they're tested and in production. But a lot of these types of packages that you get off of NuGet seem to be bloated with 'features' that I don't care for or need. For example, I remember when the GalaSoft WPF Light Toolkit was truly 'light' and was the Go To package for working in WPF. Now it seems to be full of stuff I'd never use. You can eventually end up with dozens of 3rd party assemblies in your app that could end up with the 'feature bloat' and end up compiling in packages just to use 10% of it. Yet, there's value in using NuGet. If you get your packages from well known authors, like MS for example, you can be reasonably sure the package is tested in secure. You get consistency and only have to learn it once, 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? What's your thoughts?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
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.
