| RE: [aus-dotnet] DllImport |
- From: Stephen Price
- Subject: RE: [aus-dotnet] DllImport
- Date: Sun, 29 Jan 2006 20:20:05 -0800
- Prev by Date: RE: [aus-dotnet] DllImport
- Next by Date: RE: [aus-dotnet] DllImport
- Previous by thread: RE: [aus-dotnet] DllImport
- Next by thread: RE: [aus-dotnet] DllImport
- Index(es):
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
Silly me, expecting an entirely managed code OS...
:)
I keep forgetting about all that legacy code they need to
make it all work. I didn't have much to do with coding PC's pre .Net. all my
coding was on Amigas and it was shared libraries etc. Can I say that on here?
Don't want to be subjected to public beatings. ;)
I'll check out that ActiveDirectory namespace, I understand
it to be better to use the .net way wherever possible.
Cheers,
Stephen
(suitably more enlightened than half hour
ago) From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of Nick Wienholt Sent: Monday, 30 January 2006 11:18 AM To: dotnet@xxxxxxxxxxx Subject: RE: [aus-dotnet] DllImport >
Is this how you access
unmanaged code? Yes > Is that the right
name for it? code outside of .net is not managed by the framework
right?) Yes > I would have
thought the framework would have had somekind of wrapper for OS level stuff. I
mean it has it for accessing files and memory streams etc, why not
AD? The full Win32 API is
huge compared to the .NET Framework – it will take a lot of versions of the
Framework before the majority of Win32 is covered. There is a new
namespace - System.DirectoryServices.ActiveDirectory – that covers AD, but I
don’t think it offers login services. Nick Wienholt, C#
MVP Maximizing .NET
Performance http://www.apress.com/book/bookDisplay.html?bID=217 A Programmer's
Introduction to C# 2.0, Third Edition http://www.apress.com/book/bookDisplay.html?bID=454 www.sdnug.org www.dotnetperformance.com From: peter@xxxxxxxxxxx
[mailto:peter@xxxxxxxxxxx] On Behalf Of
Stephen Price I'm looking at some code to do with
impersonation and a nagging question popped up (its done it before so here i am
asking why). Why do you use
DllImport? I understand what it does... ie allows you to use methods in a dll,
but what i don't quite get is why is this not part of some .net namespace? Is
this how you access unmanaged code? (Is that the right name for it? code outside
of .net is not managed by the framework right?) I would have thought the
framework would have had somekind of wrapper for OS level stuff. I mean it has
it for accessing files and memory streams etc, why not
AD? Seeking illumination.
:) Cheers, Stephen http://support.microsoft.com/default.aspx?scid=KB;en-us;q306158 [DllImport("advapi32.dll")] |
(Click here for more information on the aus-dotnet mailling list)
