Thursday 24 September 2009

The Guild Season 3 Ep 3

This show is great,

<br/><a href="http://video.msn.com/video.aspx?mkt=en-US&amp;vid=80a029bc-7a7a-4f6e-b63c-8c4e73975e20" target="_new" title="Season 3 - Episode 3: Player Down">Video: Season 3 - Episode 3: Player Down</a>

Migrating Classic ASP.NET to ASP.NET MVC 2 – Project

I always laugh when I see ASP.NET referenced as Classic ASP.NET after I was exposed to “Classic” asp for a little while last year.  I mean no insult to anyone, it’s still a very relevant and popular framework, but it makes it easier for me to differentiate it in my blog.

This post by Maarten Balliauw is old, but still very relevant on how to migrate ASP.NET to ASP.NET MVC.  It was put together during the beta of version 1 so there are a few things missing, but it does include 95% of what you need to do.  I don’t want to re-cover someone else’s work, so I’ll assume you’ve started there before you found this page.

Extra Bits

One thing the article leaves out is that you won’t have the ability to right click your Controllers folder to add a new controller.  While this doesn’t really stop you from adding controllers as they are just classes, it does cause you to spend extra time writing the wrapper information and leaves the possibility of error more open.  Fortunately this is easy to enable.  In the project file (aspmvcwebsite.csproj or whatever) you’ll find this line in bold:

   1: <PropertyGroup>
   2:     <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
   3:     <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
   4:     <ProductVersion>9.0.30729</ProductVersion>
   5:     <SchemaVersion>2.0</SchemaVersion>
   6:     <ProjectGuid>{9383F928-27DF-4A63-B30B-F79FF733B034}</ProjectGuid>
   7:     <ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
   8:     <OutputType>Library</OutputType>
   9:     <AppDesignerFolder>Properties</AppDesignerFolder>
  10:     <RootNamespace>AdminWebUI</RootNamespace>
  11:     <AssemblyName>AdminWebUI</AssemblyName>
  12:     <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
  13: </PropertyGroup>

It won’t, of course, be in bold in the csproj file, the ProjectTypeGuids define the flavour of project you chose when you started the project and it’s what the MVC framework looks for to setup your context sensitive menu.  All you need to do is add another flavour so your project type looks like an ASP.NET MVC project type.  If you create an ASP.NET MVC project and check out the csproj file you’ll see the extra guid you need, I’m not sure if it’s all the same for all flavours of MVC but mine was:

   1: {F85E285D-A4E0-4152-9332-AB1D724D3325};

Add this in first and you’ll have

   1: <ProjectTypeGuids>{F85E285D-A4E0-4152-9332-AB1D724D3325};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>

Reload your project and you’ll have ASP.NET MVC context sensitive menus.  You can still add web forms and whatever else you like throughout your project.

View Web.config

If you’re going to have strongly typed views, very important for ASP.NET MVC, then you’ll also need the Web.config file in your Views folder.  I would suggest creating a new ASP.NET MVC project and then copying the file into the folder in your migration application.

Conclusion

That’s pretty much all you need.  You can run the two side by side with very little effort.  If you have any other issues, just compare the web.config files from a new ASP.NET MVC site with the config file that you already have and move the differences.  ASP.NET MVC 2 has this for example:

<dependentAssembly>
    <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35"/>
    <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

That you’ll need when it gets to IIS, but is not needed locally. 

 

Hopefully someone finds this useful.

Thursday 10 September 2009

The Guild Season 3 Episode 2

I love this show, and now it’s embeddable.

<br/><a href="http://video.msn.com/video.aspx?mkt=en-US&amp;vid=bdab0fe5-ecc7-4f5e-a946-feefa45d531b" target="_new" title="Season 3 - Episode 2: Anarchy!">Video: Season 3 - Episode 2: Anarchy!</a>

SHB6100 Works with iPhone 3.1

I love my Philips headset, I used to use it with my nokia all the time. Alas even with bluetooth my iPhone has never been able to use them. With the advent of 3.0 I was promised AD2P, but again my hopes were dashed when they didn’t work due to a protocol issue apparently. Finally my dreams of listening to music wirelessly have come to fruition with the advent of iPhone 3.1.

The Philips SHB6100 and I suspect all the SHB models will now work with the iPhone as a music player. Just connect them and you’re good to go. Not only that, but the volume, play / pause all work for me now too (skip buttons are no good) as well as answering calls and of course talking.

So if you’ve been hanging out for the iPhone to start working with this truly quality bluetooth headset, wait no longer.

Tuesday 8 September 2009

Assert that a method was called with Rhino Mocks

This is not all that hard or difficult to figure out on your own, but hopefully it helps someone who’s stuck.  If you want to test that a method was called with Rhino Mocks, it’s easy!

Usually you want to assert that a method was called if you’re testing one class that has to call another.  This is particularly useful when testing the repository pattern and you want to ensure that it’s calling your data context’s submit changes method.  You will have to mock the data context for this to work, and of course you’ll need to wrap your data context in an interface, but that’s a post for another day.  I’ll post a link when I do it.

   1: MockRepository mocks = new MockRepository();
   2: IDataContextWrapper context = mocks.DynamicMock<IDataContextWrapper>();
   3: mocks.ReplayAll();
   4:  
   5: IWebProxyRepository target = new WebProxyRepository(_Proxies.AsQueryable(), context);
   6: target.Delete("1.1.1.1", 200);
   7:  
   8: context.AssertWasCalled(c => c.DeleteOnSubmit(_Proxies[0]));
   9: context.AssertWasCalled(c => c.SubmitChanges);

It’s pretty straight forward.  If you’re not sure what parameters were used, or don’t care, or if you want to assert that it was called a certain number of times you can use the options that are available ot you when you setup your results like so:

   1: context.AssertWasCalled(c => c.DeleteOnSubmit(_Proxies[0]), o => o.IgnoreParameters().Repeat.Times(2));