Avoiding configuration pitfalls with incompatible copies of Enterprise Library

re: Avoiding configuration pitfalls with incompatible copies of Enterprise Library

berkej — Thu, 19 Apr 2007 23:36:06 GMT

Tom,

Thanks for the info this is exactly what I needed. One question though, due to your final note, I am wondering if there is any benefit in keeping the MS Signed assemblies around?

I found that by replacing the pre-compiled binaries with my own strong named solved the editor issues.

Is there any reason not to do this?

Thanks

re: Avoiding configuration pitfalls with incompatible copies of Enterprise Library

tomholl — Fri, 20 Apr 2007 00:34:56 GMT

If you don't plan on using the signed assemblies, there is no reason to keep them on your machine. And if you later change your mind, you can always just reinstall EntLib to get them back!

re: Avoiding configuration pitfalls with incompatible copies of Enterprise Library

AlanY — Fri, 20 Apr 2007 17:21:27 GMT

Tom - this is brilliant. I must have spent 4/5 hours on this a couple of days ago. Solved in 30 seconds after reading your article!

Thanks Heaps

Al.

re: Avoiding configuration pitfalls with incompatible copies of Enterprise Library

Guy — Sun, 22 Apr 2007 00:22:20 GMT

Here is something related.

http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=9240

Is there an application to do an update of the config where one would supply the new version of the EntLibConfig and then have the .config files upgraded to that version and public key with out having to hand edit the file?

If build the config with out a signed library, then I swith what would I need to do to upgrade the config files?

If I start with the c:\program files then switch to my own how would that be done? Would all this be done by hand?

Thank for the registry setting and stuff that helps.

Some additional PIAB MatchingRules (err.. operators?)

^(?:[^$]*)$ --Matches everything, captures nothing — Mon, 23 Apr 2007 17:39:54 GMT

Even though the Validation Application Block supports extensive composition of validation rules (using

re: Avoiding configuration pitfalls with incompatible copies of Enterprise Library

Wes Weeks — Thu, 26 Apr 2007 22:04:22 GMT

Although I fully understand the path you took, it does cause some headaches if you have to change from using the precompiled libraries to your own compiled versions at a later time.

In our case, we found a minor bug with a policy injection call handler that wasn't marked as serializable. To fix the problem in code took 2 seconds, battling the incompatibilities across the applications that had already been written against the original version took considerably longer.

Some thoughts might be that during the install decide which version to use for the default location (signed or unsigned) or perhaps an option to create a signed version with a key of our choosing during the install?

re: Avoiding configuration pitfalls with incompatible copies of Enterprise Library

Georges — Mon, 30 Apr 2007 03:55:21 GMT

Hello,

how can i resolve this problem :

Package Load Failure

Package 'Microsoft.Practices.EnterpriseLibrary.Configuration.Design.VisualStudioIntegration.EnterpriseLibraryIntegrationPackage, Microsoft.Practices.EnterpriseLibrary.Configuration.Design.VisualStudioIntegration, Version=3.0.0.0, Culture=neutral, PublicToken=b03f5f7f11d50a3a' has failed to load properly ...

Thanks

re: Avoiding configuration pitfalls with incompatible copies of Enterprise Library

Alan — Thu, 03 May 2007 02:03:45 GMT

Tom - I thought my problems related to this issue were solved, but they seemed to have resurfaced following my introduction of the Asynchronous Splash Screen (also found on codeplex) to my solution.

I find that I am forced to drop the /2.0 portion of the ProfileCatalog.xml namespace to enable the async splash screen work otherwise an error occurs whilst deep down in the CAB framework whilst enumerating through the modules.

If I remove the /2.0 all is well and the splash screen works, but I then find that I cannot use the Enterprise Library Configuration tool because it must validate the XML. I'm not sure how to resolve this issue. Is there someone/somewhere that I can refer to, (beside wading through the internals of CAB) to better understand what is happening here?

Regards

Al.

re: Avoiding configuration pitfalls with incompatible copies of Enterprise Library

Patrick — Wed, 23 May 2007 21:39:12 GMT

I just upgrade from Ent Lib 2.0to Ent Lib 3.0 and Vista. I have deleted all the Ent Lib 2.0 .dlls from my bin folder in my web project and added the new 3.0 .dlls from the D:\EntLib3Src\App Blocks\bin. It actually installed the source on my d: drive. Also I am using the EntLibconfig tool from the D:\EntLib3Src\App Blocks\bin folder as well.

I used the assemblies from "C:\EntLib3Src\App Blocks\bin" for editing any configuration files in my solution.

When I build the website I get the following error messages:

Error 3 'Microsoft.Practices.EnterpriseLibrary.Caching.CacheManager' does not contain a definition for 'RemoveItemsFromCache' D:\_SYL_Project\Projects\ShareYourLoss\BLL\FAQ.cs 224 26 BLL

It worked with Ent Lib 2.0 but now everytime I run it I get the above error. I have delete all leftovers from Ent Lib 2.0 and all the old .dlls I could find. When I click on “Go to definition” it takes me to a file called CacheManager(from Metadata) and that file only has the method signatures in there. The method signture for my “RemoveItemsFromCache” is missing.

Can somebody tell me what is going on???

Thanks,

Newbie

Incompatible Configuration Assemblies of Enterprise Library

Guy Burstein's Blog — Thu, 31 May 2007 10:04:56 GMT

I am giving a lecture about Enterprise Library 2.0 and 3.0 for a customer later this month, and spending

re: Avoiding configuration pitfalls with incompatible copies of Enterprise Library

Sayle Matthews — Mon, 18 Jun 2007 19:26:53 GMT

Thanks so much for this clarification. Spent all day battling that error and read this and it was fixed in 30 seconds.