We are focusing on three blocks in the Enterprise Library; Logging, Configuration and Exception Handling. I'm looking at Logging first because everthing else will touch on the logging. What we need is to force three attributes into each log. These three are already provided in by the LogEntry object, these are; Application Name, Application Version and Event ID. Okay, so application version is not supplied by the LogEntry, but we can get that easy enough.
The other thing we want is that the custom logger or tracelistener or whatever it is we create must be inherited and cannot be instantiated on its own. While this sounds easy enough via an abstract class, it turned out not to be so practical. It seems that, while I can create an abstract class that inherits the ILogFormatter, that class can't be used in the Enterprise Library Configuration tool.
Hmmmm...I wonder if we can extend the Enterprise Library Configuration tool to force the required attributes and formatters. Now I have something else to look at.
I've been able to find some information on using Enterprise Library. One place which has links to tutorials (or at least is supposed to) is Channel9 Wiki. However, most the tutorials that would actually do me any good are by that Hisham Baz fellow, and I can't seem to get to his site from work. I'll have to try from home, perhaps it is just that exceptionally poor quality of internet service we experience here:
Channel9 Wiki
EnterpriseLibrary Home
EnterpriseLibrary MSDN blogs
MSDN EnterpriseLibrary page
Hands on Labs - EnterpriseLibrary 2
21 December, 2006
15 December, 2006
Oh the confustion is causes!
Trying to find information on how to use the Enterprise Library is like looking for information on how to use the Enterprise Library! This is worse than needle in a haystack scenario. I see lots of how EntLib works, and why it works, but very little on practical applications of EntLib. I should probably look at the documentation that came with the EntLib download. I haven't yet - but mostly because Microsoft has a history of piss-poor documentation (when there is any at all).
More soon!
More soon!
07 December, 2006
Enterprise Library
We're going to start using Enterprise Library for .NET Framework 2.0 to handle our configuration, exception handling, and logging processes. This is going to be fairly new because we've never been ones to actually follow recommended practices on most of anything. Maybe we'll end up with some readable code that actually works. :)
Anyway, I'll be posting in the near future the experience about a first time user with this library and it's implications.
Thanks for visiting!
Anyway, I'll be posting in the near future the experience about a first time user with this library and it's implications.
Thanks for visiting!
01 December, 2006
Other places of interest
I have several other blogs, they are updated as my schedule permits, but at least a couple of times a week. You can get there via the following links:
My Home Town
Bigsibling
At The Top Of My Lungs
C# Follies
My Home Town
Bigsibling
At The Top Of My Lungs
C# Follies
Using CACLS in an MSI install
What I have discovered is that if you use the Setup and Deployment project from the Visual Studio 2003 IDE, it doesn't always work the way one might expect it to work.
For instance, when the user installs the program, they are presented with the option to select to install the program for them only, or for anyone on that machine. If the user selects for them only, it would be expected that the files and components of that program's permissions are set so as to only allow that person to run the program.
However, if the user selects to allow all users to run the program, my prevailing expectation was that it would set permissions on the files and components to allow any user to run the program. WRONG. As I should have expected, with Microsoft making so many assumptions and decisions for us (and giving us very little means to adjust that easily), the files and components are set to read only for all but admin account holders.
In our programs, there are many files that are read and written to. For this, since we have dropped InstallShield as our primary install creating agent, I had to create yet another small program that runs on install (that makes two now). I do have these installed as "hidden" files so hopefully it won't clutter up the install directory too badly.
At any rate, I use CACLS.EXE to set the directory permissions. It's a fairly simple command line program. As I didn't want to pop open an command line window, I created a form that is 1px by 1px, located at 0,0 and has an opacity of 0. This should keep it from being seen at all. What we needed was for the local "Users" group to have read/change permissions to all files that get installed. For that I used the command line switch "/G BUILTIN\Users:C(hange)". This table lists the permission codes:
The codes really are (surprisingly) intuitive. There are other switches involved. These are
So I end up with the following example:
Resources:
Undocumented CACLS: Group Permissions Capabilities
How to Use CACLS.EXE in a Batch File
Information about the cacls command.
For instance, when the user installs the program, they are presented with the option to select to install the program for them only, or for anyone on that machine. If the user selects for them only, it would be expected that the files and components of that program's permissions are set so as to only allow that person to run the program.
However, if the user selects to allow all users to run the program, my prevailing expectation was that it would set permissions on the files and components to allow any user to run the program. WRONG. As I should have expected, with Microsoft making so many assumptions and decisions for us (and giving us very little means to adjust that easily), the files and components are set to read only for all but admin account holders.
In our programs, there are many files that are read and written to. For this, since we have dropped InstallShield as our primary install creating agent, I had to create yet another small program that runs on install (that makes two now). I do have these installed as "hidden" files so hopefully it won't clutter up the install directory too badly.
At any rate, I use CACLS.EXE to set the directory permissions. It's a fairly simple command line program. As I didn't want to pop open an command line window, I created a form that is 1px by 1px, located at 0,0 and has an opacity of 0. This should keep it from being seen at all. What we needed was for the local "Users" group to have read/change permissions to all files that get installed. For that I used the command line switch "/G BUILTIN\Users:C(hange)". This table lists the permission codes:
N | None |
R | Read |
W | Write |
C | Change |
F | Full |
/T | Recursive through current and all sub-directories |
/E | Edits permissions (doesn't replace them) |
/C | Ignores "Access Denied" errors |
/G | Grant access rights |
/R | Revoke access rights |
/P | Replace access rights |
/D | Deny access rights |
So I end up with the following example:
string response;
string userPerm = @"BUILTIN\Users:C";
string fileDirectory = @"C:\Program Files\Program";
string caclsSwitches = @" /T /E /C /G ";
string caclsLoc = System.IO.Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), "CACLS.EXE");
Process p;
if (Directory.Exists(fileDirectory)
{
p = new Process();
p.StartInfo.FileName = calsLoc;
p.StartInfo.Arguments = fileDirectory + caclsSwitches + userPerm;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.UseShellExecute = false;
p.StartInfo.WindowStyle = ProcessWindowStyle.Minimized;
p.StartInfo.CreateNoWindow = true;
p.Start();
response = p.StandardOutput.ReadToEnd();
if (response == null || response.Lenghth == 0)
{
// handle errors here
}
if (p != null) p.Dispose();
response = null;
}
Resources:
Undocumented CACLS: Group Permissions Capabilities
How to Use CACLS.EXE in a Batch File
Information about the cacls command.
Subscribe to:
Posts (Atom)