Enterprise Library
Last week I had the opportunity to meet with a group of MVPs in Hyderabad. I was there to spend a few days with the Microsoft India Development Center folks and took the opportunity to meet with the local community. I really love these meetings because it gives me an opportunity to thank folks who do an amazing job in the community and also I know that these people usually don’t hold back and give candid feedback. Thanks to Anjana, you can view my picture with community leads. One of the topics that we discussed was the great work that Patterns and Practices (PAG) team does in terms of providing prescriptive guidance. There was some constructive feedback on what we can do that is more relevant and targeted with this effort.
That discussion prompted me to write about some of the things that our PAG team is currently doing. This month, we are streaming a series of webcasts discussing different aspects of the Enterprise Library -- a library of application blocks designed to assist developers with common enterprise development challenges. The Enterprise Library has been developed by the Microsoft patterns & practices group in collaboration with business partners such as Avanade Inc, Bowne Global Solutions, Foundstone Inc & Infosys Technologies.
Application blocks are a type of guidance, provided as source code that can be used "as is," extended, or modified by developers to use on enterprise development projects
Our vision is to build a broad community of customers and partners sharing and extending their own Application Blocks that are consistent with and integrate into the patterns & practices Enterprise Library.
The Enterprise Library is not a Microsoft product. It is guidance, designed to be reused, customized and extended. Like other patterns & practices deliverables, the Enterprise Library is associated with a community site where you can post questions, provide feedback and connect with other users for sharing ideas.
The next release of Enterprise Library will target the .NET Framework 2.0 and Visual Studio 2005.
If you are Enterprise Developer, take a look at the Enterprise Library.
Namaste!
Comments
Anonymous
March 13, 2005
Thanks very much for your time :-) It was a great evening for MUGH and MVPs out here in hyderabad.Anonymous
March 13, 2005
The comment has been removedAnonymous
March 14, 2005
The MVP program in India has been running a successful mentoring program where MVPs mentor budding MVP-potentials in the community.
It is unfortunate that you have had this experience. Please get in touch with the MVP Program Manager in India - Abhishek Kant (abhishek@microsoft.com). He will most gladly assist you with your queries as well as connect you with the current MVPs and Community Stars.
Good luck!Anonymous
March 14, 2005
Well, I haven't come across anything as a mentoring program for budding MVPs as such. Infact in one of the local user group meetings, i spoke to Abishek about this. Probably, amidst all his busy schedule, he might have forgotten about this.
Anyways, thanks for your input. I'll contact Abishek. I am just frustrated not knowing where to start and how to go about this.Anonymous
March 16, 2005
Hi Soma,
The Enterprise Libraries are great excpet the source and samples are only in C#. Very sad to see.
BTW: Rant, re the MVP program. the best way to becoem a MVP is to do what you love to do. don't strive for the award, rather focus on getitng involved about the products you love. If you are MVP material the award will then find you :)Anonymous
March 16, 2005
When can we expect the release for .NET 2.0???Anonymous
March 17, 2005
Hi Klaus,
The PAG (Patterns and Practices) team is working on this as we currently speak. Their current plans is to make this available at about the same time when Visual Studio 2005 and .NET 2.0 will be available later this year.
- somasegarAnonymous
March 17, 2005
Hi Bill,
We already include the exact same code in C# and VB for the following:
API Reference documentation (including code samples)
Code samples in the “how to”-style documentation
QuickStart sample applications
So everything, other than the block source, is in both VB and C# for v1. For v2 we plan on building some larger reference implementations – our plan is to target both C# and VB.
- SomasegarAnonymous
March 22, 2005
Hi Rant,
Not sure how to get hold of you. Abhishek would like to get in touch with you - either you can contact him or let me know how we can get in touch with you.
- SomasegarAnonymous
March 22, 2005
Hi Soma,
A key concept of the EL is that you can modify the code to suit your particualr needs. However, given the source code is only in C#, that means you have to code in C# and use a multiple project solution rather than incorporate the code into your current project.
So why is this being offered for C# and not Vb.NET ? Care to tell me exactly how VB.NET is not being treated like a second class citizen there ?
Regards,
bill.Anonymous
March 22, 2005
Hi Soma,
A key concept of the EL blocks is that you can modify the source code as needed. Yet for VB.NET you can't as the source is only in C#.
So why is this ? Why is the source only in C# ? And tell me exactly how that equates to VB.ENT not being treated as a second class citizen form Microsoft ??
Thanks,
Reagrds... Bill.Anonymous
March 23, 2005
Hi Bill,
You should talk to Michael Kropp (mkropp@microsoft.com) who runs our PAG team. Given the time constraints the team was under to get this done, they chose to do this in only one language this time around. Mike promises me that the next version will have source both in VB.NET and C#.
- somasegarAnonymous
March 23, 2005
Hi Soma,
Next version ??? You mean they aren't even goign to release it suplementary ? Instead we have to wait till Whidbey ?
I think this sadly indicates the resources inside Microsoft target C# first, and VB.NET only when they feel like it. EL is jsut one example. DirectX SDK another. Now either you take affirmative action on this, or let's be honest and admit VB.NET is treated as "secondary".
Thanks,
Bill.Anonymous
March 25, 2005
bill -
It seems like your interpreting what we did with Enterprise Library as another instance that Microsoft isn't behind VB as a strategic language for our customers. Let me provide you some insight on the thinking behind our decision to implement the blocks in Enterprise Library in C#.
Our goal with enterprise library was to help customers build enterprise applications more quickly with predictable results. We talked to many customers & partners about how they would use different languages (VB.NET, C++, J#, etc..) to use and extend the application blocks in Enterprise Library. While we made a decision not to provide all the application blocks in multiple languages we intentionally did a number of things to specifically help VB developers successfully use Enterprise Library (API Reference documentation, code samples, quickstarts and documentation). Going forward, we plan to make additional investments in Enterprise Library to include end-to-end reference implementations in both VB and C#.
We use customer feedback to direct our future development plans and help us make tradeoff decisions like this. We have over 2000 customers and partners in the Enterprise Library community http://workspaces.gotdotnet.com/entlib). We are looking to this community to share feedback and ideas with us on how we can improve the solution going forward.
Thanks for sharing your ideas with us. I’d really like to see you as an active member in the Enterprise Library community to influence the direction of our next release.
- mikeAnonymous
March 25, 2005
Hey Michael,
going forward that is good, but what about the current release for VS.NET 2003 (.NET 1.1) ?
As to how this seems, well yes it does appear that Microsoft is not behind VB.NET fully, instead it's VB.NET as a second. Really, Microsoft sells and claims to support both languages equally, but yet individual groups like yours, do their own thing rather than have good corporate guidance there. That's why I asked this question of Soma, because I believe this direction needs to come from the top down.
And it's a pretty simple policy to put in place. Unless you are a project specific group, all samples, all code, all documentation should be language neutral or provided equally for both VB.NET and C#.
The EL libraries are not alone in this, but rather, they are just another examples of how Microsoft itself is VB's worse enemy. currently for VB.NET we have:
Enterprise Library - source in C# only
DirectX samples - C# only
SGen.exe - C# only
This is clearly a divisional direction problem, a management problem. But Mike, you can help turn things around today, and re-release the current EL source in Vb.NET :)
Thanks,
Bill.Anonymous
March 25, 2005
Hey Michael,
going forward that is good, but what about the current release for VS.NET 2003 (.NET 1.1) ?
As to how this seems, well yes it does appear that Microsoft is not behind VB.NET fully, instead it's VB.NET as a second. Really, Microsoft sells and claims to support both languages equally, but yet individual groups like yours do their own thing rather than have good corporate guidance there. That's why I aksed this question of Soma, because I believe this direction needs to come from the top down.
And it's a pretty simple policy to put in place. Unless you are a project speciifc group, all samples, all code, all documentation should be language neutral or provided equally for both VB.NET and C#.
The EL libraries are nto alone in this, but rather, they are just another examples of how Microsoft itself is VB's worse enemy. currently for VB.NET we have:
Enterprise Library - source in C# only
DirectX samples - C# only
SGen.exe - C# only
This is clealry a divisional direction problem, a management problem. But Mike, you can help turn things around today, and re-release the current EL source in Vb.NET :)
Thanks,
Bill.Anonymous
March 25, 2005
I meant to say :
Unless you are a language speciifc group, all samples, all code, all documentation should be language neutral or provided equally for both VB.NET and C#.Anonymous
April 01, 2005
Hi Soma - We're running some Enterprise library webasts hosted by the Mirsooft architecture team. You can find them at www.pnplive.com.
Regards,
George, MSDN Webcasts
http://blogs.msdn.com/webcastsAnonymous
April 06, 2005
Hi Shreeman,
You had asked about the updater block.
Not placing the updater application block in the enterprise library by design. Our strategy is to keep the number of blocks in Enterprise Library to a minimum but conform all Microsoft application blocks to the enterprise library specification. This way, customers and partners are free to add Microsoft blocks or their own into the library if they choose to do so. The patterns and practices team has recently shipped version 2.0 of the updater application block that has several new enhancements one of them being conformance to Enterprise Library. Here’s a link to V2 of the updater app block:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/updaterv2.aspAnonymous
June 25, 2008
PingBack from http://ingrid.meinvoll.com/michaelkroppschedule.htmlAnonymous
August 12, 2008
Hi, I read this blog, I am glad to know whether VB.Net version of enterprise library is released. If so where could I find it. Regards BilalAnonymous
August 12, 2008
Both C# and VB.NET versions (current and previous) are available at: http://msdn.microsoft.com/entlib GrigoriAnonymous
August 12, 2008
To clarify, even though Enterprise Library is written in C#, it is usable from VB.NET. You can even write extensions to it in VB.NET. All of our code samples and quickstarts include both C# and VB.NET versions.Anonymous
August 13, 2008
Hi, We are currently using Enterprise library blocks source code which is written using C#, and ofcourse we are using it for VB.Net applications. So we need the Enterprise Library Blocks source code which are written in VB.Net.