RE: Application error in event log

Hi,

The app.config/web.config file are loaded by default by the image, this
image is compiled by the .NET the first time that you load the assembly, at
that point the config file is loaded so there is no exception handling
available at that stage. This means that the image compilation failed. You
can not alter at runtime the config file (upon there are functions like
Add/Delete, they don' work and is considered bad practice)

Hope this helps to understand
Salva


"Wayne" wrote:

> I have an application where I added a comment as the first line of my Config
> file, as I found out I can't do this. However, an entry was made in the
> event log about the error (Source = .net Runtime):
>
> The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be
> found. The local computer may not have the necessary registry information or
> message DLL files to display messages from a remote computer. You may be
> able to use the /AUXSOURCE= flag to retrieve this description; see Help and
> Support for details. The following information is part of the event: .NET
> Runtime version 1.1.4322.2032- WincommCapturePurge.exe - Common Language
> Runtime Debugging Services: Application has generated an exception that
> could not be handled.
>
> The above is the error I got when I ran the app, I do not have admin rights
> on the machine. At some point I got one of our network admins to run the app
> and the following is what he got for the error (Source = Application Name
> (which means my try/catch wrote the error out) ):
>
> Error loading XML file file:///D:/WincommDFS/Landstar/Applications/Wincomm
> Capture Purge/WincommCapturePurge.exe.config The XML declaration is
> unexpected. Line 2, position 3. (D:\WincommDFS\Landstar\Applications\Wincomm
> Capture Purge\WincommCapturePurge.exe.config)
>
> Once removing the comment I was able to run the app, which at a later time
> failed due to a security right on a directory, the application was able to
> write that error to the event log.
>
> As far as I can tell the install of the frame work is very much a default
> install, running on 2003 server.
>
> Why the difference in errors? Why wouldn't the app written the invalid xml
> error when I ran it? is there something I need to set up in the framework to
> allow for the errors to be the same no matter who runs the app?
>
> --
> Thanks
> Wayne Sepega
> Jacksonville, Fl
>
> Enterprise Library Configuration Console Module Generator
> http://workspaces.gotdotnet.com/elccmg
>
> "When a man sits with a pretty girl for an hour, it seems like a minute. But
> let him sit on a hot stove for a minute and it's longer than any hour.
> That's relativity." - Albert Einstein
>
>
>
.

Relevant Pages

  • Re: Application error in event log
    ... when I put the comment in the config file in dev and run the app in the ... So I'm thinking the config file isn't ... loaded at start up but rather when you try to access it for the first time. ... >> Capture Purge/WincommCapturePurge.exe.config The XML declaration is ...
    (microsoft.public.dotnet.languages.csharp)
  • app.config Updates With No-Touch
    ... I'm deploying a windows form application using no-touch deployment and ... Rockford Lhotka's NetRun app. ... The first time I run the app everything is ... I checked the output of fuslogvw and it says the config file is from the ...
    (microsoft.public.dotnet.framework.windowsforms)
  • RE: where to save app settings?
    ... Note that the .config file of an app is read only the first time it is ... "Sam Carleton" wrote: ...
    (microsoft.public.dotnet.general)
  • Re: Extremely slow debugging performance in VS2003 with interop
    ... in the debugger now executes CreateInstance in 12 secs instead of 45. ... However, the second time I run the app, I'm back ... to 45 seconds every first time I run the app in the debugger. ... Here is the 12 second output: ...
    (microsoft.public.vsnet.debugging)
  • Re: Extremely slow debugging performance in VS2003 with interop
    ... > rename the file to symsrv.dll.hide, start VS and the initial run of the app ... > in the debugger now executes CreateInstance in 12 secs instead of 45. ... > to 45 seconds every first time I run the app in the debugger. ... > Here is the 12 second output: ...
    (microsoft.public.vsnet.debugging)