CTS300 provided tha audience with some prescription on which technology to uses when you implement SOA's. It bascially came down to this order:

  1. ASMX (webservice)
  2. EnterpriseService
  3. .Net Remoting

So asmx is the way to go, it will give the best future proof technical implementation that will migrate without too much pain to Indigo. EnterpriseServices are needed if you want/need transactions and ancient component COM+ integration. However running (distributed) transaction in a service (that might call other services and so on...) might not be the brightiest architecture to opt for. Stay away from the native COM+ api's because they will definitaly not work in Longhorn but System.EnterpriseServices are OK. .Net Remoting will be a fine solution in a system, between services where you need object-based comm (fine-grained, chatty) instead of messagbased comm(coarse-grained, chunky). And .Net Remoting will be used if youi do cross app-domain (inproc) calls.

DEV324 was presented by juval Lowy and covered the complex (and becoming even more complex) topic of versioning. Juval showed based on very quick demo's what the results where for loading the right assembly (fusion) when the assembly is friendly named, strongly named, in the GAC, int he app folder. He als showed the options in the .Net Framework configuration panel to make an app bind to a different version. He pointed out that the CLR2.0 will be almost backward compatiable. So you need some testing to do to be sure every line of code you wrote for the 1.1 framework will operate as expected on clr 2.0. Important is that MS doesn't garantee that any cross-framework use of assemblies will be supported . If you absolutely need a System.[anything].dll from 1.1 just make sure your app uses the 1.1 CLR. If you start using System.data.dll from 1.1 and System.xml.dll from 2.0 the results are not known, not tested and MS gives no support on that kind of use (I think they are right).

I already knew something about Sql-hacking (take down a SqlServer) but on SEC401 I've seen that there is still a lot to be done to get all code and the configuration of sqlserver thightened. Some great sql-injection attacks where shown and a colleague will go the advanced session this afternoon where they actually will try to bring down the sqlserver. In the DTS package the connection info (including user/pwd) is stored. Many customers send their DTS package to MS for inspection when they suspect there is some kind of problem. As MS can decrypt anything in the package, MS is in the possesion of a lot of SA passwords of a lot of their customers. Lesson learned: don't use SA (or any high-priveledged account) int the connection settings in your DTS package. Second Lesson Learned: Don't send DTS packages to MS ;-)