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.... 

Brief TechED Linq summary:

1. The point is to work with data like you work with objects
2. System.Query is the entry namespace
3. The LINQ infrastructure is built into the .Net Framework, so it's not a language extension but a first-class piece of .Net. This means it's language agnostic.
1. LINQ uses pluggable data sources to power itself. These can be done by third parties.
4. LINQ can query all objects implementing IEnumerable<T>
5. LINQ works with SQL Server by generating "interop-like" assemblies that wrap the database types and calls around something the LINQ framework can query (objects).
6. The LINQ Query Visualizer looks very cool, it's used during debugging times to see the SQL statements that the LINQ framework generated; also gives you the ability to tweak these statements and test them.
7. LINQ to XML:
1. System.Xml.XmlLINQ
2. VB.Net has now added support for XML Literals where XML can be written inline with VB.Net (without the "" quotes).
8. Check out http://msdn.microsoft.com/netframework/future/linq.

A quick run down on a few of the new changes in the Windows VISTA kernel:

1. I/O prioritization optimizations
1. Things like larger I/O packets to reduce read/write requests
2. File bandwidth reservations for long-running applications that may require time slices on the disk for a range of time (like Windows Media Player)
2. User Mode Drivers
3. No fixed-size memory preallocation of kernel regions at boot time; memory allocation can be dynamic.
4. SuperFetch
1. Notes patterns and prefetches application (and even application private memory) into VM.
5. ReadyBoost
1. Extends VM on external drives
6. Boot Configuration DataTable; boot.ini is has been replaced by the data table
1. Location D:\Boot\BCD
2. BCDEdit is the command line editor for this
3. BootMgr replaces pieces of NTLDR
7. New interactive logon manager
1. GINA has been replaced with a more dynamic, pluggable alternative
8. Kernel Transaction Manager (for transactional kernel actions)
1. File system is now transactional by nature
2. API is programmable through CreateTransaction/CommitTransaction/etc.
3. Interfaceable through commandline interface (transact command)
9. Volume Shadow Copy
10. Crash Recovery/Diagnostics for unhandled native exceptions (non-managed) isn't handled by Dr. Watson anymore, which was loaded into the address space of the crashing application as this was a bad alternative for apps with severely corrupted stack frames: No more "just dissapears" application crashes.  
11. BitLocker drive encryption
1. Implemented using filesystem filters
12. Code Integrity Verification
1. All drivers under 64-bit Windows must be digitally signed by Microsoft for verification of stability.
2. Mark noted that roughly 1/3rd of all blue screens today are occuring due to 3rd party drivers for which there are, currently, available updates that would have fixed the problem.
13. Protected Processes
1. Cannot have a debugger attached
2. Many statistics and bits of information are hidden from view, cannot be seen or analyzed.
14. Address Space Load Randomization
1. Very cool feature: randomizes where libraries and moduels are loaded into memory so that fixed-location attacks are mitigated.
2. The system randomizes 256 different locations; enough since most code that would need to inspect each 256 of the variants would be too large to fit in many buffer overrun attacks.
15. User Account Control
1. Running applications with reduced security tokens even when administrator - have the option to run as Administrator when Administrator.