Nicholas Paldino said:
They are managed, but it's not exactly what I would call "finished".
My initial response was false in the sense that yes, there is a managed
way, but choosing between WMI and the P/Invoke layer in this case is a
toss-up, IMO.
You have the advantage of being able to create strongly-typed classes
from the WMI classes, which might be just as easy as cutting and pasting
the needed declarations from
http://www.pinvoke.net (depending on if the
needed APIs and supporting structures are there or not).
It all depends on what the OP is more comfortable with.
Hmm... to me it's clear when I read this:
Any ideas? Or am I going to have to PInvoke like crazy??
Anyway, why a toss-up and why are they not finished?
In what way are they different from lets say System.Data.Odbc or
System.Data.OleDb namespace, both wrap unmanaged code (COM and native DLL
exports) to access local/remote DB server resources, both present
functionality to present the data to a consumer in an OO way. Granted
System.Management could do a lot more in managed code (like MS did with
SqlClient, where they removed the COM layer) before transitioning into
unmanaged code, but the difference here is that for SqlClient it was
"critical" move performance wise, while for System.Management this is much
less of an issue.
If you really consider PInvoke as a viable alternative I have to disagree,
if you find yourself defining several PInvoke signatures in a piece of user
code (not framework classes though) you probably overlooked a managed
equivalent (or you consider it as not finished
), or you are using the
wrong language. Native C style API's belong to C, managed OO oriented API's
are what you need from managed user code, or simply put, PInvoke is
something that belongs in frameworks that are maintained by the same vendor
as the native API's, when these change (in terms of signature, behavior,
constraints, etc...) or when they get removed the framework should be
adapted as well, and this is the vendors responsibility. Note also that many
Win32 API's have security constraints that are not well understood by many
developers, that means that instead of calling a limited number of API's you
end with calling a lot more API's because you need to impersonate (if it's
possible - remember calling LogonUser on W2K?) and/or you need to elevate
user privileges before you can actually do something as simple as changing
ACL's of some kernel objects. Really, this is something that should be
wrapped in the framework, the upcoming v2.0 frameworks offers this
functionality for the most common objects like files, but still it lacks
some features offered by System.Management.
Willy.
--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)
Willy Denoyette said:
There two managed way's to set permissions on ACL protected objects
(files, registry key's, etc..), the first is by using the
System.Management classes the second System.Directory services (which can
also be used to manage AD object ACL's), or do you consider these as not
managed?
Willy.
Nicholas Paldino said:
Richard,
Unfortunately, your latter question is the answer. There is no
managed way (at least out-of-the-box) to set permissions on a
file/folder in .NET 1.1, except through calls to P/Invoke.
.NET 2.0, makes this very easy, however.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)
Hi all,
Is there any class in .NET 1.x that will help me set file & folder
permissions for a user? Aka - I would like to do the in code
equivalent of
right clicking a folder in file explorer and granting read/write access
to a
specific user {not the user running the program}.
Any ideas? Or am I going to have to PInvoke like crazy??
