
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
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