Don't worry, we're thinking a lot about how to make this better. Have you seen WinRT that we're providing in Windows 8? It provides a much more smoother experience for interoping with native code, and exposes Windows native types in concepts that feel nature for .NET developers. For example, to .NET developers all native collections implement the same interfaces as the BCL collections, such as IEnumerable<T> and IList<T>. Primitives, string, Uri, etc are all interchangeable between native and managed. And you can use the new async features the same with the native APIs as you can with managed APIs.
While you can still have a choice to use p/invoke and normal COM interop to interact with 'classic' native code, going forward you are going to see more and more Windows APIs exposed using WinRT. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bill McCarthy Sent: Tuesday, October 04, 2011 8:42 PM To: 'ozDotNet' Subject: RE: In praise of DirectoryInfo Framework 4 Hi David, Actually I tend to agree with you on that to some extent. I do like the narrower scope that the dynamic keyword offers, and I do like some of the other features like overloading methods with optional parameters (has been on my long time request list for VB to allow for smoother versioning). That said, I think C# has been a decade late in coming to the party, and it's about time the party got out of the disco era ;) We've got some really cool things like embedded interop classes (guess that means technically they are no longer PIA's <g>), but we're still writing unverified code at design time that we know isn't going to change: the problem is the metadata isn't presented at design time. This impedance mismatch, such as exposing so many COM properties as Object due to the old IDispatch etc, is just screaming for a better interaction with managed code, be it metadata assemblies, duck typing/ pseudo interfaces etc. If we know enough at design time to write the member name in code yet intellisense can't guide us on that, and we are forced to forego any compiler checking on naming, types etc, then really the IDE and tooling has failed in its job. Dynamic in C# is great, be it ten years late, but it's a distraction from addressing the real issues, IMO . |-----Original Message----- |From: [email protected] [mailto:ozdotnet- |[email protected]] On Behalf Of David Kean |Sent: Tuesday, 4 October 2011 12:35 PM |To: ozDotNet |Subject: RE: In praise of DirectoryInfo Framework 4 | |While I like C#'s dynamic better than VB's (although I'm sure if Bill's still floating |around he'll argue differently) - VB actually supported 'dynamic' from |day 1 . J | | | |From: [email protected] [mailto:ozdotnet- |[email protected]] On Behalf Of Ian Thomas |Sent: Monday, October 03, 2011 6:15 PM |To: 'ozDotNet' |Subject: RE: In praise of DirectoryInfo Framework 4 | | | |You are right of course, David. | |Strange that this page <http://msdn.microsoft.com/en- |us/library/system.io.directoryinfo.enumeratedirectories(VS.90).aspx> exists, |more than a year after its last edit date . obviously it is a problem |with the MSDN |doco since the .enumeratedirectory (etc) doesn't work with v3.5 target. | |I have been using v4.0 for all disk file traversing, and for the |Dynamic keyword in |C# 4.0 - I think this will be in Visual Basic too, when the v4.5 |Framework is |released. | | | |________________________________ | |Ian Thomas |Victoria Park, Western Australia | |________________________________ | |From: [email protected] [mailto:ozdotnet- |[email protected]] On Behalf Of David Kean |Sent: Monday, October 03, 2011 11:00 AM |To: ozDotNet |Subject: RE: In praise of DirectoryInfo Framework 4 | | | |Pretty sure we added the EnumerateXXX in 4.0, not 3.5. | | | |From: [email protected] [mailto:ozdotnet- |[email protected]] On Behalf Of Ian Thomas |Sent: Sunday, October 02, 2011 7:56 PM |To: 'ozDotNet' |Subject: RE: In praise of DirectoryInfo Framework 4 | | | |There's always a What's New <http://msdn.microsoft.com/en- |us/library/ms171868.aspx> when a new Framework version is released. |And, I was correct - those (originally-cited) methods were in v3.5. But |the .TryParse |additions I had not seen.
