Thursday, September 23, 2010

StyleCop for ReSharper

Last night the UK ALM user group was fantastic. I really enjoyed it and we had good discussions going. So thanks to Stuart Preston for setting it up and thanks to the speakers, Karel Deman from Avanade for a great talk and Howard van Rooijen.

Which leads me to why I started to write this post. Howard demoed a tool he built called StyleCop for Resharper.

Now if you've never heard of ReSharper - shame on you, then you can search my blog or the web for info on it. If you've never heard of StyleCop then again search the web or read this post that should give you a quick overview of what StyleCop is designed to address: http://blogs.msdn.com/b/sourceanalysis/archive/2008/05/23/announcing-the-release-of-microsoft-source-analysis.aspx

Just quickly; StyleCop is a code style analysis tool. It at compile time will inspect your code against a pre-determined set of rules to determine whether your code complies with your companies coding style implicitly. The problem with it is it only tells you what is wrong with your code when you compile. And in order to get a list of "failures" you have to look at the warning tab in the 'Errors' window in Visual Studio.

When you install StyleCop: http://code.msdn.microsoft.com/sourceanalysis you get the option to install MSBuild targets that you can call during your automated build process. I haven't yet tried this but I will. As what you can do is fail the build if a developer has not complied to your companies codeing style.

Don't confuse StyleCop with FxCop or (Code Analysis) they are very different. Code Analysis inspects your assemblies post compilation for good practices in terms of how you have built your solution, i.e. implementing IDisposable when consumed types support it. Proper use of localization and best practice use of the .NET class libraries.

StyleCop for ReSharper is a ReSharper plugin (yes ReSharper supports plugins even though ReSharper is itself a VS plugin). What it does is it works like ReSharper, so as you type, it will inspect your code and tell you whether you are breaching StyleCop rules for that project. And as per ReSharper style, of hitting Alt+Enter, it gives you corrective options to fix your code for you!

I like it alot. I think it really is a great tool. Combined with the StyleCop build targets I think this can work well in a team environment. As to configuring your projects for StyleCop use, StyleCop creates a file in each project directory that it reads. It doesn't work like Code Analysis, where the settings are baked into the .proj file. So I'm thinking maybe include that file in Source Control so each dev machine doesn't have to configure their machine everytime a new environment is spun up or a new project is added to the solution.

Check it out here: http://stylecop.forresharper.org/

Tuesday, September 21, 2010

UK ALM User group

We Hitachi Consulting are hosting the next UK ALM user group at 2 More London (London Bridge) tomorrow night 22nd September.

Now I'm not sure if it is too late to register at this time, but the event brite registration page can be found here: http://ukalmug-september2010.eventbrite.com/

Thursday, September 02, 2010

No need for server side clientaccesspolicy.xml when using Silverlight for Windows phone 7 Series

If you're a seasoned Silverlight developer you'll be well aware of having to incorporate the clientaccesspolicy.xml file in the root of your service domain with a method that returns the file as a Stream object. MSDN documentation that describes that and the documentation can be found here: http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx

Then you would typically define a method that looks like the following that is accessible via a RESful call (if using WCF) - note: the UriTemplate here is what is important:
[OperationContract, WebGet(UriTemplate = "/clientaccesspolicy.xml")]
Stream GetClientAccessPolicy();
Executing any method from within a desktop Silverlight app whether in-browser or out-of-browser (SL 3 feature) will call that method above implicitly by the SL HTTP stack.

When calling any web method from a Windows phone Silverlight application, the 'GetClientAccessPolicy' is not called so there is (currently no need for it if your clients are from WP7 apps).

I'm not sure if this will change when the WP7 tools RTM on the 16th September - I will be the first to try!

My colleague Anthony Cooper found this out, so thanks to him.

Windows Phone 7 Series released to RTM

Just in case you haven't heard the news yet, yesterday Windows Phone 7 Series was released to RTM: http://windowsteamblog.com/windows_phone/b/windowsphone/archive/2010/09/01/windows-phone-7-released-to-manufacturing.aspx

Excellent work to the Windows Phone team!

So now we wait for OEMs to produce some hardware...not long I'm sure.

The tools RTM on 16th September: http://windowsteamblog.com/windows_phone/b/wpdev/archive/2010/08/23/a-developer-s-roadmap-to-windows-phone-7-launch-timing.aspx