This is part of a transcription of my notes from Microsoft's recent BUILD conference in Anaheim, CA, minus anything that might be considered Red Gate confidential. Thus, they're somewhat unstructured, sometimes ramble off-topic, and often contain dodgy grammar. My own commentary and observations will generally be italicised so you can easily distinguish it from the reporting on what actually happened. Much has already been said about this conference, and about Windows 8, but I hope you find these useful. Please feel free to comment or ask questions and I'll be happy to answer them as best I can.

Kieran Mockford is an Architect at Microsoft Corporation: http://channel9.msdn.com/Events/Speakers/kieran+mockford

Chris Sells is a Program Manager at Microsoft Corporation Corporation: http://en.wikipedia.org/wiki/Chris_Sells

Started off with a bit of banter and showed an Xbox controller hooked up to a Windows 8 PC and accessed via the XInput API.

Showed off debugging a Metro app, illustrating that even with a single monitor and Metro's full screen nature, it's possible to keep Visual Studio in view whilst debugging using the application thumbnail view. This also works for other fullscreen apps.

Also showed off WinMD files, which expose meta-data for the WinRT API in a CLI compliant format, which means you can open them with ildasm. As of the latest 7.4 early access build, they can also be opened in .NET Reflector. I later discovered that if you develop a WinRT component in a managed language (C# or VB), then the WinMD file will also contain the actual code, and not just the meta-data - i.e., it's just an assembly, and for the WinRT APIs it basically acts as a .NET reference assembly. This latter parallel was drawn elsewhere in the conference, but I had to go and talk to one of the guys on the Visual Studio expo stand to get to the bottom of the managed code issue.

C# Metro projects, and presumably those written in VB as well, support unit testing.

Showed that the XAML designer in VS is now the Blend designer. It thankfully looked a wee bit simpler to use than it does in Blend, although this may have just been my perception.

Demonstrated remote debugging of a Metro app running on device from Visual Studio running on a different computer.

Remote debugging in this way also works for JavaScript and HTML apps, and includes a DOM explorer view which seems pretty sweet, especially because it can highlight the selected element in the app being debugged, even though that's on a remote machine, via the "select element" button. Having fiddled around with debugging a bit in Chrome and Firefox, I can't overstate the value of being able to do this. It turns out that edit and continue is supported for JS/HTML apps.

Visual Studio 11 includes a "debugging simulator" allowing debugging under different screen sizes and resolutions, even resolutions hire than the native monitor resolution thanks to some cunning scaling, although obviously everything gets a little blurry and unclear. This works via a terminal services connection to self, and seems pretty good. One of the other things it offers is the ability to simulate touch on a non-touch device.

Blend has been significantly enhanced. Apart from the fact that it now obviously supports HTML & CSS, it can also execute the JavaScript in your app which, if you think about it, is pretty much essential to render the visuals properly in many apps.

Visual Studio 11 includes some cool support in the area of 3D graphics, including the support of HLSL (High Level Shader Language) as a supported programming language with, I believe, all the usual refinements (IntelliSense, etc.).

This is part of a transcription of my notes from Microsoft's recent BUILD conference in Anaheim, CA, minus anything that might be considered Red Gate confidential. Thus, they're somewhat unstructured, sometimes ramble off-topic, and often contain dodgy grammar. My own commentary and observations will generally be italicised so you can easily distinguish it from the reporting on what actually happened. Much has already been said about this conference, and about Windows 8, but I hope you find these useful. Please feel free to comment or ask questions and I'll be happy to answer them as best I can.

Jensen Harris is Director of Program Management, Windows User Experience, Microsoft Corporation: http://jensenharris.com/. He hasn't blogged much since he worked on Office, but I imagine that's because Windows 8 has until fairly recently been TOP SECRET.

Started off by introducing the Windows 8 lock screen, which contains a summary of "the things you care about" - number of emails received, etc.

The start screen can be customised in terms of apps and tiles displayed and he used the phrase "in the gap is opportunity", meaning in this chunk of screen real estate is where you can persuade users to have your app tile, if you do it right.

He also showed the Windows Store (i.e., the app store), which isn't currently available in the Preview build.

What distinguishes Metro apps that succeed?

Metro style design

Apps should follow the Metro silhouette in terms of title, fonts, typography and so forth. MS have provided the templates to allow developers to do this in VS 11.

Content before Chrome

Said there's nothing wrong with chrome in a rich desktop application but that it shouldn't be the focus, and should be minimised or eliminated in a Metro-style app.

To this end the whole content area of the screen is for your app (no title bar, or other widgets). It's immersive, and it can be beautiful.

The Edge

The edge of the screen is important:

• You switch between apps by swiping in from the left
• The left and right edges are for system UI
• Left is semantically equivalent to Back, hence the app switching
• Right brings up "charms"
• The top and bottom edges are for your app
• But both should do the same thing
• You should only put very commonly used controls on the main canvas - the rest should go on the "app bar" at the bottom of the screen, although note that IE10 also uses the top of the screen for a second bar allowing you access to the different tabs containing each web page you have loaded
• ALL apps should work this way because it means that people will know how to use every app in Metro once they've learned these simple gestures

Touch First

• The touch interface provides a more natural and direct way to interact with the computer than, for example, a mouse - e.g., children tend to naturally want to poke the screen to interact and are less prone to think of picking up the mouse.
• Showed some heat maps overlaid on the metro UI illustrating the zones that people can comfortably reach on the screen of their tablet when it's held in two hands
• Most heat concentrated in the bottom left and right corners. Had zones people can reach without stretching, those they can reach with a bit of a stretch, and those areas which require a change of position to reach.
• Shows that app developers need to position controls near the edges of the screen.
• And is why app bar buttons are placed at the ends of the app bar, rather than centred by default.
• Also, hence the split keyboard option.

Used an RSS feed reader as an example of how to transform a desktop app into a Metro app:

• Firstly, remove links, boxes, blurs and gradients
• Then remove everything else, except the content
• Add typography
• Align content with grid

Now have RSS reader re-imagined as a Metro app.

Re-imagining apps is important. They should be:

• Beautiful
• Touch first
• Content lead
• Great at doing one thing, not mediocre at doing lots

Goal is "Fast & Fluid"

Fast & Fluid

1. Speed and responsiveness are incredibly important due to the directness of touch - it feels horrible to press a button, or whatever, on a touchscreen and get no reaction from the interface.
2. Fluid animations - things come from somewhere and go somewhere, they don't just abruptly appear.
3. A language for touch - e.g., when re-arranging tiles can use first finger to pick up and second finger to pan underneath more quickly than just dragging the icon to the edge of the screen and waiting for it to pan as far as you need.

Goals of the touch language:

• Simple & consistent
• Fast & fluid
• Limited gesture set
• Direct manipulation
• Sliding
• Reversible actions
• Limit use of timed gestures, which can be accidently triggered by novices, and frustrate advanced users

Examples:

• Swipe to select - slide finger down to select an item, and if you pull further you start to move it.
• Semantic zoom
• Display information relevant to zoom level
• Can get from one end of long list to other quickly with single gesture

Designing Touch First

Mouse and keyboard should work well without extra work - don't bifurcate your interface to suit each interaction mechanism because you don't need to do this. If you do you've obviously gone wrong somewhere along the way.

In summary, goal is fast and fluid. To get there:

• Measure responsiveness
• Use the animations library - this will give you most of what you need
• Embrace the touch language, and don't deviate from it

How to Scale Beautifully Across Form Factors

Screen sizes: 27"

HD (200dpi) and Ultra HD (250dpi) displays are coming soon.

Supporting the maximum number of form factors means you can maximise your potential market.

The built-in templates and controls already work across form factors. However, you must provide 3 asset sizes: 100%, 140%, and 180%. They don't anticipate that anyone will ever need to provide more since these will enable them to hit the limits of resolution of the human eye. Alternatively you can supply vectors as SVG, CSS primitives, or XAML.

Interface wise you must support:

• The minimum resolution of 1024 x 768
• Widescreen: 1366 x 768+
• The snap view (your app is docked in a narrow pane on the left of the screen) - this is required
• Optionally, a portrait view

More on the snapped state:

• You must provide this view
• Invites users to keep your app on screen
• Preserves context for users
• Is NOT a gadget - should be a fully functional view of your app
• 320ish pixels wide
• Allows people to do two things at once, which we often do, and which people seem wired to do today

Summary:

• Provide the three required asset sizes
• Provide the required snap view
• Optionally, provide a portrait view

Use the Right Contracts

Contracts bind apps together and bind apps to the system UI. Examples of contracts are share, search, and picker.

If two apps implement the same contract they can interact.

Note that contracts are only for Metro apps so it's not possible to use them to communicate between Metro and Win32 apps, or between Win32 apps. This is perhaps a shame, although understandable. The phrase that came up a few times on the subject of contracts is that they provide a "semantically rich clipboard", which makes a lot of sense when you see the current contract examples. I'm still not clear on whether or not it's possible to specify and implement your own contracts, although obviously even if it is I'd hold to the line that you should still use standard system contracts except where these really don't make sense - and if that's the case, you might just be able to reframe the problem so they do.

Contract Example - Share

The share contract is for sharing data. It sounds like it's really two sub-contracts: source, and target.

The sharing pane contains a list of apps that have identified themselves as targets. Sharing is asynchronous (or should be).

Every app should implement source, and in the broadest range of formats possible. Not every app needs to be a target though.

This isn't just about publishing to social media - it's about sharing between apps.

Contract Example - Search

This is a killer contract. Apps show results in their own UI in whatever format makes the most sense for those results.

• You should implement Search for apps that browse or create dynamic content, reference apps, or apps that otherwise have a searchable content index (and/or would have their own search UI if they didn't implement the contract).
• You should not implement search for games, novelty apps, and utilities.

Contract Example - Picker

When should I use this?

• If my app accesses or stores files that are useful elsewhere.
• If data is kept in a service, and where it makes sense it's good to do this, rather than have little turds of data (Jensen's term) spat all over the hard disk.

Doing this can make your app more valuable because it will provide easy access to content.

Tiles

These are not interesting in terms of being mere program launchers, like icons, which he described as "antiquated". They should be the front door to your application. They are connected and alive with activity, thus they draw you back to the app, or even make it so you don't need to open it at all because the important information is displayed as part of the tile.

They are also an extension of your app. They make apps feel like they're always running, even when they're not. They have a single hit target (i.e. no sub-widgets).

They are templated, so all you have to do is provide the text and images and Metro will do the rest.

They also allow people to pin key areas and content from within your app to the start screen. For example, you might pin the people you care about most in Socialite to your start screen. You can pin tiles from the app bar, and these pinned tiles have the same capabilities as other tiles (animation, etc.). You can also use Peek to add content and visual interest. Pinned tiles make your app more sticky and allow people to quickly get to the content they really care about.

Windows is Alive with Activity

Live tiles and notifications keep people connected to and draw them into your app. This makes it more likely that your app gets put on page one of the start screen by users.

The start screen doesn't have folders (c.f. current Start menu) but does have groups. Folders are bad because they put items down a level, make things feel less alive, and are hard to name. On the other hand people love to create groups (based on their observations), and they can name them or not, as they choose.

Peek functionality allows for multiple states in a tile. You don't need to worry about manually scheduling your tile to update - you just tell Windows that there's an update to the content and it will schedule when the update occurs.

Live tiles can be large or small. They can function like badges, containing some sort of count or overview stats. They should allow your app's personality to shine through.

There is also a Notification mechanism:

• Briefly bring up a popup message anywhere in Windows
• But there's no junk draw for them - critical notifications should also update the corresponding app tiles because they're shown once, and then they can't be retrieved if users miss them.
• Most apps should be silent, and notifications are opt-in
• Should only be used for information that must be interruptive

Live tiles and notifications use the same infrastructure, and there are three update mechanisms:

• Local (not entirely sure what this means)
• Scheduled (exactly what you'd expect)
• Push (Windows Notification Service - WNS), which will work even when your app isn't running.

Roam to the Cloud

Apps only run when on screen but should feel always alive. For example, if you finish a level on a game you should never have to do it again when you play the game on another device. Likewise, when you change an app or system setting, that change should be reflected across all your devices. E.g., °C vs. °F in your weather app, your RSS feeds, cities you're interested in, etc.

This is made possible by the cloud, and your settings information is tied to your Windows Live ID. Every app gets an allotment of content, which isn't gigs, but it's enough to store basic state information.

Should use the settings charm for settings rather than build your own UI.

You can imagine that this would also come in really useful for Win32 apps for storing settings, projects, and so forth but, of course, it's only available for Metro apps.

Process Lifetime

Great Metro apps preserve state as they go and don't have an explicit save. This is important because when your app is swiped off screen you have about 5 seconds to save state before it's suspended.

The kind of state you might save is, e.g., the furthest position I've read in an eBook, the last checkpoint I reached in a game, the last track I listened to in a media player.

Embrace Metro Principles

In conclusion:

1. Take pride in craftsmanship
2. Make your apps Fast & Fluid
3. Make the experience authentically digital
4. Do more with less
5. ? - didn't get this one down - TODO: watch end again

This is part of a transcription of my notes from Microsoft's recent BUILD conference in Anaheim, CA, minus anything that might be considered Red Gate confidential. Thus, they're somewhat unstructured, sometimes ramble off-topic, and often contain dodgy grammar. My own commentary and observations will generally be italicised so you can easily distinguish it from the reporting on what actually happened. Much has already been said about this conference, and about Windows 8, but I hope you find these useful. Please feel free to comment or ask questions and I'll be happy to answer them as best I can.

Michael Angiulo is Corporate Vice President, Windows Planning & Ecosystem, Microsoft Corporation: http://www.microsoft.com/presspass/exec/Angiulo/.

The first thing Michael talked about was the boot time for Windows 8, which is measured quite literally in seconds. They initially demoed this on a PC that had been designed to work with Windows 7, and had it boot in 8 seconds. I'm still a bit sceptical about this, even having used my Samsung slate for a while. This does seem to boot even from cold in about 5 - 8 seconds, but I wonder how the system will perform after I've installed a load of Win32 desktop apps and filled my registry with crud. Would love to be proven wrong.

Supports UEFI (http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface) which includes a sort of connected standby mode. Windows 8 is also very secure due to the implementation of BitLocker security - possibly with hardware support (? - I may be wrong about that last point).

Did a quick demo of Metro running on ARM hardware. I assume C++ Metro apps just require a recompile to run on ARM.

Demoed new "connected standy" state, which is a VERY low powered idle state offering instant on/off, and brings a phone-like power on/off experience to the PC.

Also supports USB3 and gave a quick demo of a USB3 versus USB2 file copy - obviously USB3 is MUCH faster.

Windows 8 now supports booting from disks up to 256TB, which improves significantly on Windows 7's support for disks up to only 2TB. Sounds insane but I'm sure we'll all take that for granted in five years time.

DirectX 11 looks really cool, and Michael gave a nice quick tech demo of this - the next generation of games are certainly going to have sweet graphics. In Windows 8 the whole OS sits on a hardware accelerated platform, so all rendering is done by DX11, and accelerated graphics come for free for all apps.

On the screen front, all touch screens must have "first pixel sensitivity" since Windows uses the first line of pixels along each edge of the screen to activate system and app bars, and to switch between apps. To me this seems to work variably on the Samsung developer preview hardware so you quite often have to swipe in from the edge two or three times to get a response from the system (e.g., bringing up settings & charms, switching back to the previous app, or bringing up the app bar).

You also get more functionality in Metro, and obviously more tiles on screen, as screen resolution increases.

Windows 8 provides a very simple Sensor API (is this only available to Metro apps via WinRT, or can it be accessed via desktop apps also?) to access the accelerometer, magnetometer, and gyroscope.

Also includes support for Near Field Communication (NFC - http://en.wikipedia.org/wiki/Near_field_communication) for sending data over very short distances (think centimeters). It's mainly about easing transactions and in this context seems to me mostly relevant for phones rather than larger form factors such as tablets, which might be a little unwieldy. That said, there may be other applications for easily transferring data between tablets or between phone and tablet, netbook, laptop, or desktop PC.

There is a unified notification mechanism for Metro style "device apps". "Device apps" are apps for items such as printers, connectivity (e.g., from 3G), etc. In the 3G example it's possible to use the USSD sideband protocol to query and update account information without incurring roaming charges. USSD = Unstructured Supplementary Service Data (http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data).

Showed a new (to Windows) laptop form factor - the "Ultrabook" - which offers an incredibly thin and powerful computing experience, rather like the MacBook Air. Inside the machine it turns out that most of the space is taken up by the battery, with a very small mainboard and integrated SSD.

It was at this point they also announced the Samsung "Windows Developer Preview PC", which later on in the day they handed out to all attendees - this includes some interesting stuff: the first public Windows 8 preview build, and the Visual Studio 11 Developer Preview.

This is part of a transcription of my notes from Microsoft's recent BUILD conference in Anaheim, CA, minus anything that might be considered Red Gate confidential. Thus, they're somewhat unstructured, sometimes ramble off-topic, and often contain dodgy grammar. My own commentary and observations will generally be italicised so you can easily distinguish it from the reporting on what actually happened. Much has already been said about this conference, and about Windows 8, but I hope you find these useful. Please feel free to comment or ask questions and I'll be happy to answer them as best I can.

Antoine Leblond is Senior Vice President, Windows Web Services at Microsoft Corporation: http://www.microsoft.com/presspass/exec/antoine/.

Figure 1. The marketecture diagram with which everyone's now so familiar. What it doesn't make clear is that managed code still runs inside the CLR and that the WinRT interfaces are exposed in the CLR just like those in any normal .NET assembly. JavaScript runs on the Chakra engine used by IE10 - in fact it seems pretty obvious to me that the whole HTML/CSS/JS story must basically run in IE10 with the WinRT interface exposed to it. (You can right-click and "Open image in new tab", or whatever your browser's equivalent is, for a larger view - sorry, it's still not great, but that's my shonky iPhone 3GS camera for you. OTOH, it's also all over the web so you can always Google for a better version.)

Interaction with Windows in the Metro environment is via the Windows Runtime APIs, or WinRT. Microsoft provide a unified toolset for developing Metro apps that allow you to pick the languages and technologies you want to use, which means you can bring forward and develop your existing skills, rather than have to learn a whole new technology afresh.

Demoed building a Javascript web application from a blank template in Visual Studio 2011 - something that will obviously already be very familiar to web developers.

(It was at this point I suddenly realised how annoying Steven Sinofsky's habit of interrupting other presenters must be to them. I wanted to wedgie the guy and toss him off the stage into the front row of developers to stave off the possibility of a worse rampage later on.)

Then went on to build a really simple Javascript/HTML5 Metro drawing application, using WinRT. Noticed that the event syntax in JavaScript sucks a bit because you have to use strings for the event names when you register event handlers. Oh well.

Showed that WinRT is exposed to and can be easily used from JavaScript by calling into it to bring up a file picker. JavaScript also supports asynchronous method calls using "promises".

He also turned a primitive app into a full touch photo picker app, which he automatically integrated with Socialite by implementing the "share" contract, allowing him to share back photos via the charm - photo uploading occurs asynchronously so the app remains responsive.

Showed Expression Blend 5, which can now work with HTML 5 & CSS, as well as XAML. It works in exactly the same way for both, so it's easy for existing Blend users to work with apps developed with HTML/CSS rather than XAML.

In the HTML version of the demo app the app bar at the bottom (swipe up or down from either bottom or top edge to bring up) is implemented as a

This is part of a transcription of my notes from Microsoft's recent BUILD conference in Anaheim, CA, minus anything that might be considered Red Gate confidential. Thus, they're somewhat unstructured, sometimes ramble off-topic, and often contain dodgy grammar. My own commentary and observations will generally be italicised so you can easily distinguish it from the reporting on what actually happened. Much has already been said about this conference, and about Windows 8, but I hope you find these useful. Please feel free to comment or ask questions and I'll be happy to answer them as best I can.

Steven Sinofsky is President of Microsoft's Windows and Windows Live DIvision: http://www.microsoft.com/presspass/exec/ssinofsky/, and http://en.wikipedia.org/wiki/Steven_Sinofsky.

I've only ever seen a short extract of Steven in a YouTube video previously, but apparently he has a reputation for execution. My impression of him is that he's taken care of himself, is confident, articulate and passionate. The latter seems to spill over into a habit of interrupting his co-presenters that might become rather annoying if you're one of them - OTOH a couple of those interruptions did seem to be rescue attempts, so kudos there.

Some interesting statistics:

• 450M copies of Windows 7 shipped, which is now more than Windows XP
• 542M Windows Live users
• (Later on Steve Ballmer shared that 350M Windows devices will be shipped this year)
• IE9 is the fastest growing web browser on Windows 7 - didn't quote actual market share though, and I wonder who it's stealing market share from out of Chrome, Firefox, or earlier versions of IE
• 1502 non-security-related changes and improvements have been made to the product since Windows 7 shipped

Since Windows 7 shipped the world has changed. We have seen a proliferation of form factors, from phones, through tablets, laptops, netbooks, and the faithful old desktop computer - didn't mention media servers, but I imagine because of small market share. More importantly he also didn't mention servers, virtualisation or the cloud, but there are obviously changes here too.

We have also seen the rise of touch and Microsoft believes that before long people will want touch everywhere, and that a monitor that doesn't support touch will soon seem laughably primitive. At the time I rather churlishly observed that if you use Apple devices you already know this, but this was obviously before we'd really seen anything of substance.

Mobility is also key - people expect to be able to use their devices, and access applications, data, and services on the move from wherever they happen to be.

We will also see more and more richly connected applications. By this we mean apps that connect to eachother, to other apps, and to a wide variety of cloud services to provide functionality we haven't yet imagined.

Windows 8 will be 100% Windows 7 compatible - it makes 7 better.

More than that, with 8, Microsoft wanted to "re-imagine Windows" from the chipset right through to the user experience. They also aim to provide access to the system for developers at every level with multiple layers of abstraction depending upon how much, and how directly, you need to interact with the hardware - although this has always been true to some extent, at least since the advent of DirectX.

Keynote demos coming up:

• Windows 8 Experience
• Metro Style Platform and Tools
• Hardware Platforms
• Cloud Services

Microsoft have focussed on fundamentals and have improved the performance and decreased the resource usage relative to Windows 7. Thus, base operating system resource usage after boot now looks like this:

• Windows 7 SP1: 404MB and 32 processes
• Windows 8: 281MB and 29 processes

This represents a saving of 25 - 30% over Windows 7 SP1, and somewhat more over the original Windows 7 release, although I didn't manage to grab the figures.

I've just posted up full details of this release on the .NET Reflector blog at http://www.reflector.net/2011/05/life-is-a-journey-not-a-destination-net-reflector-7-2-ea-1-has-been-released/ and, breaking with previous tradition, this includes a fairly extensive changelog.

You can download this EA build from the .NET Reflector homepage at http://www.reflector.net/.

Enjoy!

(And please don't forget to tell us what you think on the forum, http://forums.reflector.net/, using the tags #7.2 and #eap.)

Dodgy Bond references aside, I'm extremely happy to be able to tell you that we've just released our first .NET Reflector 7 Early Access build. We're going to make these available over the coming weeks via the main .NET Reflector download page at:

http://reflector.red-gate.com/Download.aspx

Please have a play and tell us what you think in the forum we've set up. Also, please let us know if you run into any problems in the same place.

The new version so far comes with numerous decompilation improvements including (after 5 years!) support for iterator blocks - i.e., the yield statement first seen in .NET 2.0. We've also done a lot of work to solidify the support for .NET 4.0. Clive's written about the work he's done to support iterator blocks in much more detail here, along with the odd problem he's encountered when dealing with compiler generated code: http://www.simple-talk.com/community/blogs/clivet/96199.aspx.

On the UI front we've started what will ultimately be a rewrite of the entire front-end, albeit broken into stages over two or three major releases. The most obvious addition at the moment is tabbed browsing, which you can see in Figure 1.

Figure 1. .NET Reflector's new tabbed decompilation feature. Use CTRL+Click on any item in the assembly browser tree, or any link in the source code view, to open it in a new tab.

This isn't by any means finished. I'll be tying up loose ends for the next few weeks, with a major focus on performance and resource usage. .NET Reflector has historically been a largely single-threaded application which has been fine up until now but, as you might expect, the addition of browser-style tabbing has pushed this approach somewhat beyond its limit. You can see this if you refresh the assemblies list by hitting F5. This shows up another problem: we really need to make Reflector remember everything you had open before you refreshed the list, rather than just the last item you viewed - I discovered that it's always done the latter, but it used to hide all panes apart from the treeview after a Refresh, including the decompiler/disassembler window.

Ultimately I've got plans to add the whole VS/Chrome/Firefox style ability to drag a tab into the middle of nowhere to spawn a new window, but I need to be mindful of the add-ins, amongst other things, so it's possible that might slip to a 7.5 or 8.0 release.

You'll also notice that .NET Reflector 7 now needs .NET 3.5 or later to run. We made this jump because we wanted to offer ourselves a much better chance of adding some really cool functionality to support newer technologies, such as Silverlight and Windows Phone 7.

We've also taken the opportunity to start using WPF for UI development, which has frankly been a godsend. The learning curve is practically vertical but, I kid you not, it's just a far better world. Really. Stop using WinForms. Now. Why are you still using it? I had to go back and work on an old WinForms dialog for an hour or two yesterday and it really made me wince. The point is we'll be able to move the UI in some exciting new directions that will make Reflector easier to use whilst continuing to develop its functionality without (and this is key) cluttering the interface. The 3.5 language enhancements should also enable us to be much more productive over the longer term.

I know most of you have .NET Fx 3.5 or 4.0 already but, if you do need to install a new version, I'd recommend you jump straight to 4.0 because, for one thing, it's faster, and if you're starting afresh there's really no reason not to.

Despite the Fx version jump the Visual Studio add-in should still work fine in Visual Studio 2005, and obviously will continue to work in Visual Studio 2008 and 2010. If you do run into problems, again, please let us know here. As before, we continue to support every edition of Visual Studio exception the Express Editions.

Speaking of Visual Studio, we've also been improving the add-in. You can now open and explore decompiled code for any referenced assembly in any project in your solution. Just right-click on the reference, then click Decompile and Explore on the context menu. Reflector will pop up a progress box whilst it decompiles your assembly (Figure 2) - you can move this out of the way whilst you carry on working.

Figure 2. Decompilation progress. This isn't modal so you can just move it out of the way and carry on working.

Once it's done you can explore your assembly in the Reflector treeview (Figure 3), also accessible via the .NET Reflector > Explore Decompiled Assemblies main menu item. Double-click on any item to open decompiled source in the Visual Studio source code view. Use right-click and Go To Definition on the source view context menu to navigate through the code.

Figure 3. Using the .NET Reflector treeview within Visual Studio. Double-click on any item to open decompiled source in the source code view.

There are loads of other changes and fixes that have gone in, often under the hood, which I don't have room to talk about here, and plenty more to come over the next few weeks. I'll try to keep you abreast of new functionality and changes as they go in.

There are a couple of smaller things worth mentioning now though.

Firstly, we've reorganised the menus and toolbar in Reflector itself to more closely mirror what you might be used to in other applications.

Secondly, we've tried to make some of the functionality more discoverable. For example, you can now switch decompilation target framework version directly from the toolbar - and the default is now .NET 4.0.

I think that about covers it for the moment. As I said, please use the new version, and send us your feedback. Here's that download URL again: http://reflector.red-gate.com/Download.aspx.

Until next time!

(Remember, you can also follow .NET Reflector's progress and updates on Twitter.)

Following on from my previous post, where I shared a Live Template for quickly declaring a normal read-write dependency property and its associated property change event boilerplate, here's an unsurprisingly similar template for creating a read-only dependency property.

       #region $PROPNAME$ Read-Only Property and Property Change Routed Event

        private static readonly DependencyPropertyKey $PROPNAME$PropertyKey = 
                                            DependencyProperty.RegisterReadOnly( 
            "$PROPNAME$", typeof ( $PROPTYPE$ ), typeof ( $DECLARING_TYPE$ ), 
            new PropertyMetadata( $DEF_VALUE$ , On$PROPNAME$Changed ) );

       public static readonly DependencyProperty $PROPNAME$Property =
                                           $PROPNAME$PropertyKey.DependencyProperty;

        public $PROPTYPE$ $PROPNAME$ 
        { 
            get { return ( $PROPTYPE$ ) GetValue( $PROPNAME$Property ); } 
            private set { SetValue( $PROPNAME$PropertyKey, value ); } 
        }

       public static readonly RoutedEvent $PROPNAME$ChangedEvent   =
                                           EventManager.RegisterRoutedEvent(
           "$PROPNAME$Changed",
           RoutingStrategy.$ROUTINGSTRATEGY$,
           typeof( RoutedPropertyChangedEventHandler< $PROPTYPE$ > ),
           typeof( $DECLARING_TYPE$ ) );

       public event RoutedPropertyChangedEventHandler< $PROPTYPE$ > $PROPNAME$Changed
       {
           add { AddHandler( $PROPNAME$ChangedEvent, value ); }
           remove { RemoveHandler( $PROPNAME$ChangedEvent, value ); }
       }

        private static void On$PROPNAME$Changed(
           DependencyObject d, DependencyPropertyChangedEventArgs e) 
        { 
            var $DECLARING_TYPE_var$ = d as $DECLARING_TYPE$; 
           var args = new RoutedPropertyChangedEventArgs< $PROPTYPE$ >(
               ( $PROPTYPE$ ) e.OldValue,
               ( $PROPTYPE$ ) e.NewValue );
           args.RoutedEvent    = $DECLARING_TYPE$.$PROPNAME$ChangedEvent;
           $DECLARING_TYPE_var$.RaiseEvent( args );$END$
        } 

       #endregion

The only real difference here is the addition of the DependencyPropertyKey, which allows your implementation to set the value of the dependency property without exposing the setter code to consumers of your type.

You'll probably find that you create read-only dependency properties much less often than read-write properties, but this should still save you some typing when you do need to do so.