It took a few seconds before it completely registered on my mind.

O.M.G.

The data CASCADED! It really CASCADED!! Niyuuuu. Tears of joy continue to flow. Waa I can't comprehend anymore. La la la la La la la la. YOSH! YOSH! YOSH! YOSH! \(^_^)/ \(^_^)/ \(^_^)/ \(^_^)/

I love God very much! Huwaaaa huwaaaa.

tblhrFile201, you're next on Cascader! WUHOO! WUHOO! WUHOO!

Warning: This is a very technical post. My thoughts and tears are overflowing right now I want to express them all! Uwaaaaaa huhuhuhuhu.

This recent problem of mine started last Tuesday, after I decided to deploy the executables on dev server for further testing and to prepare the big tests with Sol's and Kuya Kim's modules. As expected, my deployment brought a lot of misfortunes. The series of error messages below are associated with their corresponding resolutions and/or prerequisites PLUS my spectacular experiences in order to solve them. WOOOOT!

Scenario: The executable loaded an assembly via System.Reflection which references other dll
Error: "Could not load file or assembly... or one of its dependencies. The system cannot find the file specified."
Resolution: Use Assembly.LoadFrom(assembly) instead of Assembly.LoadFile(assembly)
Explanation: LoadFile just loads ONLY the assembly we are invoking while LoadFrom loads the assembly including other assemblies which have reference to it. :)
Other Notes: 1. According to Master Alex, include the .pdb files as well in the location of the invoked assembly because the actual code resides on the them ^_^; 2. Don't forget to include all assemblies which the invoked assembly have reference into in the same directory.

Scenario: The Data Access Layer of the invoked assembly uses Enterprise Library 3.1 for all database-related processes.
Error: "SecurityException: That assembly does not allow partially trusted callers"
Resolution: Followed the steps from http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=10710 and www.stuffthatjustworks.com/CommentView,guid,b5b1f5df-f69e-4ffa-ba95-d5d9d8d6dfbb.aspx
Explanation. It's the fault of Microsoft.Practices.ObjectBuilder.dll. It should be unsigned when referenced by EntLib 3.0 and 3.1 considering deployment. The process is quite tedious, building ObjectBuilder (creating an unsigned assembly), then re-referencing the unsigned OB in EntLib then building it, then re-referencing EntLib in your custom assembly, but it should work eventually.
Other Notes: 1. The use of [assembly: AllowPartiallyTrustedCallers()] is for SIGNED ASSEMBLIES only. In our case, a strong name for the invoked assembly was not created; 2. Make sure the folder definition where the assemblies to invoke are located SHOULDN'T BE A MAPPED DRIVE. e.g \\test\d$\AseemblyPath; 3. Using the unsigned ObjectBuilder, this should be also referenced now in your custom assembly; 4. The section <section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

should be modified into <section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null" requirePermission="false"/>

. Note that PublicKeyToken was changed to null and requirePermission="false" attribute was added; 5. Enterprise Library 4.0 has already solved this issue but it's prerequisite version of .NET Framework is 3.5 or higher and I'm using .NET 2.0 only =))

Scenario: The resolved partial trust affected the SqlClientPermission
Error: "Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0 failed."
Resolution: Add the following code prior to connection.Open();
SqlClientPermission pSql = new SqlClientPermission(System.Security.Permissions.PermissionState.Unrestricted);
pSql.Assert();
Explanation: I'm sorry I don't know hahaha. I'm not even sure if the resolved partial trust is the cause. But adding that code snippet didn't throw an exception. THAT WAS A MIRACLE. =)) There are other solutions like creating a strong name for your custom assembly or increasing the trust in .NET configuration yet didn't opt for those.
Other Notes: 1. Folder definition still shouldn't be a mapped drive; 2. Make sure the server you are using has your expected running version of .NET Framework. >_< -> I'm a big idiot on this one. I'm using .NET Framework 2.0 yet the first dev server I chose runs 1.1 WOOOOOTT!!

Technical part ends here.

WOOOOTTT! Resolving those errors were really hard! The feeling was HELLLLLLLL. X3 I really cried when the workaround on SqlPermission was a big success as I've been toiling on the that since Wednesday night. SOOOOOOWSSSS. Thank you very much Master Alex for being always open for consultations even though I must not consult. Y__Y Thank you also Kuya Kim for providing the link about the Reports. I found the snippet about the SqlPermission there. >:D< >:D< Haaayyyzz, my Sunday-Monday ALL NIGHTER was worth. BANZAI! Wuhooo!

My Next Stop: the tests covering Sol and Kuya Kim's parts. Yes! And today's the start of UAT! O_O

---

Even Sanada-papa posed my emotions regarding the past week's HELL experience (hahaha what a coincidence! I just changed Sanada's positions to fit:P)



from HELL to HURRAY to RELAX. =)) Sanada is a real winner. Hahaahaha.


---

Mamabear's birthday is a blessing. Happy Birthday Mamabear! <3 Don't forget to bring some SAYOTE back to Manila :P