Scott Hanselman

Congrats to Miguel (nice guy and a fine dancer) and team for the release of Moonlight 1.0. What is it?

"Implementation of Silverlight for Unix systems has officially reached its 1.0 level. We are feature complete, we pass all the Microsoft regression test suites and we shipped support for Microsoft's Media Pack for x86 and x86-64 architectures.

Moonlight is available as a Firefox plugin that can be installed with a single click from the moonlight download page."

It's an implementation of Silverlight 1.0 for Unix. That includes graphics, video/audio and the JavaScript bridge. It's not Silverlight 2.0, yet, so it has no execution engine. There's no CLR. Rather one uses Javascript to do work.

In the future (pronto, espero, Miguel?) Moonlight 2.0 will be the Unix version of Silverlight 2.0 and include the ECMA CLR execution engine (fancy words for "CLR on Linux in the browser").

You can watch a Silverlight, ahem, 2, screencast of the installation process over on Tim's blog or check these static screenies of me running OpenSUSE and Firefox, visiting http://videoshow.vertigo.com/ (a Silverlight 1.0 site), installing Moonlight, and watching a video. If you want to try it, you can burn a LiveCD (bootable ISO) that includes it here.

Moonlight 1.0 Installation Screenshots

I'm running OpenSuse 10.3 and Firefox 2, just to point out that you don't have to be super-bleeding edge to run this plugin. I visit http://videoshow.vertigo.com/ first, and I get the Microsoft Silverlight plug-in download badge.

Note that the folks that ran this page have not coded specially for Moonlight. When the badge is shown, clicking on it sends you to a Microsoft link that will sniff your browser and OS and send you to the right place for Silverlight. If Microsoft sees you need Silverlight 1.0 and you've got Linux, you're sent to http://www.go-mono.com/moonlight. This is cool (read: no evil) as Microsoft's detection code redirects you to Mono. Next, you get this screen:

Now, I select 32-bit vs. 64-bit, the click Download the Plugin, and I get the standard Firefox installation dialog, like any Firefox plugin:

Click "Install Now" and restart Firefox. I hit http://videoshow.vertigo.com/ and I can see the Silverlight application right there.

At this point in our installation, you're running all Open Source software. You won't, however, be able to play videos that require non-Open-Source-ed codecs. But, you can install the Microsoft Media Pack that includes codecs Microsoft has made available for Moonlight by right clicking on the Silverlight player and clicking "Install Microsoft Media Pack." Or, you'll be prompted the first time the Silverlight app tries to play the media.

Even thought Moonlight 1.0 exposes Silverlight 1.0 features, it uses a 2.0 media stack (minus DRM). That means, you can use media that uses these codecs:

Video:

• WMV1: Windows Media Video 7
• WMV2: Windows Media Video 8
• WMV3: Windows Media Video 9
• WMVA: Windows Media Video Advanced Profile, non-VC-1
• WMVC1: Windows Media Video Advanced Profile, VC-1

Audio:

• WMA 7: Windows Media Audio 7
• WMA 8: Windows Media Audio 8
• WMA 9: Windows Media Audio 9
• WMA 10: Windows Media Audio 10
• MP3: ISO/MPEG Layer-3
  • Input: ISO/MPEG Layer-3 data stream
  • Channel configurations: mono, stereo
  • Sampling frequencies: 8, 11.025, 12, 16, 22.05, 24, 32, 44.1, and 48 kHz
  • Bit rates: 8-320 kbps, variable bit rate
  • Limitations: "free format mode" (see ISO/IEC 11172-3, sub clause 2.4.2.3) is not supported.

Basically, the first time that Moonlight hits a page that contains media, it will ask you whether you want to install the Microsoft Media Pack which contains the codecs for all of the formats listed before. Microsoft offers the codecs for Linux on x86 and Linux x86-x64. If you want codecs on other *nix platforms, go vote here.

Now, click a video, and it'll play nicely in Moonlight on Linux:

Very cool. It was a smooth and fast install and it runs great. Where's Moonlight 2.0?! ;) Seriously, though, congrats to the team. If you want to check out the source for Moonlight 1.0, you can find it here.

Detecting and Supporting Moonlight and Google Chrome

While the Video.Show guys didn't have to do anything to support Moonlight, if you want to really customize the detection experience, make sure to visit Tim's blog post on Moonlight and Silverlight Detection scripts. He's updated the Silverlight.supportedUserAgent.js helper script to check for Linux and report correctly, and shows you how to hack in support (the currently unsupported but seems to work but don't quote me on that) for Google Chrome.

If you're interested in learning more about Silverlight, check out http://silverlight.net/learn/ as it's full of video tutorials and samples.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

I'm running 64-bit operating systems on every machine I have that is capable. I'm running Vista 64 on my quad-proc machine with 8 gigs of RAM, and Windows 7 Beta 64-bit on my laptop with 4 gigs.

Writing managed code is a pretty good way to not have to worry about any x86 (32-bit) vs. x64 (64-bit) details. Write managed code, compile, and it'll work everywhere.

The most important take away, from MSDN:

"If you have 100% type safe managed code then you really can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR."

If you do that, you're golden. Moving right along.

WARNING: This is obscure and you probably don't care. But, that's this blog.

Back to 32-bit vs. 64-bit .NET Basics

I promote 64-bit a lot because I personally think my 64-bit machine is snappier and more stable. I also have buttloads of RAM which is nice.

The first question developer ask me when I'm pushing 64-bit is "Can I still run Visual Studio the same? Can I make apps that run everywhere?" Yes, totally. I run VS2008 all day on x64 machines writing ASP.NET apps, WPF apps, and Console apps and don't give it a thought. When I'm developing I usually don't sweat any of this. Visual Studio 2008 installs and runs just fine.

If you care about details, when you install .NET on a 64-bit machine the package is bigger because you're getting BOTH 32-bit and 64-bit versions of stuff. Some of the things that are 64-bit specific are:

• Base class libraries (System.*)
• Just-In-Time compiler
• Debugging support
• .NET Framework SDK

For example, I have a C:\Windows\Microsoft.NET\Framework and a C:\Windows\Microsoft.NET\Framework64 folder.

If I File|New Project and make a console app, and run it, this is what I'll see in the Task Manager:

Notice that a bunch of processes have *32 by their names, including devenv.exe? Those are all 32-bit processes. However, my ConsoleApplication1.exe doesn't have that. It's a 64-bit process and it can access a ridiculous amount of memory (if you've got it...like 16TB, although I suspect the GC would be freaking out at that point.)

That 64-bit process is also having its code JIT compiled to use not the x86 instruction set we're used to, but the AMD64 instruction set. This is important to note: It doesn't matter if you have an AMD or an Intel processor, if you're 64-bit you are using the AMD64 instruction set. The short story is - Intel lost. For us, it doesn't really matter.

Now, if I right click on the Properties dialog for this Project in Visual Studio I can select the Platform Target from the Build Tab:

By default, the Platform Target is "Any CPU." Remember that our C# or VB compiles to IL, and that IL is basically processor agnostic. It's the JIT that makes the decision at the last minute.

In my case, I am running 64-bit and it was set to Any CPU so it was 64-bit at runtime. But, to repeat (I'll do it a few times, so forgive me) the most important take away, from MSDN:

"If you have 100% type safe managed code then you really can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR."

Let me switch it to x86 and look at Task Manager and we see my app is now 32-bit.

Cool, so...

32-bit vs. 64-bit - Why Should I Care?

Everyone once in a while you'll need to call from managed code into unmanaged and you'll need to give some thought to 64-bit vs. 32-bit. Unmanaged code cares DEEPLY about bitness, it exists in a processor specific world.

Here's a great bit from an older MSDN article that explains part of it with emphasis mine:

In 64-bit Microsoft Windows, this assumption of parity in data type sizes is invalid. Making all data types 64 bits in length would waste space, because most applications do not need the increased size. However, applications do need pointers to 64-bit data, and they need the ability to have 64-bit data types in selected cases. These considerations led the Windows team to select an abstract data model called LLP64 (or P64). In the LLP64 data model, only pointers expand to 64 bits; all other basic data types (integer and long) remain 32 bits in length.

The .NET CLR for 64-bit platforms uses the same LLP64 abstract data model. In .NET there is an integral data type, not widely known, that is specifically designated to hold 'pointer' information: IntPtr whose size is dependent on the platform (e.g., 32-bit or 64-bit) it is running on. Consider the following code snippet:

[C#]
public void SizeOfIntPtr() {
Console.WriteLine( "SizeOf IntPtr is: {0}", IntPtr.Size );
}

When run on a 32-bit platform you will get the following output on the console:

SizeOf IntPtr is: 4

On a 64-bit platform you will get the following output on the console:

SizeOf IntPtr is: 8

Short version: If you're using IntPtrs, you care. If you're aware of what IntPtrs are, you likely know this already.

If you checked the property System.IntPtr.Size while running as x86, it'll be 4. It'll be 8 while under x64. To be clear, if you are running x86 even on an x64 machine, System.IntPtr.Size will be 4. This isn't a way to tell the bitness of your OS, just the bitness of your running CLR process.

Here's a concrete example. It's a pretty specific edgy thing, but a decent example. Here's an app that runs fine on x86.

using System;
using System.Runtime.InteropServices;

namespace TestGetSystemInfo
{
    public class WinApi
    {
        [DllImport("kernel32.dll")]
        public static extern void GetSystemInfo([MarshalAs(UnmanagedType.Struct)] ref SYSTEM_INFO lpSystemInfo);

        [StructLayout(LayoutKind.Sequential)]
        public struct SYSTEM_INFO
        {
            internal _PROCESSOR_INFO_UNION uProcessorInfo;
            public uint dwPageSize;
            public IntPtr lpMinimumApplicationAddress;
            public int lpMaximumApplicationAddress;
            public IntPtr dwActiveProcessorMask;
            public uint dwNumberOfProcessors;
            public uint dwProcessorType;
            public uint dwAllocationGranularity;
            public ushort dwProcessorLevel;
            public ushort dwProcessorRevision;
        }

        [StructLayout(LayoutKind.Explicit)]
        public struct _PROCESSOR_INFO_UNION
        {
            [FieldOffset(0)]
            internal uint dwOemId;
            [FieldOffset(0)]
            internal ushort wProcessorArchitecture;
            [FieldOffset(2)]
            internal ushort wReserved;
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            WinApi.SYSTEM_INFO sysinfo = new WinApi.SYSTEM_INFO();
            WinApi.GetSystemInfo(ref sysinfo);
            Console.WriteLine("dwProcessorType ={0}", sysinfo.dwProcessorType.ToString());
            Console.WriteLine("dwPageSize      ={0}", sysinfo.dwPageSize.ToString());
            Console.WriteLine("lpMaximumApplicationAddress ={0}", sysinfo.lpMaximumApplicationAddress.ToString());
        }
    }
}

See the mistake? It's not totally obvious. Here's what's printed under x86 (by changing the project properties):

dwProcessorType =586
dwPageSize      =4096
lpMaximumApplicationAddress =2147418111

The bug is subtle because it works under x86. As said in the P/Invoke Wiki:

The use of int will appear to be fine if you only run the code on a 32-bit machine, but will likely cause your application/component to crash as soon as it gets on a 64-bit machine.

In our case, it doesn't crash, but it sure is wrong. Here's what happens under x64 (or AnyCPU and running it on my x64 machine):

dwProcessorType =8664
dwPageSize      =4096
lpMaximumApplicationAddress =-65537

See that lat number? Total crap. I've used an int as a pointer to lpMaximumApplicationAddress rather than an IntPtr. Remember that IntPtr is smart enough to get bigger and point to the right stuff. When I change it from int to IntPtr:

dwProcessorType =8664
dwPageSize      =4096
lpMaximumApplicationAddress =8796092956671

That's better. Remember that IntPtr is platform/processor specific.

You can still use P/Invokes like this and call into unmanaged code if you're on 64-bit or if you're trying to work on both platforms, you just need to be thoughtful about it.

Gotchas: Other Assemblies

You'll also want to think about the assemblies that your application loads. It's possible that when purchasing a vendor's product in binary form or bringing an Open Source project into your project in binary form, that you might consume an x86 compiled .NET assembly. That'll work fine on x86, but break on x64 when your AnyCPU compiled EXE runs as x64 and tries to load an x86 assembly. You'll get a BadImageFormatException as I did in this post.

The MSDN article gets it right when it says:

...it is unrealistic to assume that one can just run 32-bit code in a 64-bit environment and have it run without looking at what you are migrating.

As mentioned earlier, if you have 100% type safe managed code then you really can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR.

But more than likely the managed application will be involved with any or all of the following:

• Invoking platform APIs via p/invoke
• Invoking COM objects
• Making use of unsafe code
• Using marshaling as a mechanism for sharing information
• Using serialization as a way of persisting state

Regardless of which of these things your application is doing it is going to be important to do your homework and investigate what your code is doing and what dependencies you have. Once you do this homework you will have to look at your choices to do any or all of the following:

• Migrate the code with no changes.
• Make changes to your code to handle 64-bit pointers correctly.
• Work with other vendors, etc., to provide 64-bit versions of their products.
• Make changes to your logic to handle marshaling and/or serialization.

There may be cases where you make the decision either not to migrate the managed code to 64-bit, in which case you have the option to mark your assemblies so that the Windows loader can do the right thing at start up. Keep in mind that downstream dependencies have a direct impact on the overall application.

I have found that for smaller apps that don't need the benefits of x64 but need to call into some unmanaged COM components that marking the assemblies as x86 is a reasonable mitigation strategy.  The same rules apply if you're making a WPF app, a Console App or an ASP.NET app. Very likely you'll not have to deal with this stuff if you're staying managed, but I wanted to put it out there in case you bump into it.

Regardless, always test on x86 and x64.

Related Posts

• 32-bitness and 64-bitness and migrating DasBlog on IIS7 and ASP.NET under Vista x64

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

I used to hate podcasts, but that didn't last long. I got a longer commute, bandwidth became less of an issue and podcasts, frankly, got better. Of course, I'm a smidge biased.

I listen to a number of podcasts, not all technical, of course. I also watch the nightly news and a number of other news and political TV shows delivered not over the air or via cable, but by podcast.

Here's some technical podcasts, collected and recommended by my folks and friends on Twitter. I've heard some, and added my thoughts. Others I look forward to listening to. They are listed in no particular order. I threw mine in there as well. ;)

NOTE: If you've created a list of YOUR favorite .NET Podcasts, send me a link to your blog and I'll add it here:

• Steve Bohlen's Podcast Playlist for .NET Developers
• Caffeinated Coder's Podcast Roundup
• Matt Penner's "Podcasts Worth Listening To"
• Canadian Developers "Audio Resources On the Go" for the Developer
• Rhonda Tipton's (Epic) Podcast List
• Walden's ".NET Podcasts that are on my iPod"
• ...

And here's mine:

Hanselman's Super Karate Death Car List of .NET and Software Podcasts

Thoughtworks IT Matters - I respect a lot of the guys over at Thoughtworks so I'll give this a listen just based on that. It looks like it's updated infrequently, and there's no dates on their shows on the site (the RSS includes them), so hopefully they'll get a nice meter going and perhaps commit to a monthly or weekly schedule. Looks promising and fairy platform-agnostic, so likely useful for anyone programming in any language.

Hanselminutes - I'll let Scott Bellware's tweeted review of my show speak, rather than toot my own horn: "the one i look forward to is hanselminutes. know it? host is a bit of a nut, but ethical and with a heart :)"

I'm a .NET person, but I also dabble in Ruby and did some time at Nike coding Java. I also like gadgets so the show has become all of the above plus (I think) interesting interviews.

.NET Rocks - The first and longest running, now on show #418 which is CRAZY. Richard and Carl set the standard for those that followed them. Often interviews, sometimes random, always interesting, .NET Rocks is the gold standard.

ALT.NET Podcast - "You're the type of developer who uses whatever works while keeping an eye out for a better way, you reach outside the mainstream to adopt the best of any community, you're not content with the status quo and you realize that tools are great, but they only take you so far..." this might be the podcast for you.

Sparkling Client - Entirely focused on Silverlight and RIA (Rich Internet Application) technologies, I'd call this an "up and comer" in the .NET podcast world.

ASP.NET Podcast by Wally McClure - The site design is a little wacky, but Wally's got 130+ podcasts focused entirely on ASP.NET and the content continues. He has covered Azure, lots of ASP.NET AJAX, jQuery and many other topics.

Polymorphic Podcast - Craig Shoemaker works for Infragistics and hosts this .NET focused podcast. It's a little spotty as far as the frequency of updates, but he has an easy style and focuses a lot of ASP.NET. He's also had a couple of killer interviews like his one with craigslist founder Craig Newmark.

Herding Code - Hosted by K. Scott Allen, Kevin Dente, Scott Koon and Jon Galloway, this is kind of the TWiT of .NET podcasts. If you ever wish you could go to coffee and shoot the sh*t with some really smart folks, but you just can't find enough find enough smart guys or enough coffee, look no farther than Herding Code. Each host has a different perspective that adds to the conversation. The sound quality and leveling can be a little off, but not enough to distract from the good content.

Software Engineering Radio - A language and platform agnostic show, these folks have over 120 shows in the can. The audio quality has been a little inconsistent, but the content is diverse and the guests are first class. Frankly this is one of the most diverse podcasts out there, and they do it without sacrificing depth. Recommended.

The Java Posse - To understand .NET, one has to understand that which came before. The Java Posse has hosts from Sun, Google and Navigenics and is a really quick and terse way to get up to speed on what's happening in the world of Java. It tends to be a little random and conversational, but they have VERY thorough show notes and links. If you're into Java or selling against Java, a podcast to watch.

OpenWeb Podcast - It's new, but it's got John Resig. They are still getting the handle of the audio and tend to have problems overdriving the microphone and have issues with leveling and so that's a little distracting. However, it's got some really smart Google and Mozilla employees talking about the Open Web and how to keep it open. They also get +2 Charisma for publishing not only in MP3 but also in (the kind of irrelevant but totally open) OGG Vorbis format.

They have been REALLY spotty, publishing only every month or two, but that's probably because they are DOING things to make the web better. Let's pressure them to publish more.

Ruby on Rails Podcast - Also pretty spotting on their publish dates, but always a good overview about what's going on in the world of Ruby on Rails. Tends to be a little chattier than I like in a technical podcast "Hey, how's it going, good, how's the weather" but that's a stylistic thing.

Elegant CodeCast - With a spin towards the Agile/TDD crowd, Elegant CodeCast puts on a show on a roughly twice a month basis.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

In an ongoing series on different reasons that I suck, I wanted to share another interesting quasi-debugging story about this public ADO.NET Data Services (Astoria) service I'm trying to help get live at a large company.

I'd mentioned how I had some trouble with UrlScan and Astoria Services in my post on "RTFLF - Read the Expletive Log File."

UrlScan 3.1 is a security tool that restricts the types of HTTP requests that IIS will process. By blocking specific HTTP requests, the UrlScan 3.1 security tool helps to prevent potentially harmful requests from reaching applications on the server. UrlScan 3.1 is an update to UrlScan 2.5 supports IIS 5.1, IIS 6.0 and IIS 7.0 on Windows Vista and Windows Server 2008.

UrlScan is a really valuable tool and a really powerful way to slap down evil and attacks on your Web Server. It is VERY configurable and very powerful and takes a clear mind to make sure that all your application's URLs work well while still preventing evil. Learn how to setup UrlScan here.

When we moved the service onto a production machine, it turned out that their production UrlScan.ini was locked down more than development. They were disallowing single quotes in QueryStrings as well as Dots in Url Paths.

The trick was that they haven't partitioned their sites up by subdomain, or website, just AppDomain. This means that they have 40+ "logical sites" running under one instances of IIS6, which means that they can't setup a separate IIS site with their own configuration and instance of the UrlScan ISAPI Filter. They also didn't feel like making a separate domain or subdomain just for our one little service.

OK, blah blah blah, background, right? So where did things go wrong?

URLScan has a section in the UrlScan.ini file called [AlwaysAllowedUrls] that does just that. It allows access to any URL in that section. Adding a URL there will make UrlScan completely ignore it.

I added our service to this section like this:

[AlwaysAllowedUrls]
/foo/MyService.svc

And I thought this would work. It DID allow us to request that Url. However, no other Astoria queries worked.

When you traverse Entities in ADO.NET Data Services (Astoria), your URLs look like this, for example:

/foo/MyService.svc/Cars()
/foo/MyService.svc/Cars()$filter=((Visible%20eq%20true)

And I didn't initially see why these were being blocked.

The issue, pointed out to me by the IIS Team's Wade Hilmo (check out his blog) was obvious (hence: I suck). The URL isn't the file, it's everything before the ?. It's everything before the QueryString. This is one of those "Duh" moments, and was my bad. I know the difference, of course, and understand Urls fully, but I completely brain-farted this obvious point when looking at ADO.NET Data Service queries and had been mentally parsing them wrong for hours. Once Wade set me straight, configuring UrlScan.ini was trivial:

In the ADO.NET Data Services parlance, the Entities exist after the .svc filename, but before the ? delimiter. Once we added those to our UrlScan.ini file, we were able to maintain the existing state of "super locked-down-ed-ness" while still allowing our services to run.

It is not possible to have a SQL Injection attack on a ADO.NET Data Service, due to the complete query rewrite that happens server side when a URL query comes into the system. The analogy is to think of in the same way that a LINQ query goes through a complete query re-write or a translation layer before it actually gets executed as SQL on the server. This re-write or translation is the layer of protection against SQL Injection attacks.

I was happy to learn that I could have my Cake ADO.NET Data Services and my UrlScan too.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

ModelBinders are great. I've blogged a bit about them before like the File Upload Model Binder.

I am working on some code like this:

[Authorize]
public ActionResult Edit(int id) {

    Dinner dinner = dinnerRepository.FindDinner(id);

    if (dinner.HostedBy != User.Identity.Name)
        return View("InvalidOwner");

    var viewModel = new DinnerFormViewModel {
        Dinner = dinner,
        Countries = new SelectList(PhoneValidator.Countries, dinner.Country)
    };

    return View(viewModel);
}

It's pretty straight forward, but this Controller knows too much. It's reaching into implicit parameters. The id was passed in, but the User is actually a property of the Controller base class and ultimately requires an HttpContext. Having this method "know" about the User object, and worse yet, having the User object go reaching into HttpContext.Current makes this hard to test.

I'd like to have the convenience of passing in the User (actually an IPrincipal interface) when I want to test, but when I'm running the app, I'd like to have the IPrincipal get passed into my method automatically. Enter the Model Binder. I need to teach ASP.NET MVC what to do when it sees a type as a parameter.

This quickie model binder is now responsible for one thing - it knows how to reach down into the HttpContext and get the current User (IPrincipal). It has one single responsibility.

public class IPrincipalModelBinder : IModelBinder
{
    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        if (controllerContext == null) {
            throw new ArgumentNullException("controllerContext");
        }
        if (bindingContext == null) {
            throw new ArgumentNullException("bindingContext");
        }
        IPrincipal p = controllerContext.HttpContext.User;
        return p;
    }
}

Now I can release the Controller from the emotional baggage of knowing too much about the User object. It can just have that passed in automatically by the framework. I just need to register the binder to tell folks about it. I can either do it on a one-off basis and put an attribute on this one method parameter:

public ActionResult Edit(int id,                        
                         [ModelBinder(typeof(IPrincipalModelBinder))]                        
                         IPrincipal user)
{...}

But even better, I can just tell the whole application once in the global.asax:

void Application_Start() {
    RegisterRoutes(RouteTable.Routes); //unrelated, don't sweat this line.
    ModelBinders.Binders[typeof(IPrincipal)] = new IPrincipalModelBinder();
}

Now that ASP.NET MVC knows what to do when it see an IPrincipal as a method parameter, my method gets nicer.

[Authorize]
public ActionResult Edit(int id, IPrincipal user) {

    Dinner dinner = dinnerRepository.FindDinner(id);

    if (dinner.HostedBy != user.Identity.Name)
        return View("InvalidOwner");

    var viewModel = new DinnerFormViewModel {
        Dinner = dinner,
        Countries = new SelectList(PhoneValidator.Countries, dinner.Country)
    };

    return View(viewModel);
}

Now I can test my controller more easily by passing in fake users. No need for mocking in this case!

[TestMethod]
public void EditAllowsUsersToEditDinnersTheyOwn()
{
    // Arrange
    DinnersController controller = new DinnersController(new TestDinnerRespository());

    // Act
    IPrincipal FakeUser = new GenericPrincipal(new GenericIdentity("Scott","Forms"),null);
    ViewResult result = controller.Edit(4, FakeUser) as ViewResult;

    // Yada yada yada assert etc etc etc
    Assert.IsTrue(result.ViewName != "InvalidOwner");
}

Fun stuff.

UPDATE: Phil had an interesting idea. He said, why not make method overloads, one for testing and one for without. I can see how this might be controversial, but it's very pragmatic.

[Authorize]
public ActionResult Edit(int id)
{
    return Edit(id, User); //This one uses HttpContext
}

You'd use this one as before at runtime, and call the overload that takes the IPrincipal explicitly for testing.

Yes, I realize I could use an IoC container for this also.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By