v6 DLLs

Topics: Transient Fault Handling Application Block ("Topaz")
Nov 6, 2013 at 3:21 PM
Hi Folks

I'm getting this error trying to get the aExpense solution to compile:

Warning 16 The referenced component 'Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.WindowsAzure.Storage' could not be found. aExpense.FunctionalTests

The homepage for the library mentions:

"If you are using the Transient Fault Handling Application Block, you should ensure that you are using version 4.0.30319.18003 or later of mscorlib.dll, otherwise you may see a VerificationException exception at run time. For more information, see http://support.microsoft.com/kb/2748646."

This makes no sense in my scenario. (I'm at a higher version than mentioned in the link, plus the link doesn't make any sense since it doesn't contain a version which meets 4.0.30319.18003 or later of mscorlib.dll.) (And yes, I'm good on the latest version of nuget as well.)

So basically I can't kill anymore time on this "reference" example as far as setup triage goes...

Is there a place where I can simply get ALL the .DLLs (v6 release version)? Which leads me to my next question. Below is the list of DLLs I had from v5 and then v6. In my v6 list, are there additional DLLs (for that library that I'm missing)?

Finally, the DLLs from v5 where there isn't a corresponding v6 DLL, is there some way to figure where this code went? (deprecated, superseded, etc.)?

v5.0.414.0
Microsoft.Practices.EnterpriseLibrary.Caching.Cryptography.dll
Microsoft.Practices.EnterpriseLibrary.Caching.Database.dll
Microsoft.Practices.EnterpriseLibrary.Caching.dll
Microsoft.Practices.EnterpriseLibrary.Common.dll
Microsoft.Practices.EnterpriseLibrary.Configuration.Design.HostAdapter.dll
Microsoft.Practices.EnterpriseLibrary.Configuration.Design.HostAdapterV5.dll
Microsoft.Practices.EnterpriseLibrary.Configuration.DesignTime.dll
Microsoft.Practices.EnterpriseLibrary.Configuration.EnvironmentalOverrides.dll
Microsoft.Practices.EnterpriseLibrary.Data.dll
Microsoft.Practices.EnterpriseLibrary.Data.SqlCe.dll
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF.dll
Microsoft.Practices.EnterpriseLibrary.Logging.Database.dll
Microsoft.Practices.EnterpriseLibrary.Logging.dll
Microsoft.Practices.EnterpriseLibrary.PolicyInjection.dll
Microsoft.Practices.EnterpriseLibrary.Security.Cache.CachingStore.dll
Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.dll
Microsoft.Practices.EnterpriseLibrary.Security.dll
Microsoft.Practices.EnterpriseLibrary.Validation.dll
Microsoft.Practices.EnterpriseLibrary.Validation.Integration.AspNet.dll
Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF.dll
Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WinForms.dll
Microsoft.Practices.ServiceLocation.dll
Microsoft.Practices.Unity.Configuration.dll
Microsoft.Practices.Unity.dll
Microsoft.Practices.Unity.Interception.dll

v6.0.1304.0

Microsoft.Practices.EnterpriseLibrary.Common.dll
Microsoft.Practices.EnterpriseLibrary.Configuration.Design.HostAdapter.dll
Microsoft.Practices.EnterpriseLibrary.Configuration.Design.HostAdapterV5.dll
Microsoft.Practices.EnterpriseLibrary.Configuration.DesignTime.dll
Microsoft.Practices.EnterpriseLibrary.Configuration.EnvironmentalOverrides.dll
Microsoft.Practices.EnterpriseLibrary.Data.dll
Microsoft.Practices.EnterpriseLibrary.Data.SqlCe.dll
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll
Microsoft.Practices.EnterpriseLibrary.PolicyInjection.dll
Microsoft.Practices.EnterpriseLibrary.SemanticLogging.Database.dll
Microsoft.Practices.EnterpriseLibrary.SemanticLogging.dll
Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Caching.dll
Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Configuration.dll
Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Data.dll
Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.dll
Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.ServiceBus.dll
Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.WindowsAzure.Storage
Microsoft.Practices.EnterpriseLibrary.Validation.dll
Microsoft.Practices.EnterpriseLibrary.Validation.Integration.AspNet.dll
Microsoft.Practices.ServiceLocation.dll
Microsoft.Practices.Unity.Configuration.dll
Microsoft.Practices.Unity.dll
Microsoft.Practices.Unity.Interception.Configuration.dll
Microsoft.Practices.Unity.Interception.dl
Microsoft.Practices.Unity.NetCore.dll

Thanks
Rob
Nov 6, 2013 at 7:22 PM
ok, here's the real issue...

the nuget fetch actually fails because of a file directory and file length too long issue (destination path too long).

( the message looks very similar to this: http://www.thewindowsclub.com/file-names-too-long-for-destination-folder or
http://answers.microsoft.com/en-us/windows/forum/windows_8-files/windows-8-file-name-too-long-error/db84824e-fd43-4afa-a3aa-31cd69fd738e )

hmmm, nutty as a fruit cake (does the same thing even with windows explorer copy-n-paste....)

rob
Nov 7, 2013 at 12:56 PM
at first I thought this was a nuget issue (but seeing that the .dll and .xml ended up in a user appdata location), this told me otherwise

this is a very serious Windows 8 Pro bug (not being able to handle file names like what is below).

we will have to hand rename .DLLs and .XMLs for:

Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.WindowsAzure.Storage.*

even copies in the command window fail (with the filename being too long), i.e.:

copy "C:\Microsoft Enterprise Library 6\DLLs\Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.WindowsAzure.Storage.dll"
"C:\Microsoft Enterprise Library 6\EnterpriseLibrary6-aExpenseRI-source\aExpense\EL-V6\packages\EnterpriseLibrary.TransientFaultHandling.WindowsAzure.Storage.6.0.1304.1\lib\NET45*.*"

Rob K
Nov 7, 2013 at 1:06 PM
(feel like I'm loosing my mind with MS....)

I renamed all instances of Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.WindowsAzure.Storage. to x.

however, there are package failures for each project in the solution that had assembly references (3 of them) to Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.WindowsAzure.Storage.dll

they come in pairs (3 of them for aExpense.FunctionalTests, aExpense.Tests, aExpense):

Error 6 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. aExpense.FunctionalTests

Error 7 The command ""C:\Microsoft Enterprise Library 6\EnterpriseLibrary6-aExpenseRI-source\aExpense\EL-V6.nuget\nuget.exe" install "C:\Microsoft Enterprise Library 6\EnterpriseLibrary6-aExpenseRI-source\aExpense\EL-V6\aExpense.Tests\packages.config" -source "" -o "C:\Microsoft Enterprise Library 6\EnterpriseLibrary6-aExpenseRI-source\aExpense\EL-V6\packages"" exited with code 1. aExpense.FunctionalTests

what a GD mess...

Rob K
Editor
Nov 7, 2013 at 1:25 PM
Have you tried moving to a directory path that is shorter? e.g. "c:\MSEntLib\aExpense"? Windows has a limit to the length of the path.

If NuGet package restore is enabled and the files can be written then they should download and the solution compile.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Nov 7, 2013 at 1:45 PM
final fix was to create a new directory (C:\MSEntLib6 <- which changes our naming pattern), pull everything back down and rebuild (this was a short enough directory name that Win 8 Pro, nuget and VS 2012 had no issues)...

mouth still open trying to get a handle on how something that should have taken 5 minutes, ate up 3 hours...

rob k
Nov 8, 2013 at 3:34 PM
hi randy

as mentioned this did work.

however, one simple test and point, copy the file directory and file name mentioned throughout the dialog and paste them into notepad.

you'll see that neither the directory nor the filename length is anywhere near the mentioned limitation. here's the bigger of the two, just as a reference (so you can copy into NotePad and look for yourself...:

C:\Microsoft Enterprise Library 6\EnterpriseLibrary6-aExpenseRI-source\aExpense\EL-V6\packages\EnterpriseLibrary.TransientFaultHandling.WindowsAzure.Storage.6.0.1304.1\lib\NET45\
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
     *         *         *         *         *         *         *         *         *         *         *         *         *         *         *         *         *         *
Pretty much I'm calling this a bug in Windows 8 Pro.

Respectfully
Rob
Editor
Nov 10, 2013 at 8:35 PM
I feel your pain on this one. I hit something similar this week as well on Windows 7. I tried to copy an entire folder up a level (e.g. c:\users\me\dev\longfolder to c:\users\me\shortfolder) and I got the path length error! Definitely something non-intuitive going on there.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Jun 1 at 10:11 PM
Just want to add: I have had the same issue and used the approach mentioned here: http://blogs.msdn.com/b/jnak/archive/2010/01/14/windows-azure-path-too-long.aspx - this enabled me to tell the Azure SDK to deploy the project to \Azure instead of the "long" temp dir. This resolved the error in my case and also - I didn't have to move my project files outside where I feel they belong ;)

So basically, what I did was:

1) Close VS and the Azure emulators
2) Create a new user environment variable with name: "_CSRUN_STATE_DIRECTORY" and value: "C:\Azure"
3) Boot VS again, launch the project and see it work :)

Hope this helps someone out there ;)