I am wondering what is the best way to construct a common utilities library that can be used in different projects. I am using .Net and C#.
Should I create a separate project for each utility such as Logging, Authentication, Excel etc. and release them separately along with dependencies or should i include all utilities in one common utils assembly along with all dependencies bundled and only reference the necessary dependencies in projects that use the common utils?
I would probably figure out what functionality you want to provide (at least generally) and then define a logical namespace hierarchy around that. Once you've got the overarching definition, you should be able to create all of the library files and structure the modularity of it so you don't have one behemoth "everything" library but can instead have things like "your file/directory helper assembly".dll, "your DB wrapper assembly".dll, "your UI component assembly".dll, etc.
It depends on two things.
First, what's the relationship between the things you're bundling together? Does it make sense to put them in a library together?
Second, what's the usage model? If it's a set of standard utilities you link with every project it makes sense to have them together, but if you're using a runtime plug-in style model where you dynamically load different modules to provide functionality you might want more separation.
I've gone down the route of creating the master ProductivityLibrary - yeah, that was the dumb namepace - only to find that I had a subset of classes that I was using the most, and the grandiose scheme of a design-pattern-swiss-army-knife was always being recompiled each time a set of ideas came along. It didn't make sense to make plug-ins for everything as it became such a mish-mash.
Build discrete assemblies that solve one problem - it's just easier to manage.