Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Visual Studio.NET / Enterprise Tools / November 2003

Tip: Looking for answers? Try searching our database.

Prevent Logging of certain EIF messages

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Jim - 29 Oct 2003 19:26 GMT
How can you prevent the logging of the message about EIF not being able to
create a backup file when it loads the configuration file or for that matter
turn off the logging of the fact that it successfully loaded. In fact, is it
possible to have it log only if it cannot load the
EnterpriseInstrumentation.config file?

On our terminal servers where we used EIF enabled application we end up with
a whole lot of these EIF entries.

Thank you in advance.

Jim
Mike Hayton [MS] - 29 Oct 2003 21:34 GMT
Sorry Jim,

There is no way of preventing these messages in the current version of EIF.
This is a request that weve heard several times, and I am lobbying to get
it into the next version.

Where do you think such a setting(s) should be specified?
What would you call the setting(s)?

Mike

--------------------
| From: "Jim" <jim@nospam.com>
| Subject: Prevent Logging of certain EIF messages
[quoted text clipped - 23 lines]
|
| Jim

Signature

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Jim - 29 Oct 2003 21:56 GMT
Mike,

I would be OK with a registry entry or config file for EIF either way.  I
would definitely want the option of what to log such as success, failure and
warning. I suppose the config file that was being loaded could even have a
key that indicated logging and level if you wanted it on an application by
application basis. My preference would be system wide or at least a system
wide override (similar to machine.config and web.config).

I would think two keys. LogConfigFileRead with a true/false and a
LogConfigFileReadLevel with something like 0,1,2 with 0 for fail only, fail
and error and fail, error and success. Of course you could just use the
second key and have 0,1,2,3,4 with 0 equals no logging, 1 fail only, etc.

Hope this makes good sense. It did tome while I was writing it anyway. :-)

Thank you,

Jim

> Sorry Jim,
>
[quoted text clipped - 38 lines]
> |
> | Jim
Mike Hayton [MS] - 31 Oct 2003 18:11 GMT
Thanks for your thoughts.

I am currently thinking of:
- one switch to disable the auto backup of EI.config file. (true=no backup,
false=(default) tries to backup)
- one switch to set the  EIF message logging level (0=none, 1=errors,
2=errors&warnings, 3=(default) All: errors,warnings&information)
I was thinking of putting these in <appSettings> in the app.config file,
since they could be put in machine.config for a machine level effect if
needed.

Can you give me your thoughts on this design?

--------------------
| Mike,
|
[quoted text clipped - 50 lines]
| > Use of included script samples are subject to the terms specified at
| > http://www.microsoft.com/info/cpyright.htm

Signature

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Jim - 08 Nov 2003 00:38 GMT
Mike,

I think that would work out great and I especially like the idea of putting
it in the app.config or machine.config. I did not realize that a choice in
the app.config worked in machine.config that way so I learned something new
from this too.  My one thought here, may be the backup flag should be "true"
to backup and "false" is no backup and the absence of the key is the default
of true so backup by default. This would avoid the kind of negative logic of
saying, yes, do the backup by saying no, don't not backup. See what I mean?

The not backing up choice may also take care of the issue we appeared to
experience on a terminal server the other day when we included the backup
file in the install msi. Not 100% sure but when we made it read-only again
vs read-write the problem went away so I can only guess that in that brief
instance of it backing up someone starting up the application saw it as
"missing" which caused the auto repair feature of the installer to try and
reinstall it. Besides, in this environment we have a lot of people logging
in and out all day and there really isn't a reason to backup the file
everytime someone logs in.

BTW, great thanks for wanting my input.

Jim

> Thanks for your thoughts.
>
[quoted text clipped - 70 lines]
> | > Use of included script samples are subject to the terms specified at
> | > http://www.microsoft.com/info/cpyright.htm

rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
Mike Hayton [MS] - 08 Nov 2003 17:43 GMT
Jim,

Thanks for the feedback - I totally agree about the negative logic point -
my bad :)

Mike

--------------------
| Mike,
|
[quoted text clipped - 106 lines]
| > Use of included script samples are subject to the terms specified at
| > http://www.microsoft.com/info/cpyright.htm

Signature

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.