The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Oh yes. When I write code, I write it with an eye to "generalization" so that it can be moved into a library - and I have have several just for C#, each containing different but related material - once it's shown to work and can be properly tested.
If you don't keep libraries of "good code" then you will be re-inventing the wheel far, far, too much.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
I'm in the same boat. My "goodies" library lives inside a single DLL that doesn't have any external dependency, so I can very easily add it to any project.
For years I went out of my way to have it target .NET 2.0 (what I've considered to be the lowest common denominator), but I've "upgraded" it to target .NET 4 last year or so only because 2/3.5 are no longer installed by default on the newer OSes. But, it still doesn't rely on anything from .NET 4; I could retarget it for .NET 2 and it would still compile.
I don't use interfaces nearly as much as I should, but I make sure function signatures don't change from one version to the next...so in theory whenever I add/fix something in the DLL, I can drop in the replacement file and all my apps should continue to work.
If it gets more complex than that, then it doesn't belong in my utilities library.
Yes I do. For Android (some .aar libraries) and C#. Couldn't do without it. Sometimes you have to find the edge of "how closely are these and those classes related to each other" and decide, whether to put them in one library together (which means more memory usage / download size, especially on mobile platforms) or to split them (which means, more references, maybe more builds, a bit more organizational work in the project structures).
In most cases I prefer to do more, but smaller libraries, than to do one single dinosaur who "eats everything". It adds flexibility on the cost of a bit more time to set up a new project. But the setup is done once... the memory is used every time the app starts.
Exception is my WinForms library, but the past showed, that indeed most of the classes in there are used in each of my winforms apps.
I strictly divide code into "Business logic" - which means, code that "does the job of the app" and "everything else". As long as I have not made the "everything else" code as generalized as needed to be library-ready I consider it a prototype. I have finished platform (non-business) code of my app when I have succesfully outsourced it to a library project. not a minute sooner.
I have a couple of libraries (being primary a SharePoint Developer), I’ve got a Common, Winforms, ASP.NET and SharePoint libraries (including unit tests) which I’ve built up over the years of consulting.
Anything that can be generalized is added to the library. Some of it even ends up as articles. But the backlog seems to be growing, mundane things such as family, work and procrastination, tends to get in the way.
I have a tiny one for automating view and viewmodel comms, and lots of share code in base classes in my framework. So far I still just Copy-Paste the first steps from the previous project. It is a framework, but only within each new project and not yet ready as a proper stand-alone framework.
Any technical (vs. business) code should always be a library. (Others touch on this as well)
In addition, create a Façade (at the minimum) for any System or Third Party library that is not part of the deep core of the language or that is heavily used in the business layer. This protects business logic from platform upgrades or Third Party changes.
I think it is natural to develop a "code library" of sorts for the things that should be easier, but are not, or the things like Logging which need different implementations depending on the type of application, etc.
Sometimes, just wrapping an outside tool so we all use it in a consistent manner.
Logging, and Timing come to mind. We add those to every project.
Then we have impersonation things we do all the time in web frameworks so we can test specific user features/paths.
It all feels like a framework at some point, because we know it is going to be in there, but it is really a set of libraries and approaches, so we are not locked in too far.
For those of us that do keep a reusable framework around, how do we like to organize it? - Create a personal NuGet package? - Keep a Visual Studio project around that gets included into each project that uses it? - Keep a folder full of *.cs files that get copied into a project when needed? - Keep a *.dll (or folder of them) to reference without looking at the source code?
if it's a dog performing mark-up, that's grrrfitto.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
I have been using this one for several years now: [^] This has very good support of the different possible file sources (network to access directly the HD of my DSL box, the sdcard of the phone, or the phone content itself), does a very good job at copying/cutting etc...
I second that File Manager, but recommend the original version when it was still Rhythm Software. I set my Android devices to not auto update and have preserved old versions of APKs. Including the original ES File Explorer that had the backup capability in the free version! You can grab 'em from here[^]. All the APKs are free versions of the apps.
folks on agents of sheild said the same thing in the last ep too; then again in aos they did have scenes a few months back with a female potus, and even included side comments along the likes of 'lucky people didn't vote for that guy.' LOL LOL
Sin tack ear lol Pressing the any key may be continuate