Setting `ApplicationName` on Error object is ignored

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Get ELMAH working normally.
2. Submit an error with the following VB code:

        Dim elmah = ErrorLog.GetDefault(Nothing)
        Dim e = New Elmah.Error()
        e.ApplicationName = "HOORAY"
        e.Type = "TestException"
        e.Detail = "None"
        e.Message = "Test message!"
        e.User = "Fake User"
        e.HostName = "None"
        e.Time = Date.Now
        elmah.Log(e)

3. Notice that the error's application name in the DB is not "HOORAY". Sad face!

What is the expected output? What do you see instead?

I expect that the error will be saved with a different application name. 
Instead, the default name is used. I am trying to sub-divide errors in a 
service which accepts legacy SOAP requests to log errors for multiple 
applications, and I need to be able to set the ApplicationName on individual 
Error objects. If it is not intended to be set, don't allow it to be set!

What version of the product are you using? On what operating system?

1.2 SP2. Windows 7, Windows 2008R2, etc.

Please provide any additional information below.

All of the `ErrorLog` implementations ignore the `Error.ApplicationName` on the 
object, if it is set, and just jump straight to using `this.ApplicationName`. 
For example, line 154 of SqlErrorLog.

Original issue reported on code.google.com by dgfi...@gmail.com on 1 Jul 2015 at 10:01

[GoogleCodeExporter]

This is by-design. The ErrorLog determines the ApplicationName and ignores 
anything you have set for sake of consistency, correctness and isolation (where 
the backend store is being shared by several applications). The 
Error.ApplicationName property is settable primarily so that it can be 
initialized when an error is rehydrated from the log. If you want override this 
policy then subclass SqlErrorLog and override the Log method to use what was 
supplied in the Error object.

Original comment by azizatif on 1 Jul 2015 at 10:22

• Changed state: WontFix

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The only problem with that plan is that the public `Log` method calls into the 
private sealed class `Commands.LogError`. So then I have to duplicate that code 
as well. Ah well, should work, and I know this is a very, very edge usage case.

Thanks!

Original comment by dgfi...@gmail.com on 2 Jul 2015 at 2:17

[GoogleCodeExporter]

> So then I have to duplicate that code as well.

Thank God this is open source and so you *can* do that. ;)
I agree it's not ideal but fortunately you don't have to duplicate the whole 
class except one method:
https://bitbucket.org/project-elmah/1x/src/3a71f9a4eeb57921662b5a5acc211fc4b0932
cae/src/Elmah/SqlErrorLog.cs?at=v1.2-sp2#cl-415
That method is not ever likely to change unless you tweak the stored procedure 
interface. The rest is just plain old ADO.NET code.

Original comment by azizatif on 2 Jul 2015 at 4:04