Any problem updating Microsoft.Practices.EnterpriseLibrary.Caching.Cryptography.dll to latest?

flipscript's picture

Hi ZNode,

Hopefully, this will be helpful to you, too.

My web host will not allow "full trust" assemblies to run, so the Cryptography.dll in \Web\Bin is unable to load.

Luckily, Microsoft has a newer build of EnterpriseLibrary that allows it to run under "medium trust". See How to implement Enterprise Library in a Medium Trust Environment for a few details.

The latest Microsoft build of the library can be downloaded here (registration is required):
https://www.microsoft.com/downloads/details.aspx?familyid=4C557C63-708F-...

[Note to others: Do NOT download and install this library if you are not encountering this issue]

Sure enough, it is indeed a later version, and about 10% larger (additional code) than the .DLL that ships with ZNode.

However, for some reason, the ZNode .dll has a later build date. Of course, that could be because of a myriad of things (source code control check-in time, installation tool date changing, use of "Touch", etc.).

However, it could also be because that really is the last build date of the .DLL. Since the source code for the MS EnterpriseLibrary is included in the distribution, I was wondering if anyone at ZNode has perhaps customized the source code before doing a build.

I certainly don't want to overwrite something that is needed, or has been customized to make the store front work.

However, if nothing has been customized in the EnterpriseLibrary, this might be a great solution for running ZNode on a shared server in a "Medium Trust" environment.

I would like to know just what I would be breaking (if anything) by replacing the EnterpriseLibrary .dlls with the newer versions from MS.

At any rate, if the code in that assembly has indeed been changed by ZNode developers, it might be nice to merge those changes into the latest MS EnterpriseLibrary for the next ZNode build.

Any advice in this area would be appreciated.

Thanks,

Mark

flipscript's picture

Status: Indeterminate

I did successfully replace the EnterpriseLibrary DLLs with the newer ones, and ZNode ran without a hiccup at all.

In fact, I was unable to find *anything* which had changed (which in this case, was a good thing).

As chance would have it, we needed some additional things we couldn't get from GoDaddy, and ended up leaving them behind, so I have no idea if running with partial trust would have allowed ZNode to work on a GoDaddy shared server.

Still, I haven't found the need to go back to the original DLLs that shipped with ZNode and we are running with the latest ones.

This works for me, but if you're not having issues, there's really no advantage to making this change. Don't fix what's not broken. :)

admin's picture

Enterprise Library

Thanks for the info!

We don't make any changes to the enterprise library and use them right out of the box. I think you should be ok to try and substitute in a newer version of the library. Of course you would need to do some testing to verify that there are not side effects.

Znode Administrator
email: support@znode.com
url: www.znode.com

scottwade's picture

Microsoft P&P Enteprise Library

Mark,

Just wondering if your exploration into the Cryptography application block in the Enterprise Library is referring to the Enterprise Library v3.1 - May 2007 release or the v4.0 - March 2008 CTP? I too noticed file differences between those latest builds and the ZNode code and was wondering myself if the source has been customized by ZNode?

I do know the partial-trust problems have been resolved in v4.0 and I'm wondering if you've managed to get that running with your ZNode source or if you're just updating with the v3.1 release? The docs for Enterprise Library v4.0 - March 2008 CTP mention the new atrribute:

"Enterprise Library 4.0 has the Allow Partially-Trusted Caller attribute (APTCA) on all assemblies. This means that you can call the methods of Enterprise Library and the application blocks from an application running in a partial trust environment. You can do this with the signed assemblies provided with Enterprise Library. There is no longer any requirement, as there was in version 3.x, to recompile the source code then either use the unsigned binaries or strong-name them yourself."

Thanks...

--Scott--