Tech Off Thread

4 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Migrating to EntLib January 2006 release from June 2005 release on VS 2005

Back to Forum: Tech Off
  • User profile image

    Hi All,

    I've got a chance to try out the very latest EntLib January 2006 stuff but I am wondering what happened to the useful:


    and all the classes in Configuration.Protection?

    I see in the latest EntLib QuickStart the configuration libraries are utilized in System.Configuration but are there equivalent of classes above?  Why was it removed from EntLib?  Our tools are using them and creates a difficult migration from EntLib June 2005 to EntLib Jan 2006 release.

  • User profile image


    Infact there are a many of the classes that have vanished, because the Configuration block is now moved to System.Configuration.
    The approach that we take is to find internally how the EL used that class, and how are they using it now with 2.0. Although I tried for the KeyAlgorithmStorageProviderNode.cs class, but didnt find much, but am sure u will find an alternative from the System.Configuration namespace.

    Even Tom Holl said in one of his blogs
    that "System.Configuration in .NET Framework 2.0 comes with a new (and not particularly well documented) feature" when he was addressing the issue for external config files.

    If happen to get a chance, will look into it.

  • User profile image

    Thanks for your reply.

    At our organization we have tools with the same intentions as EntLib.  Our tools cover the Java world, .NET world:

    provide reusable best practices using code generation techniques for enterprise development / architecture community.

    Over the years we found the value is in backward compatibility and well defined migration paths.  So my feedback to EntLib team would be to be careful when phasing out functionality as this impacts very many users.  From the EntLib team perspective it may seem that you found a new and cool  way of doing something, but from the user perspective those old artifacts are sometimes lifeblood.  Even bugs often become features - take Java SDK as an example: almost nothing is removed from SDK since early release back in 99'.  So my advice for EntLib team going forward:

    1) Never remove classes only mark them as obsolete and document what is the new equavalent version.  After several years, old classes can be deleted.  Great example:  Java community and .NET Framework as well is fairly backward compatible.

    2) Provide a migration guide with a release if it is a major revision such as EntLib January 2006.  Otherwise, there is no value in upgrading because the functionality is the same only in different packages.  What is more is that some functionality has been actually removed such as XML security serialization as in my previous post.

    3) Remember that the key to your success is customer adoption.  I believe things were going well up to June 2005 release.

    As it stands now, I've been using VS 2005 since beta 1 and upgraded to EntLIb June 2005 with RTM release.  I see no value of upgrading to EntLib 2006.  If there is value, please help customers like me see it.



  • User profile image

    I agree with you. EL ppl should have considered this.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.