I went to a fairly good talk this morning on the topic of managed/unmanaged interop issues when programming for VISTA. The core problem is that many of the development tools you'd use to program for this platform won't be ready by the time of release, and so some of the fancy .Net tools and short-cuts we're accustomed to won't be available. As a result, certain situations may require interop to the native APIs of the platform. Cases discussed included:

1. UAC-aware applications
1. User Access Control
2. Windows VISTA desktop search,
1. Integrated into the client experience in many ways
3. CommandLinks
1. The new "button" that's available in Windows VISTA giving allowance for a more descriptive text region.
4. Common File Dialogs
1. Presenting the new file dialog interface to clients.

...and so forth. The actual points made, however, wasn't of special interest to me as I believe I could find my way around them if I encountered them, but the fact that I may have to do interop to catch up to certain user interfaces was the most important "point" I took away from the talk.

Unfortunately I just haven't had time to totally wrap my head around all the new features coming out in the Windows VISTA security infrastructure; namely those in the firewall. One technology I'd like to look at more is the Windows Filtering Platform.

If you are interested in platform security or the firewall or anything related to these things, I would recommend checking it out.

http://www.microsoft.com/whdc/device/network/WFP.mspx
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWNE05008_WinHEC05.ppt
http://windowssdk.msdn.microsoft.com/en-us/library/ms686658.aspx

I had a chance to speak with a Russ Humphries who is the Sr. Product Manager for the Windows VISTA Security team and was very impressed with this man's overall intelligence, but especially impressed with a technology called BitLocker. I dont' want to go into it at the moment as I'm a bit short on time, but it's basically a mechanism for very securely encrypting content on disk in such a manner that nobody can retrieve it regardless of their manner of attack.

Check out this site here for more information (I'll try reducing it to something more palletable later): http://www.microsoft.com/technet/windowsvista/security/bitlockr.mspx.

Clemens Vasters gave a great talk on WCF today concerning binding and contracts; I got a lot out of it even though a lot was review, but it was good review because it solidified a lot of things that were nebulous to me still. Here are some basic notes:

1. There are three basic types of contracts
1. Service: which concerns the ports, operations and behaviors.
2. Data: data types,
3. Message: which define the format of the message on the wire.
2. There are three ways to talk:
1. One way: send the message and "forget" about it,
2. Request/Reply: where there is a request .... wait ..... response model,
3. Duplex: most easily thought about in terms of "callbacks"
3. One way requests are important because they're effecient. If the protocol is reliable that it's being sent on, you don't ahve to worry about it not getting there...you can send the message and forget about it. This is a good choice for several solutions.
4. Duplex is back channel, callback based.
5. Take note of "Channel Builder",
6. You can declare the back channel as [OperationContract(IsOneWay=True )]
7. Take note of "Dispatcher"
8. Duplex: [ServiceContract(Session=true), CallbackContract=typeof(IMYCALLBACKTYPE)]. The IMYCALLBACKTYPE is the interface the client is going to be using to reach the methods to call back.
9. Fault tolerance:
1. [FaultContract(typeof(SOMETYPE))] .....
2. ......
3. throw new FaultException<SOMETYPE>
1. These things are handled as soap exceptions
10. If you wish to work on the actual XML format, use the XMLSerializer
11. Bindings:
1. BasicHTTPBinding: "Old style"
2. WSHTTPBinding: "New style". Secure, reliable.
3. NetTCPBinding: Becoming very fast, almost as fast as COM+/DCOM. Instant firewall feedback/ NAT feedback.
4. NetNamedPipeBinding: maximum performance, same machine, on windows.
5. NetMSMQBinding: robust, reliable, queue-based transport.
6. MSMQIntegrationBinding: integration with old-style MSMQ applications.
7. NetPeerTCPBinding: for building peer to peer meshes.

The remainder of his talk was very informative, but difficult to express here as he went through particular case scenarios. This was an excellent way of seeing these protocols actually walk and therefore very a very expressive way of showing how to use the various binding types and why.

Warning, rough notes:

I went to a notable talk this morning about versioning web services using WCF (though, many of the concepts could have been applied to ASMX too, or for that matter, any web service technology). The basic question the session tried to answer was how do you adjust a contract over time (version it) so that you don't break existing cilents?

In short, there are two potential answers:

1. Put up a completely seperate and new endpoint,
2. Carefully adjust what you currently have.

Simple in theory, but in practice the second part is typically the more difficult one. The benefit of the first is that you don't haev to worry about breaking any clients in the field as the original logic isn't touched; however you will more than likely experience code-bloat. The second option is tougher to write as you have to make sure what you're touching dosen't break existing clients, but it's also more conservative as you typically can reuse existing blocks of code (less code = fewer bugs, etc).

If you must adjust your existing service contract (option #2), then you typically can do so in one of three ways:

1. Add new stuff - new types
2. Extend old stuff - add new functions or fields
3. Change old stuff - adjust parameter types, etc.

The 3rd option is usually the least preferrable, and if you're faced with this then it's recommended to just create a new endpoint (service) altogether. Adding new stuff is simple as you simply add new types and they don't interfere with the existing contracts. Extending older stuff, however, is possible but takes some thought:

1. The DataContract serializer (I believe it's called) expresses members of data types in alphabetical order into the WSDL. You must use the [DataMember(order=X)] ordering feature to properly order them since new additions must be placed at the end (so you don't break existing clients). The 'order' is done by group, so that the first versioned group is 1, the second 2, etc.
2. The XMLSerializer uses the same concept but is ordered like [XMLElement(Order=1)]......[XMLElement(Order=N+1)] with each value N going from 0 on.
3. If a client is calling in with less information than the service expects, then either the DataContract serializer and the XMLSerializer represent the value of the type as Nullable<T>, so test for this. Express new additional types that support nullable with the question mark (ex: [DataMember(order=x)] public int? age; )
4. Also note the benefits of IExtensibleDataObject, XMLAnyElement, and XMLIgnore.

....they'd be a MUCH more aggressive towards growing a monopoly.

I've been to talks like this one before, so not everything was new (in fact, very little was to me...which is probably a good thing, I guess). So, not as much struck me as interesting...but this is a (very) brief run down of some main points to take away...

1. Critical Problems are always...
1. IntraProcess: resources within the process like memory and CPU, or
2. InterProcess: contentions for resources outside (files, network, etc.)
2. Important CPU Counters to monitor for CPU utilization
1. % Processor Time: Useful in multi-CPU environments
2. % User Time: Determines how much work user-mode code in your app (therefore, typically YOUR APP) is taking,
3. % Priv. Time: Determines how much time the kernel is spent working on particular tasks given to it by your app.
3. Good CPU performance tools:
1. Visual Studio Performance Profiler (available in Team edition),
2. Kernrate viewer (available on MSDN),
3. Intel's performance profiler (forgot the name...oops)
4. Visual Studio Performance Profiler has the capability to profile in,
1. Sampling Mode: where it samples every N CPU cycles; this method is typically less intrusive, but given that it's time-based can miss things.
2. Instrumentation: performance code and bit are inserted into the runtime code, which takes up more time for it and gives it a larger working size, but is sometimes the only option for certain scenarios (like testing for Priv. Time slices).
5. Memory Problems:
1. Check for immense paging,
2. Tools:
1. Perf Counters, TaskManager, SysInternals' ProcessExplorer
2. CLRProfiler V 2.0
3. VADump (very cool app)
1. take note of the OtherData vs. Heap values in this as this determines what is native/managed resource leaks (usually) respectively.
4. Also Check out User Mode Dump Heap (never heard of this tool, personally), sometimes called "UMDH".
6. Key blogs:
1. http://blogs.msdn.com/ricom/.
2. http://blogs.msdn.com/maoni/.

Went to a lunch time session on Windows MapPoint; and there are some cool advances going on there. Version 3 is out, so I would recommend checking it out as there are some new features built into it.

Some highlights:

1. Check out http://dev.live.com/virtualearth/sdk for a wonderful array of samples and examples for what is capable and how to do it.
2. MapPoint is available as a web service too for smart clients, etc.
3. Check out MapCruncher, which is a service that lets you upload your own maps and morph them to support the same functional capabilities of MapPoint using the MapPoint services. Check it out here: http://research.microsoft.com/mapcruncher.

Some cool stuff, folks....