Enterprise Library as default framework
I think include enterprise library as default framework will become handy as this will help for consistency. As my concern, I think most of development works now need dependency injection (unity), Logging tool and config tool. So why not put enterprise library as the first option
Thank you all for voting on this suggestion. The team has heard you and is considering this request, possibly for a future release.
Deonhe – MSFT .NET Framework team
Robert Petz commented
absolutely not! please no! it's really sad that this is under review when so many other better uservoice posts are not...
Guang Yang commented
James McKay commented
No, no, no, no, no, no, no, no, no, no, a million times no!!!!!!!
While it's good that Microsoft does have a number of options available in the dependency injection, logging, ORM and configuration space, we need to get away from this mentality of being spoon-fed by them. As I've said elsewhere, it's utterly, utterly, utterly toxic, because it results in teams that don't know how to think for themselves, don't know how to evaluate the best option for their project's particular needs, and don't know jack about the underlying principles and design patterns behind the tools that they're using. They also tend to end up thrashing around with so-called "best practices" that are at best five years out of date and at worst outright harmful.
Secondly, it leads to bloat in the core framework. You're asking Microsoft to come up with an anodyne one-size-fits-all set of components that do a so-so job of everything but that excel at nothing.
Thirdly, it encourages pointy-haired managers to introduce ludicrous restrictions on non-Microsoft tools that just frustrate and demoralise developers everywhere, as well as giving the entire .NET world a bad reputation, the result of which is that it's more difficult to find good developers for .NET than for any other programming ecosystem in existence.
Microsoft has taken great strides in the past few years towards making .NET a more community-driven ecosystem, with a variety of different grass-roots options available alongside their own. They've wisely allowed spaces such as these to remain competitive, and would be a great shame to see them take a step backwards in this respect.
Lars-Erik Aabech commented
We have way better open-source alternatives to Enterprise Library (IMHO). Please don't. As @mark says, Nuget gives the options.
Mark Seemann commented
Oh, and regarding the Dependency Injection (DI) options: .NET has had DI support since 1.0. It's called "interfaces".
Learn DI instead of clamouring for a tool you don't understand how to use.
Mark Seemann commented
This is, IMO, not a good suggestion. Not because it's Enterprise Library (of which I have no particular opinion), but because the BCL is already too big.
We already have NuGet as a fine delivery mechanism for optional frameworks, and if you can't already pull Enterprise Library from there, it would be easy to make it available via that channel.
Besides, putting Enterprise Library into the BCL (or VS) would lock it to the release cycle of that parent product. Look at the ASP.NET framework, that did exactly the opposite (pulled out of the BCL) to be able to iterate faster.
Kijana Woodard commented
Avoid. VS should not add unused references to a new project and unused using statements to a source file. Namespace pollution like this should be avoided since it adds a daily extra cost to each developer working on the project.
Phillip Haydon commented
Don't even consider this recommendation. Don't bloat .NET any further. Don't introduced Ent Lib, its a horrible library.
Not recommended too. I have tried Enterprise Library before, it is bad design, i will nevery use it. and don't recommend developers use it.
.Net framework has too many garbage in it now, start a .net program is too slow.
All modules like winform/wpf/asp.net forms/asp.net mvc... all should get out from .net framework.
Not recommended. VS should start a project with the most minimal set of dependencies to keep projects a simple as possible. Unused dependencies, DLLs, C# files, etc. add a daily tax cost to the project for every day it is in development, production, maintenance.
.net has di out of the box. see MEF. if entlib will be added to net platform it would be ****** to add new features and fixes to entlib. see entity framework - what dont you like in that model? quick updates and so on.
Mike Brooks commented
While I'm an advocate for DI, defaulting to a specific framework is a bad idea (made even worse by defaulting to Enterprise Library). I prefer to have the flexibility to choose my IoC container and I would rather not start each project by removing Enterprise Library.
Very bad suggestion.Disagree。
Enterprise Library is not good enough, some block is bad design such security block is useless.
.Net framework is too slow and too big now. so don't add this Library to it.
Matt Dotson commented
I do agree that .NET should have a dependency injection framework in it. It should also have a standard interface that ninject, autofac and all the other DI frameworks could implment so I can swap out for a different DI framework if I want.
Rich Czyzewski commented
Couldn't disagree more
Richard Collette commented
The problem I see with this is the lack of frequency with which Microsoft releases fixes, combined with the fact that GAC updates would most likely be needed to implement those fixes. If MS were to in-house this, I believe we would lose the ability to implement our own fixes. There have been some real show stoppers that I have been able to correct on my own in the past, without impacting existing projects, without having to deploy components to all machines, etc. If MS could provide a product that was robust, updated frequently enough and could be distributed simply, then the bundling concerns subside.
Christoph Rüegg commented
Disagree as well
Very bad suggestion. Disagree