Logging Issues under 3.1 medium trust

Topics: Exception Handling Application Block, Logging Application Block
Nov 6, 2007 at 12:52 PM
Team:
We are upgrading to .Net 2.0 on a medium trust shared server. We recompiled an unsigned objectbuilder, and used that to recompile the 3.1 source. Data and Crytpo are working correctly, but exception logging is not. All of the dlls in the bin are unsigned as well as the references to same in the code. We keep getting "Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)" We can't figure out where that incorrect manifest is coming from.

Relevant sections of our web.config are;
<configSections>
<section name="loggingConfiguration"
type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
requirePermission="false" />
<section name="exceptionHandling"
type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
requirePermission="false" />
<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" />
<section name="securityCryptographyConfiguration"
type="Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.Configuration.CryptographySettings, Microsoft.Practices.EnterpriseLibrary.Security.Cryptography, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
requirePermission="false" />
....
And

<loggingConfiguration name="Logging Application Block"
tracingEnabled="true"
defaultCategory="General"
logWarningsWhenNoCategoriesMatch="true">
<listeners>
<add databaseInstanceName="Public"
writeLogStoredProcName="CL_InsertError"
addCategoryStoredProcName="CL_InsertErrorCategory"
formatter="Text Formatter"
listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Database.Configuration.FormattedDatabaseTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging.Database, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
traceOutputOptions="None"
type="Microsoft.Practices.EnterpriseLibrary.Logging.Database.FormattedDatabaseTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging.Database, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
name="Database Trace Listener" />
<add fileName="~/_private/rolling.log"
rollSizeKB="0"
timeStampPattern="yyyy-MM-dd"
rollFileExistsBehavior="Overwrite"
rollInterval="None"
formatter=""
header="----------------------------------------"
footer="----------------------------------------"
listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.RollingFlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
traceOutputOptions="None"
type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.RollingFlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
name="Rolling Flat File Trace Listener" />
</listeners>
<formatters>
<add template="Timestamp: {timestamp}&#xA;Message: {message}&#xA;Category: {category}&#xA;Priority: {priority}&#xA;EventId: {eventid}&#xA;Severity: {severity}&#xA;Title:{title}&#xA;Machine: {machine}&#xA;Application Domain: {appDomain}&#xA;Process Id: {processId}&#xA;Process Name: {processName}&#xA;Win32 Thread Id: {win32ThreadId}&#xA;Thread Name: {threadName}&#xA;Extended Properties: {dictionary({key} - {value}&#xA;)}"
type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
name="Text Formatter" />
</formatters>
<categorySources>
<add switchValue="All"
name="General">
<listeners>
<add name="Database Trace Listener" />
</listeners>
</add>
</categorySources>
<specialSources>
<allEvents switchValue="All"
name="All Events">
<listeners>
<add name="Database Trace Listener" />
</listeners>
</allEvents>
<notProcessed switchValue="All"
name="Unprocessed Category">
<listeners>
<add name="Database Trace Listener" />
</listeners>
</notProcessed>
<errors switchValue="All"
name="Logging Errors & Warnings">
<listeners>
<add name="Rolling Flat File Trace Listener" />
</listeners>
</errors>
</specialSources>
</loggingConfiguration>
<exceptionHandling>
<exceptionPolicies>
<add name="Log Only Exception Policy">
<exceptionTypes>
<add type="System.Exception, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
postHandlingAction="None"
name="Exception">
<exceptionHandlers>
<add logCategory="General"
eventId="100"
severity="Error"
title="Enterprise Library Exception Handling"
formatterType="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.TextExceptionFormatter, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
priority="0"
type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
name="Logging Handler" />
</exceptionHandlers>
</add>
</exceptionTypes>
</add>
<add name="Normal Exception Policy">
<exceptionTypes>
<add type="System.Exception, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
postHandlingAction="NotifyRethrow"
name="Exception">
<exceptionHandlers>
<add logCategory="General"
eventId="100"
severity="Error"
title="Enterprise Library Exception Handling"
formatterType="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.TextExceptionFormatter, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
priority="0"
type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
name="Logging Handler" />
</exceptionHandlers>
</add>
</exceptionTypes>
</add>
</exceptionPolicies>
</exceptionHandling>

Our connection strings and data access are just fine. So is the crypto. The logging stored procedures are correctly done, and execute permissions correct on the SP and related tables. In fact, all is running fine on VS2005 development server. Can anyone see a problem here or suggest a solution?

TIA,
Bill
Nov 6, 2007 at 1:20 PM
Hi Bill,

Everything seems to be right configuration-wise. What does the fusion log have to say about this load failure?

Fernando
Nov 6, 2007 at 3:40 PM


fsimonazzi wrote:
Hi Bill,

Everything seems to be right configuration-wise. What does the fusion log have to say about this load failure?

Fernando

Fernando:
No clue. Fusion log is turned off by the hoster (shared).
TIA,
Bill
Nov 6, 2007 at 4:51 PM
Hi Bill,

Debugging load failures without logs will be difficult. Can you replicate your hoster's environment in one of your servers?

What did you try already to diagnose the problem?

Fernando
Nov 7, 2007 at 6:49 AM
Fernando:
When an error is thrown the full detail is;
"Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionHandlingException was unhandled by user code
Message="The type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null' cannot be resolved. Please verify the spelling is correct or that the full type name is provided."
Source="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling"
StackTrace:
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicy.GetExceptionPolicy(Exception exception, String policyName, ExceptionPolicyFactory factory)
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicy.HandleException(Exception exceptionToHandle, String policyName, ExceptionPolicyFactory policyFactory)
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicy.HandleException(Exception exceptionToHandle, String policyName)
at Cheeseline.Default1.PageLoad(Object sender, EventArgs e)
at System.Web.UI.Control.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)"

The unhandled error is occuring in:

private static ExceptionPolicyImpl GetExceptionPolicy(Exception exception, string policyName, ExceptionPolicyFactory factory)
{
try
{
return factory.Create(policyName);
}
catch (ConfigurationErrorsException configurationException)
{
try
{
DefaultExceptionHandlingEventLogger logger = EnterpriseLibraryFactory.BuildUp<DefaultExceptionHandlingEventLogger>();
logger.LogConfigurationError(configurationException, policyName);
}
catch { }

throw;
}
catch (Exception ex)
{
try
{
string exceptionMessage = ExceptionUtility.FormatExceptionHandlingExceptionMessage(policyName, ex, null, exception);

DefaultExceptionHandlingEventLogger logger = EnterpriseLibraryFactory.BuildUp<DefaultExceptionHandlingEventLogger>();
logger.LogInternalError(policyName, exceptionMessage);
}
catch { }

throw new ExceptionHandlingException(ex.Message, ex);
}
}
in the file ExceptionPolicy.cs

Hope this helps. I have a ticket in with the hoster to see if they can enable the fusion log, but I have my doubts.

TIA,
Bill
Nov 7, 2007 at 3:38 PM
Edited Nov 7, 2007 at 3:45 PM

Bill_H wrote:
Fernando:
When an error is thrown the full detail is;
"Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionHandlingException was unhandled by user code ...


Fernando:
We were able to resolve it by adding a reference to Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll

We rechecked the P&P docs for both logging and exception handling under the "adding application code" sections. This reference is not mentioned. We found it by just adding references until something worked. Very scientific eh?

Hope this helps someone else.
Cheers,
Bill
Nov 7, 2007 at 4:00 PM
Hi Bill,

I'm confused here. The reference is not necessary for building, of course, and the only thing it would do for you if you have "Copy Local" set to true is that it will be copied to the output folder. Of course, the assembly needs to be accessible by the application at runtime, and having a copy local reference would take care of it, but it's not the appropriate way to manage runtime dependencies.

Your initial post stated that a:
  • a version of the assembly was found, but its manifest didn't match expected one (maybe a leftover from a previous install?)
  • the app did work on your dev server (when it should have failed to find the assembly if the failure was caused by a missing assembly)

In your second post, the error message changes to "The type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null' cannot be resolved. Please verify the spelling is correct or that the full type name is provided". This is not possible unless something changed in your app's deployment.

I'm glad you have it working now.

Fernando
Nov 8, 2007 at 8:14 PM


fsimonazzi wrote:
Hi Bill,

I'm confused here. The reference is not necessary for building, of course, and the only thing it would do for you if you have "Copy Local" set to true is that it will be copied to the output folder. Of course, the assembly needs to be accessible by the application at runtime, and having a copy local reference would take care of it, but it's not the appropriate way to manage runtime dependencies.

Your initial post stated that a:
  • a version of the assembly was found, but its manifest didn't match expected one (maybe a leftover from a previous install?)
  • the app did work on your dev server (when it should have failed to find the assembly if the failure was caused by a missing assembly)

In your second post, the error message changes to "The type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null' cannot be resolved. Please verify the spelling is correct or that the full type name is provided". This is not possible unless something changed in your app's deployment.

I'm glad you have it working now.

Fernando

Fernando:
We are doing some tests to try to recreate the problem. In summary, when the development server was running in full trust, the problem did not surface. When we switched it to partial trust to emulate the production server and trace the issue, the development server threw the same error as documented about.

When we added the reference to Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll
to the build, and of course added that .dll to the bin directory, all the problems ceased. It appears that under medium trust that reference and dll was required but not under full trust.

Will follow up and post.

Cheers,
Bill
Nov 9, 2007 at 6:46 PM
Hi Bill,

Is it possible that during the tests the signed version of Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll was not replaced by the unsigned one you built? That would explain the manifest mismatch error.

Have you tried building without the assembly reference but making sure the assembly is copied to the deployment folder? That would confirm your hypothesis that the reference is required; I don't think it's necessary though.

Regards,
Fernando
Nov 22, 2007 at 3:49 PM
Fernando:
Sorry, I have been another country on another project and just got back to this one.

Now another issue has developed after compiling unsigned enterprise dlls with an unsigned objectbuilder.

Whenever we access System.Security.Cryptography.RijndaelManaged we are getting "Request for the permission of type 'System.Security.Permissions.DataProtectionPermission, System.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed." on the development server. If we remove medium trust, it goes away.

Some of my team are having concerns about crypto's 'protectedKeyFilename" needing an absolute path, which is not possible on a shared server. Is this true?

Cheers,
Bill
Nov 22, 2007 at 4:02 PM
Hi,

About the partial trust error, does your app have the required DataProtectionPermission? Keep in mind that using EntLib will still require the app to be granted the permissions necessary for the underlying framework capabilities. You can look at the "Customizing the Medium Trust Policy" topic (ms-help://ms.EntLib.2007May/EnterpriseLibrary/html/00-330-Customizing_the_Medium_Trust_Policy.htm#crypto) for details.

Regarding the absolute path for the key filename, it's not really necessary. Unfortunately the config tool will write absolute paths, but they are not a requirement. You should be able to modify the config file to use relative paths.

Fernando
Nov 22, 2007 at 5:22 PM
Fernando:
This app is going on a shared server, we can't touch the hoster's medium trust settings. Alternatives?

Cheers,
Bill

fsimonazzi wrote:
Hi,

About the partial trust error, does your app have the required DataProtectionPermission? Keep in mind that using EntLib will still require the app to be granted the permissions necessary for the underlying framework capabilities. You can look at the "Customizing the Medium Trust Policy" topic (ms-help://ms.EntLib.2007May/EnterpriseLibrary/html/00-330-Customizing_the_Medium_Trust_Policy.htm#crypto) for details.

Regarding the absolute path for the key filename, it's not really necessary. Unfortunately the config tool will write absolute paths, but they are not a requirement. You should be able to modify the config file to use relative paths.

Fernando

Nov 22, 2007 at 5:54 PM
Hi Bill,

I'm not sure what kind of alternatives you're looking for. If an operation guarded by CAS is executed the required permisions need to be available, period. This can only happen if:
  1. your app is granted the permission, either by being fully trusted or by being assigned a security setting that includes the permission.
  2. the operation is fired by an assembly that does have the permission, accepts partially trusted callers (in case it is fully trusted) and asserts the permission before invoking the privileged operation.

In your case, #1 seems to be the only alternative.

Fernando
Nov 22, 2007 at 6:15 PM
Fernando:
In summary, are you advising that the Crypto library cannot be used under default medium trust settings? It seems strange that we have dataconfiguration, exception handling, logging, etc working now and crypto won't.

Interestingly, we put the test code up on the hosted server and got a different error message - System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

Cheers,
Bill
Nov 22, 2007 at 6:47 PM
Bill,

Each block, and in fact the different features of each block, has different permission requirements as documented in the topic I mentioned before. EH doesn't have any specific requirements (except when gathering some context information), and if you're using sql server the daab doesn't either. For the logging block, it depends on what you're using to log; a local file might be ok, but I don't know right now.

Do you have a stack and the additional details for the security exception? Is it possible the hosting provider has tweaked the default medium trust setting to explain the different exception?

Fernando