I suggest you ...

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

127 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    kkurnikkurni shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    20 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Robert PetzRobert Petz commented  ·   ·  Flag as inappropriate

        absolutely not! please no! it's really sad that this is under review when so many other better uservoice posts are not...

      • James McKayJames McKay commented  ·   ·  Flag as inappropriate

        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 AabechLars-Erik Aabech commented  ·   ·  Flag as inappropriate

        -1

        We have way better open-source alternatives to Enterprise Library (IMHO). Please don't. As @mark says, Nuget gives the options.

      • Mark SeemannMark Seemann commented  ·   ·  Flag as inappropriate

        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 SeemannMark Seemann commented  ·   ·  Flag as inappropriate

        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.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        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 HaydonPhillip Haydon commented  ·   ·  Flag as inappropriate

        Don't even consider this recommendation. Don't bloat .NET any further. Don't introduced Ent Lib, its a horrible library.

      • ssjxssjx commented  ·   ·  Flag as inappropriate

        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.

      • RR commented  ·   ·  Flag as inappropriate

        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.

      • DmitryDmitry commented  ·   ·  Flag as inappropriate

        .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 BrooksMike Brooks commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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 DotsonMatt Dotson commented  ·   ·  Flag as inappropriate

        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.

      • Richard ColletteRichard Collette commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base