在使用Microsoft patterns & practices Enterprise Library  Data Access Application Block
在本机运行正常,但发布到服务器报错。“Requested registry access is not allowed.”
请问如何解决?需要什么权限?谢谢!SR.strings:
# Instrumentation strings
LogName = Application
MachineName = .
FailureLogSource = Enterprise Library Instrumentation
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application 添加名为"nterprise Library Instrumentation"项是否可以解决?(服务器不能随便修改权限和注册表)
详细错误信息:Security Exception Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file. Exception Details: System.Security.SecurityException: Requested registry access is not allowed.Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. 
 
Stack Trace:  [SecurityException: Requested registry access is not allowed.]   Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable) +473   System.Diagnostics.EventLog.CreateEventSource(String source, String logName, String machineName, Boolean useMutex) +445   System.Diagnostics.EventLog.CreateEventSource(String source, String logName, String machineName) +11   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.PerformanceCounterInstances.ReportCounterFailure(String message)   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.PerformanceCounterInstances..ctor(String categoryName, String counterName, Boolean createNewInstance)   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.InstrumentedEvent.AddPerformanceCounter(String category, String[] counterNames, Boolean createNewInstance)   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.InstrumentedEvent.Initialize(String counterCategory, String[] counterNames, Boolean createNewInstance, String eventLogSource, EventLogIdentifier[] eventIds)   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.InstrumentedEvent..ctor(String counterCategory, String[] counterNames, Boolean createNewInstance)   Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataServiceEvent..ctor(String[] counterNames)   Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataCommandFailedEvent..ctor(String[] counterNames)   Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataCommandFailedEvent..cctor()
  
--------------------------------------------------------------------------------Version Information: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET Version:1.1.4322.573

解决方案 »

  1.   

    都把这个帖子给忘了:)同样问题的朋友清察看 蝈蝈俊.net's Blog
    http://blog.joycode.com/ghj/archive/2005/07/26/60364.aspxInstrumentation in Enterprise LibraryMuch of this has already been discussed in other forums, but there seems to be a fair bit of confusion about the instrumentation code in Enterprise Library, so I thought it would be worthwhile for me to touch on this too. I'll try to clear up how it currently works, why we chose to do it that way, and what we are thinking of doing to improve instrumentation in vNext.One of the primary goals of Enterprise Library is to showcase best practices for enterprise .NET development. We try to do this in multiple domains, including architecture, code standards, unit testing and operations. This last one is especially important, as it's something that developers often ignore. As a developer it's very tempting to fall into the mindset that once it compiles and meets functional requirements, it's somebody else's problem. Then one day someone from your organization's operations team will call you at 11pm on a Friday night (probably when you're at the pub with your mates) and declare that your app is broken and your help is needed to fix it. And unless the application is properly instrumented (including logging errors, trace/diagnostic messages and health monitoring) it can be really, really hard to work out what's going on (and whose fault it is - because as soon as you can prove it's not to do with your app, you can go back to the pub!). So instrumentation is very important, which is why we made sure we included it in the blocks - including event log messages, WMI events and performance counters. Of course you also need to instrument your applications as well, and we make a lot of this easier with the Logging & Instrumentation Application Block. However most kinds of instrumentation come at a cost - you generally need to run some kind of installation script and/or have administrator rights. In most cases this is something that can be dealt with, but we are aware that it is sometimes not an option - for example when deploying apps to hosted environments where you have limited rights and don't have the ability to run scripts.So we tried to support both of these scenarios with Enterprise Library. Instrumentation is enabled by default, but to make sure everything is registered you'll need to run the Install Services script from the Start Menu, or run installutil over each assembly (possibly as a part of your own MSIs). When you install Enterprise Library with default settings, all of the code will be automatically compiled, but unfortunately we didn't run the Install Services script for you. This was an unfortunate outcome - but if you remember to run the script yourself then everything should work well.If you are deploying to an environment where the instrumentation cannot be used, it's pretty easy to disable it, but you will need to recompile the code. Luckily all the instrumentation code is wrapped around conditional compilation directives, so you won't need to edit any source files directly. Just go into the Project Properties dialog for the Common project, and under Configuration Properties\Build, find the Conditional Compilation Properties property and remove ;USEWMI;USEEVENTLOG;USEPERFORMANCECOUNTER (or any combination of these that you don't want). Once you recompile, the relevant instrumentation code will be disabled. Of course, it is still possible to configure the Logging & Instrumentation Application Block to use WMI or Event Log, so make sure you also choose appropriate settings for your environment if you are using that block.So, how are we thinking about improving the instrumentation? We're still in planning mode so we're open to suggestions, but at the top of the list are:·   Make it possible to change the instrumentation behavior (turn it on and off) through configuration, rather than by recompiling the code ·   Run the Install Services script by default as a part of the installation process ·   Make the instrumentation more fine-grained, for example have separate performance counter instances for each Enterprise Library item such as a Database or Cache ManagerI hope this helps clarify things - please keep the suggestions coming!