I am getting the following exception. I have given full control to Asp.net account on Eventlogs in Registry edit.
[SecurityException: The source was not
Launch Developer command line "As an Administrator". This account has full access to Security log
If you are performing a new install of the SenseNet TaskManagement website on IIS (from source code, not WebPI), you will get this message, usually related to SignalR communication. As @nicole-caliniou points out, it is due to a key search in the Registry that fails.
To solve this for SenseNet TaskManagement v1.1.0, first find the registry key name in the web.config file. By default it is "SnTaskWeb".
<appSettings>
<add key="LogSourceName" value="SnTaskWeb" />
Open the registry editor, regedit.exe
, and navigate to HKLM\SYSTEM\CurrentControlSet\Services\EventLog\SnTask
. Right-click on SnTask and select New Key
, and name the key SnTaskWeb
for the configuration shown above. Then right-click on the SnTaskWeb
element and select New Expandable String Value
. The name should be EventMessageFile
and the value data should be C:\Windows\Microsoft.NET\Framework\v4.0.30319\EventLogMessages.dll
.
Keywords: signalr, sensenet, regedit, permissions
For me just worked iisreset (run cmd as administrator -> iisreset). Maybe somebody could give it a try.
Had the same exception. In my case, I had to run Command Prompt with Administrator Rights.
From the Start Menu, right click on Command Prompt, select "Run as administrator".
For me this error was due to the command prompt, which was not running under administrator privileges. You need to right click on the command prompt and say "Run as administrator".
You need administrator role to install or uninstall a service.
EventLog.SourceExists
enumerates through the subkeys of HKLM\SYSTEM\CurrentControlSet\services\eventlog
to see if it contains a subkey with the specified name. If the user account under which the code is running does not have read access to a subkey that it attempts to access (in your case, the Security
subkey) before finding the target source, you will see an exception like the one you have described.
The usual approach for handling such issues is to register event log sources at installation time (under an administrator account), then assume that they exist at runtime, allowing any resulting exception to be treated as unexpected if a target event log source does not actually exist at runtime.