How to deploy odd version of EntLib ( with my app?

Topics: User Forum
Feb 16, 2007 at 11:17 PM
Edited Feb 16, 2007 at 11:18 PM
The versions of the Enterprise Library dlls that are placed in the "Library" sub-dir of a WCSF solution generated by the guidance packages are versioned The console (EntLibCfg.exe) that ships with the latest version of EntLib prior to 3.0 is It will not open my Web.config file for a website created by WCSF.

Any tips to get it opening, and how to make this easy to deploy to my customers? I will be installing this web site at multiple customer sites and will require them to install Enterprise Library beforehand. I want the version they install to be able to open and edit the Web.config file in the field should I need to tweak it there.


Feb 19, 2007 at 4:02 AM
I too am wondering why the version of the Enterprise Library assemblies are a different version, but more from the standpoint of I would like the source for whatever the differences are.

You can open the web.config by using the configuration application that comes in the folder with the different assemblies instead of the one that ships with Enterprise library.

Hope this helps, and I hope that the development team can answer why there is a different version of the Enterprise library shipped with this factory and how to obtain this version of the Enterprise library.

John Bailey
Feb 19, 2007 at 1:54 PM
The source code is exactly the same as

Shipping the dlls allowed us to not depend on having EntLib installed, however p&p does not ship binaries unless they are signed (notice that version has public key). Hence we signed the entlib dlls and packaged them in the MSI. You can use the unsigned versions if you want. The only issue I see is with the guidance package generated code, specifically the web.config which has a reference to the signed one. You can always change the web.config T4 template anyways.

Hope that explains the reason
Feb 19, 2007 at 2:49 PM
I believe the version of Enterprise Library that ships with the Web Client Software Factory includes the partial trust patch for EntLib, which is why it has a different version number.




David Hayden
Microsoft MVP C#
Mar 8, 2007 at 2:05 PM
This is very frustrating for people who has developed a middle tier with the version and when to create a new UI with WSCF. I hope you will take this kind of problem in account in you future release.


Mar 8, 2007 at 2:53 PM

I talked a little about this challenge on the Enterprise Library Forums at:

Enterprise Library vs. Software Factories

If you think you are frustrated now, wait for when the new Enterprise Library 3.0 is shipped this month and you want all of its really cool and much needed functionality like:

1) Validation Application Block for simple Validation
2) Policy Injection Application Block for AOP-like functionality
3) Improvements to Data Access Application Block to support System.Transactions and Batch Updates
4) New Rolling Log File Trace Listener for much needed rolling log files
5) Etc...

I have a whole list of tutorials on Enterprise Library 3.0 you may be interested in that describe all of the new features:

Enterprise Library 3.0 Tutorials

The WCSF will still be on EntLib and none of the above features will be available until they come out with a version that supports 3.0, and I know everyone will want to use EntLib 3.0 :)

To be fair, however, I don't envy the challenge of the WCSF Team in having to work on a project that is so dependent on other internal projects like Enterprise Library, ObjectBuilder, Guidance Automation Extensions, etc. that are going through some big advancements themselves and on different schedules. No matter what you do there will always be some leap-frogging in functionality from other dependent projects and a delay in being able to support those new releases.

My hope is that the next version of WCSF will be on the next version of EntLib 3.0 and things will be a little more aligned in terms of schedules. And, I hope the next version of WCSF comes out relatively close to the next release of EntLib 3.0 because I want to use them both together :)

I also hope that the Policy Injection Application Block ( PIAB ) is leveraged within the WCSF such that when I request a registered service it is properly wrapped using the PIAB Wrap<> Methods for AOP-like functionality :) That PIAB is really, really cool except for the missing Dependency Injection Application Block that in our case the WCSF provides for us:

Policy Injection Application Block - ObjectBuilder - Dependency Injection

Exciting stuff.




David Hayden
Microsoft MVP C#
Mar 16, 2007 at 3:56 AM
Believe it or not, we feel your pain.

As we all know, there is always some new technology that is only a few months away that could really be great to use in the app you are working on now. (At least that is how it seems to me). But, sometimes you just need to ship with what is out now. This is the approach we used with WCSF's first release.

The nice thing is that we include ALL the source code, so if anyone really wants to, they can recompile the blocks and the guidance packages against the newest Enterprise Library version. This will require changing references all over the place, but it should be doable.

But, back to the original question for this thread:
"The console (EntLibCfg.exe) that ships with the latest version of EntLib prior to 3.0 is It will not open my Web.config file for a website created by WCSF."

There is, in the Program Files\Microsoft Web Client Factory\Libraries (or wherever the default installation folder is. I can't remember right now) a version of the config tool (and all the rest of the ent lib libraries) that are strong named and compiled with the source. These were actually provided to us by the EntLib team to redistribute and minimize the number of pre-requisites that folks need to download to use the WCSF.

And as a final thought, please vote for EntLib 3 inclusion in the WCSF in Issue Tracker if you really want this feature in the next release.
Mar 16, 2007 at 8:02 PM
Edited Mar 16, 2007 at 8:04 PM
From watching the rollout of P&P and now the software factory blocks over the past few years, there seems to be a lack of scheduling and architectural oversight with these (in my opinion) critical pieces of .NET infrastructure. I assume that there exists at least one hands-on architect currently tasked with a position to oversee the integration between the deliverables from all of these teams. I hope this person looks at the code and regularly interfaces with the lead developers, and is not simply a "face" who holds meetings once every few weeks for status updates.

If these teams are all on the same page, and their deliverables dependencies are directly linked (through a merged multi-file MS project schedule, up-front designed software interfaces, and frequent cross-deliverable integration builds) we should see releases that are a bit closer together I would assume. However I don't work at Microsoft, and know the red tape can get in your way so I won't pretend to understand all the political roadblocks ;)

A bigger problem IMHO than just the fact that these pieces come out at different times however is the clouded strategic message being sent to customers who are trying to select the best technologies. This is especially apparent in the data access layer where we have raw ADO.NET, DataSets through VS, LINQ, EntLib 2.0/3.0, and the wizards from the Web Service Software Factory - If LINQ is where things are going, shouldn't all .NET infrastructure components being planned now be driving towards 100% support for it when it is done?

I hate to say it but I'm seeing .NET start to go the same way as Java, with too many camps, even within Microsoft, releasing pieces with competing, overlapping goals that result in yearly deliverables of "the next big thing" which only adds a few features, but isn't fully supported by all the other design and configure-time tools related to it. I hope you guys are able to find more ways to push the issue within the WCSF team and help the company get a handle on consolidating all these technologies at some point.

The idea of choosing any programming language you want, and compiling to .NET to allow VB, C++, C#, and Java developers to be productive with your platform makes sense from a syntactical perspective. But there are way too many choices for doing the same thing, all of which ultimately fall short in .NET right now because there seems to be a difficulty keeping all the class libraries and middleware pieces on top of it aligned.

I really hope this gets better soon, it makes it very difficult for people who are designing commercial products in .NET for customers in the field such as myself.

IMHO we should have had one best of breed configuration platform, data access layer, UI pattern, and web service platform several years ago. The fact that .NET is in its 6th or so year and these basic decisions are still creating split dev teams is very disruptive to anyone trying to use .NET in "the real world". I do not buy the argument that just because .NET is an "open platform" these subsystems cannot be aligned within Microsoft much better than they are now.