"Design for Operations" Workshop in Redmond, March 27-28

First, thanks to everyone who attended the patterns & practices Summit in Sydney this past week – it was great to see so much excitement around our deliverables and everyone’s willingness to share feedback and ideas. It was also great to catch up with so many people from past projects and teams, not to mention being able to escape the cold Seattle winter 🙂

One comment that we heard a lot this week this week is that despite all of the good architectural content available from p&p and others, many of their applications are still painful to deploy and operate, often because designers and developers don’t consider (or don’t understand) how early design decisions can have a big impact on the ability to easily and efficiently deploy and manage the application later on.

Unfortunately most guidance around important topics such as health modeling, instrumentation, deployment and so on is targeted at infrastructure people, rather than developers and architects – and by the time these people come into the picture, many of the key design and implementation decisions have already been made. So the patterns & practices team is working with other management technology teams within Microsoft to try to fill some of this gap with actionable, and hopefully even vaguely interesting guidance on how to build apps that don’t suck in the datacenter.

This effort will take a while, but one of the first things we are doing is running a free customer workshop on our main campus in Redmond, Washington. I know that many of you aren’t in a position to make it over to our corner of the world, and rest assured we’ll still get some good guidance to you soon that won’t require you to jump on a plane. But if you’re able to join us, it will be a great opportunity to both learn about the management technologies available for developers today, as well as to influence our thinking as we start putting together more guidance in this important space.

For more details and registration information, here’s the invitation. Hope to see you there!

Comments (4)
  1. Master Signer says:

    Why are the entlib blocks not signed? I cannot reference them from my project which requires signed assemblies.

    Now I’m looking at the huge tree of projects in the entlib source code. If I start signing them I need to go in and sign them all. Surely this is not the best way?

  2. Master Signer says:

    OK, I got over that one finally. I think the logging block is great but I have a couple of constructive suggestions:

    1. Add capability to do SMTP authentication in the email trace listener

    2. Add capability to limit log file size in the flat file listener (i.e., like the log4net RollingFileAppender)

    3. Add capability to assign messages to listeners by severity (without using categories)

    4. The template {timestamp} token is written out in UTC. This is far less useful than having local time. I don’t see how it can be configured so go ahead and add that as a new token ({localtime} or something).

    Please let me know when you have implemented these. Thanks!

  3. Hmmm… comments are a bit off topic, but I’ll respond anyway 🙂

    The blocks aren’t signed out of the box since we have a policy against shipping binaries. This is because it discourages customization (which is an inherent part of guidance) and complicates support. While it would be possible to ship the source with the necessary attributes and key file, this would not be a good idea at all as the key could be reused by anyone for any purpose, which defeats the purpose of strong naming to begin with. However we realize that strong naming is harder than it should be. The process is now fairly well documented, and there’s a macro available to simplify the process (see http://tinyurl.com/fvclh). I’ve also been working on something similar but still haven’t found time to fully test it.

    Now, to the logging questions:

    1. Sensible request, but probably not high on our list and should be pretty easy to add yourself.

    2. Yes this is something we would have really liked to get to, but we ran out of time. Luckily there’s a community Rolling File TraceListener available from http://workspaces.gotdotnet.com/RollingFlatFileTraceListener

    3. You may be able to do this by using the Switch Levels setting that applies to each Source… not sure if it’s flexible enough but worth a try.

    4. I blogged about how to add this – it’s actually very simple. See http://blogs.msdn.com/tomholl/archive/2006/01/22/516055.aspx



  4. Master Signer says:

    Great, thank you for the response! I am impressed by the community efforts to improve this product.

Comments are closed.

Skip to main content