Visual Studio Screen Real Estate

I have to say first that I am a total keyboard-freak. I use keyboard shortcuts for all Visual Studio and ReSharper commands. Over Christmas, my main dual-24”-screen development machine developed a fault, and I fell back to my (excellent and highly recommended) Lenovo ThinkPad X201. Of course screen real estate was suddenly an issue, and I decided to do something radical.

I got rid of all the toolbars.

Yep – all of them.

Literally, I right-clicked the toolbar, and un-checked every single one, in both design mode and debugging mode. I then found and installed the Hide Main Menu plugin for Visual Studio.

Now Visual Studio looks like this:

This is good, I like this. Then I fixed my desktop PC, and didn’t want to lose the goodness, but also wanted to make use of VS2010’s improved multi-monitor support. I exported All Settings->General Settings->Window Layouts options to SingleMonitor.vssettings, put that file into my shared DropBox folder to sync it to the desktop, imported it, and customised VS to look like this:

I’ve exported those window layouts to MultiMonitor.vssettings, so I can easily switch between them. Sometimes I move to a single screen even on the desktop in order to read documents/websites on the secondary monitor, or when screen sharing with my colleagues.

If you want my window layout files, you can find them on my box.net page.

Additional Tips:

1. Don’t forget when customising your window layouts to also customise them when debugging, as VS will switch between layouts as you start and finish debugging.
2. Try closing toolwindows too. If you learn the shortcuts to get them back (or alternatives) it makes for a much cleaner feel.
3. Try replacing the solution explorer with ReSharper’s “CTRL+T” command. It’s faster and doesn’t take up space.
4. Try working in full-screen mode when actually coding (toggle using SHIFT+ALT+ENTER).

I appreciate I may have taken this as far as I could without using vi or something, but hopefully it serves as a little inspiration.

HTH.

Advertisements

Rabbit in the headlights (Windows Identity Foundation woes)

I’m working on a new project at work, and part of my role as architect is to decide how we’re going to build authentication and authorisation. This will be a desktop smart client application deployed via ClickOnce that will use web services (hosted by us at our datacentre) to operate, with a dash of local caching for offline operation where applicable. We already have an ASP.NET website that has auth/authz behind it, so ideally I’d like to build on that.

After much internetting, I re-discovered Windows Identity Foundation (WIF), having heard a little about it on a DotNetRocks episode some time back. I like the concepts – separating auth/authz from your applications and instead obtaining tokens containing the claims the user has.

Sounds great. In theory.

In practice, it’s appears WIF suffers from “Over-engineering Microsoft Giddyness” syndrome. I’ve watched various WCF Pluralsight videos (which are excellent, by the way) to try and get a basis of understanding for WIF, but when I really got into WIF itself, it’s too much for my small brain to cope with.

Essentially I’ve worked out that I want to have an “Identity Provider” that my desktop app can authenticate with, and that will return a security token in exchange for a valid username and password. I then want to be able to pop that token into subsequent calls to the other WCF services, which will then investigate the claims supplied in that token to establish whether the user can carry out those operations or not. However it seems writing my own Identity Provider that works off our user store is, ahem, “non-trivial”. There are a few choices of existing ones out there in the world., but it all seems like over-kill to me.

So I’m going to steal the idea and Build My Own. I’ll have a WCF service that is accessed via SSL that will return a token containing various information (“claims” in WIF parlance) about the user in exchange for a valid username and password. This token will then be made available in the SOAP headers of calls to our other web services (also accessed via SSL, so it’s okay ).

I know what some of my readers will be thinking – that there’s a reason for the engineering that’s gone into WIF. The truth is that this approach should work just as well. I’ll need to have a think about possibly signing the token and encrypting it so that the web services can be confident the data hasn’t been tampered with or otherwise intercepted, but I’m willing to be my small brain comes up with The Simplest Thing That Could Possibly Work. A key tenant of Domain Driven Design, and something else I’m going to strive for on this project.