Adrian Hara

Just a quick tip: in case you are trying to register your windows phone 7 as a developer phone (so that you can deploy your app on it and debug directly on the device from Visual Studio 2010) and get the "Error communicating with the developer portal 0x64" error you might want to check that the regional settings for the Windows Live ID you're using are the same as the regional settings of your development machine where you're running the registration tool.

In my case the Windows Live ID was set to US, but the local machine's regional settings (location) were set to Switzerland. Setting them to US made the registration tool work. The actual hint to find the problem came from Zune, which displayed a much more explicit error message when logging in.

Now I'm only sad because I wasted two days because of this somewhat ambigous error message, I had thought that I couldn't register the phone because the Windows Marketplace verification process was not yet complete, but in fact the problem was in the regional settings.

It's been so long since I posted on the blog that doing it now makes me a bit feel a bit weird. In my defense, i've been quite busy these past months: I left my previous company, got married, moved to a new country, started work for a cool company here... in this order :)

More recently I've been working on a small app for Windows Phone 7 and one of the app's needs is some (fancy) charts...you know, the bar/pie/gauge kind. While there are some nice control libraries out there for bar and pie charts, they don't (to my knowledge) include also a gauge control.

So what's a wp7 developer to do? My first thought was to use the circular gauge control from codeplex as a starting point, with which I've played before, but I remembered it having some small annoyances. However, some further googling lead me to a fantastic article by Colin Eberhardt in which he builds a lookless circular gauge control. Now since I'm a big fan of MVVM the "lookless" part immediately jumped out so I dug into it. As said before, the article and code are brilliant, both easy to read and understand (as all of Colin's work actually).

Unfortunately, while the control works flawlessly on Silverlight 4, it doesn't out-of-the-box work on WP7's frankensteinian SL3/4 flavor. This is mainly because the WP7 version of Silverlight is missing the ability to use Bindings on DependencyObjects (which Colin's xaml heavily uses for example for Transforms), falling back to the Silverlight3-uesque (?) way of supporting only FrameworkElements.

The good news is that fixing this is a pretty straightforward, if a bit tedious, job. Attached at the end of the article you can find a solution which contains two projects, the original code as-is from Colin's blog and a WP7 project with the modified code that runs (at least in my) WP7 Emulator.

I won't go into great details here on the changes, feel free to explore the code or ask me directly (shameless twitter plug), but the highlights are:

• the workaround I used for the missing binding functionality is based on behaviors, and more concretely, BindableBehaviors. These are, as surely the name says, the regular behaviors enhanced with data binding capabilities (otherwise they're still subject to the "can only bind on FrameworkElement" rule). The code for them is not mine, but was extracted pretty much as-is from the excellent nRoute framework (which also supports WP7 btw). The only reason I didn't add a reference to the nRoute framework (or its lighter cousin, the nRoute toolkit) was to not increase the download size, but by all means I encourage you to use it in your project by reference, since the code in it, including the BindableBehaviors, might be updated over time (which my code probably won't).
• the way BindableBehaviors work is by "shadowing" each property you want to bind with a "PropertyNameBinding" property of type Binding, which is then behind-the-scenes added to an attached property dictionary on the behavior's target. If that seems like a mouthful I strongly encourage you to read the complete article on bindable dependency objects on Rishi's blog.
• with the above in mind what I did was just replace the non-working bindings with behaviors that update the otherwise bound values themselves. There are some behaviors which work on the Transforms and another that builds the coloured ranges. Keep in mind that these were done pretty much in a quick and dirty fashion, so feel free to change/extend them to suit your needs.
• as a minor tweak I also added a small animation to move the needle when the gauge value changes and updated the colors of the gauge ticks and labels to use some predefined WP7 resources, so they work on both light and dark backgrounds. The gauge's color is always gray-ish, but that could be updated as well to take into account the current theme and render in a more matching tone. Otherwise the gauge's design is unchanged from the original one.

I hope you find this useful and if you find any nasty bugs, please let me know.

Also, big thanks to Colin Eberhardt for such an outstanding article and to Rishi Oberoi for the awesome nRoute framework.

Link to source code download

Although the team's intentions might have been good, the new help system in Visual Studio 2010  is a huge step backwards (more like a cannonball-shot-kind-of-leap really) from the one we all know (and love?) in Visual Studio 2008 and 2005 (and heck, even VS6).

Its biggest problem, from my point of view, is the total and complete lack of the Help Index feature: you know...the thing where you just go and type in what you're looking for and it filters down the list of results automatically. For me this was the number one productivity feature in the "old" help system, allowing me to find stuff very quickly.

Number two is that it's entirely web based and runs, by default, in the browser. So imagine, when you press F1, a new tab opens in your default browser pointing to the help entry. While this is wrong in many ways, it's also extremely annoying, cleaning up tabs in the browser becomes a chore which represents a serious productivity hit.

These and many other problems were discussed extensively (and rather vocally) on connect but it seems MS seemed to ignore it and opt to release the new help system anyway, with the promise that more features will be added in a later release. Again, it kind of amazes me that they chose to ship a product with LESS features that the previous one and, what's worse, missing KEY features, just so it's "standards based" and "extensible". To be honest, I couldn't care less about the help system's implementation, I just want it to be usable and I would've thought that by now the software community and especially MS would've learned this lesson.

In the end, what kind of saddens me is that MS regards these basic features as ones for the "power help user". I mean, come on! a) it's not like my aunt's using Visual Studio 2010 and she represents the regular user, b) all software developers are, by definition, power users and c) it's a freakin help, not rocket science!

As you can tell, I'm pretty pissed. Even more so because I really feel that the VS2010 & co. release really is a great one, with a lot of effort going into the various platforms and frameworks, most (if not all) of them being really REALLY good products. And then they go and screw up the help! How lame is that?!

 

Anyway, it's not all gloom-and-doom. Luckily there is a desktop app which presents a UI over the new help system that's very close to what was there in VS2008, by Robert Chandler (to which I hereby declare eternal gratitude). It still has some minor issues but I'll take it over the browser version of the help any day. It's free, pretty quick (on my machine ;)) and nicely usable. So, if you hate the new help system (passionately) like I do, download H3Viewer now.

 ps: by now you probably realize that the word "cake" in the post title was, in all likelihood, not the best choice ;)

I'm actually somewhat amazed that there are only 16 downloads (or so CodePlex says) for the 1.0 release of AutoFixture. I had heard about it a while ago, but due to lack of time didn't actually get a chance to try it out until today. Please, PLEASE don't make the same mistake in delaying getting and using it for as long as I did, because frankly, it rocks.

I won't go into details on what AutoFixure is, except say that it will help you write better, cleaner unit-tests and also because I wouldn't do nearly a good job at explaining it as the following amazing (series of) posts:

• Zero-Friction TDD
• Test Data Builders
• AutoFixture exposed (read from oldest, on bottom, to top); though it might seem like a lot, it's well worth it

One experience I can share though is that, after a couple of hours of using and loving it I found that as the complexity of the code and tests go up, moving from just using the Fixture class directly to inheriting from it and customizing a specific fixture class for the particular SUT brought a HUGE improvement, both in dropping the number in lines of code by almost half and making the tests crystal clear. This is also summarized in one of the posts referenced above, though only briefly: "The more complex and demanding your SUT's API is, the greater the gain from using AutoFixture will be, since it's going to figure out much of the routine stuff for you." While this is certainly true, I'd add that customizing the Fixture for your particular case with an appropriate API can really make your tests easy on the eyes of future readers (which, of course, might be you :))

 

 

Profiling some memory problems in the latest project i worked on we found out something rather disturbing:
IF
   a WPF UserControl/Window uses a DispatcherTimer (declared as a private member in the UserControl's code-behind)
   AND
   the event handler for the timer's Tick event is also declared in the UserControl's code-behind
   AND
   that UserControl/Window is shown/opened by a parent
WHEN the UserControl/Window is dismissed WITHOUT stopping the Timer or unsubscribing from its Tick event
THEN you have a memory leak.

Basically what we were doing was opening/showing some Windows/UserControls which would then get dismissed at some point. Unfortunately they never got collected. We traced it down to the DispatcherTimer and actually the Dispatcher for the thread itself. What happens is when you Start() the DispatcherTimer it adds itself to a list of timers that the current Dispatcher is keeping. If you never stop it then it never gets removed from that list, and since the Dispatcher is rooted, whoever handles the timer's Tick is also rooted, so it never gets collected.

So the lesson is to always Stop() the DispatcherTimer or unsubscribe from its Tick event. Either way will get rid of the rooted path to your control and will allow the garbage collector to reclaim it. Another option is to use weak events. This might seem like overkill, but the fact is that, depending on your design, you might not KNOW when it's a good time to either Stop() the timer or unsubscribe from its Tick event. You can read about weak events (which are implemented already in WPF) in the following links:

Basic idea:

http://blogs.msdn.com/greg_schechter/archive/2004/05/27/143605.aspx

WPF implementation idea:

http://reedcopsey.com/?p=55

How to use them:

http://shevaspace.spaces.live.com/blog/cns!FD9A0F1F8DD06954!471.entry?wa=wsignin1.0&sa=479373232

A nice trick to simplify your amount of work:

http://blogs.msdn.com/nathannesbit/archive/2009/05/28/weakeventmanager-and-iweakeventlistener.aspx

Even though I heart about transactional file system support since Vista, I never really tried it. So needing to do it today I looked up ways to use it from the managed world. Turns out it's not so straightforward...

In the Vista RC, to use the transactional fs support what you'd have to do is just call some win32 api methods that would signal the file system functions that there's a transaction going on. So basically you would whip up a TransactionScope, call the win32 api to set the "transaction-aware" flag, work with some file functions, call the win32 api again to reset the flag, and commit the scope. Here's how: http://www.pluralsight.com/community/blogs/jimjohn/archive/2005/09/13/14803.aspx

Well, in later releases it was decided (probably for good reasons) that this wasn't the way to go, so what happened was that most (if not all) the win32 file apis got some "-Transacted" counterparts, like CreateFileTransacted, DeleteFileTransacted etc. Also, to be able to use all these from managed code, you'd have to interop with the Kernel Transaction Manager. You can find a pretty good write-up of all this here: http://msdn.microsoft.com/en-us/magazine/cc163388.aspx . Jim Johnson also blogs about this here: http://www.pluralsight.com/community/blogs/jimjohn/archive/2006/08/31/36819.aspx

I was just about to go and write the nitty-gritty myself, when I stumbled across this gem: http://alphafs.codeplex.com/ . AlphaFS provides all the transactional file system support for .net you'll ever need, and more! Even though AlphaFS is still beta (no pun intended), it worked out-of-the-box quite well. Granted, I only did some simple stuff, like traversing some directory structure and manipulating stuff along the way (creates, deletes, attributes etc), but it's all good. While there are some minor issues, like no built-in methods for recursively doing stuff (DeleteDirectoryRecursive anyone?) or some performance hit (which is to be expected from a transactional fs), the library is really great and I'd like to extend my congratulations to the folks that wrote it. So... enjoy :)

In case you missed it, a really good whitepaper by Rick Strahl and Michele Leroux Bustamante was published a few days ago on dealing with localization in WPF. At 66 pages long, I found the whitepaper really good, as it takes a hands-on, no-bull approach (in the familiar style of the authors ;) ) on the subject. There is also sample code for download containing examples and some goodies.

For those interested, here's a quick summary of the paper (which is NOT supposed to replace reading it):

• you can use LocBAML for localization, which is an unsupported tool from Microsoft. Basically it sucks, but if you have a finished WPF application which you wrote without localization in mind, this tool might help you somewhat.
  
• you can use the plain ol' ResX resources, together with the {x:Static} markup extension to access them. This works loads better than the LocBAML approach, but has the major disadvantage that you're limited to localizing only simple string properties, because the {x:Static} markup extension doesn't use type converters (so, for example, localizing a Thickness might be tricky if not impossible).
  
• you can use the plain ol' ResX resources, but this time together with a custom markup extension which knows how to use type converters. The authors of the whitepaper kindly supply for download such an extension, which does quite a lot of other nice stuff besides the type converter business. I'd say this is the way to go :)
• you can use a mechanism similar to the one used in Winforms and Asp.net applications where you could have a label, say "lblTitle" and then resource keys with sub-properties, like "lblTitle.Text", "lblTitle.Width" and so on. To do this in WPF the authors again supply some attached properties which do some magic to get this working. While this looks pretty cool, unfortunately they also don't support type converters, so you're stuck to localizing "simple" stuff.

Again, if you're interested in the subject, please read the whitepaper as it provides a lot more subject matter than the actual possibilities of localization and I'd go as far as to say it's a mandatory read for anyone who has to localize WPF applications.

Codeplex link:

http://wpflocalization.codeplex.com/

If you ever need to deploy a WCF service to SharePoint 2007, there's plenty of information about how to do it on the web. Including how to make it work with Integrated Authentication or Forms Authentication. And it's all great and works.

However, I had to make the service "run" under the context of a particular web (which was actually a subweb). By this I mean that if I have a root site and a subsite and my WCF service calls SPContext.Current.Web I'd want it to return the subsite, not the root site.

Well, I deployed the service in a subfolder of the "_layouts" folder and it worked fine. Except that SPContext.Current.Web always returned the root site, not the subsite. Surprisingly (or maybe due to my lack of google search skills  ), there was little to no information available on the net on how to do this. All I found was something along the lines of "if deployed in layouts or vti_bin folder, a service runs under the context of the specific web". Pretty generic for me. So after some headbanging and some more searching, I finally found out the problem. And it's so obvious and simple that I'm really surprised there's very little information around about this, so I thought I'd note it here... for posterity like

In the service client, instead of having the service reference like so:

http://domain/_layouts/somefolder/MyService.svc

have it like so

http://domain/SUBSITENAME/_layouts/somefolder/MyService.svc

That's all there is to it, just include the subsite (or subweb) name in the url, as the services in the _layouts folder are available from every subweb, and then the SPContext.Current.Web will return the correct web.

Thanks to Serge van den Oever, on whose blog I found out about this!

This has probably been covered in some tutorial videos or "silverlight 3 what's new"s, but due to the fact that I spent the better half of an hour googling about ways to do it, I guess also posting it here for reference won't hurt.

Problem: when calling a WCF service from Silverlight 2, if the service throws an exception, in Silverlight you get a CommunicationException with some mumbo-jumbo in it, not the actual exception or Fault declared on the service.

Fix: in Silverlight 3 there is built-in support on the client-side for FaultException and FaultException<T>. All you need to do it tweak the WCF service a bit so it returns a 200 response code, instead of the default 500 response code, so you actually get the FaultException, as explained here: http://msdn.microsoft.com/en-us/library/dd470096(VS.96).aspx

Also, some more info on this and other new stuff in SL3: http://blogs.msdn.com/silverlightws/archive/2009/03/20/what-s-new-with-web-services-in-silverlight-3-beta.aspx

If you have a Silverlight 3 Beta 1 DataGrid that, for some reason, is not refreshing when its bound ItemsSource changes, like so...

 <data:DataGrid ItemsSource="{Binding Path=Parameters}" AutoGenerateColumns="false" IsReadOnly="True" >
                     
...you might want to know that it's a bug in the beta. I actually spent about 2 days on and off on this issue, researching a workaround and googling for it with no results. Only today, more on a guess than anything else, I did this:

 <data:DataGrid ItemsSource="{Binding Path=Parameters, Mode=TwoWay}" AutoGenerateColumns="false" IsReadOnly="True" >

It's obviously stupid to have a readonly grid with TwoWay binding but, to my surprise, it started working ;)

Armed with this knowledge, I refined my google searches and voila, the following thread magically appeared. The link to the repro in the thread isn't working, but I assume it's about the problem at hand. So, anyway, just use TwoWay binding in the meantime ;)

update: I also noticed the same behavior for binding paths that go "deeper" in the bound object (e.g. "SelectedParameter.Value"), even if they are NOT used for the DataGrid (i.e. I have a case that's not working for a Button). Luckily, the same workaround works there too. The downside is that you have to be careful to not really use the TwoWay binding, thus inadvertently updating your ViewModel.

 

Small gotcha today after installing the Silverlight 3 beta "suite" - runtime, visual studio 2008 tools and blend 3 preview.
(side note: if you install the Silverlight 3 runtime BEFORE the visual studio 2008 tools, then the tools installation fails because it tries to reinstall the runtime... so either uninstall the runtime or don't install it at all standalone, the tools installation will take care of it)

Opening an existing Silverlight 2 project triggered the conversion to SL3, which worked fine. Suprisingly though, the service reference that the project had to a WCF service didn't work anymore. Looking at the generated reference file I found it to be empty (with just some comment at the top). Doing an "updated service reference" from VS2008 didn't do anything much so I was stuck.

Fortunately, an entry on Jimmy Lewis' blog about a similar situation led me on the right way to the fix: uninstall the Silverlight 2 SDK. After I did this and went back to "update service reference" the code was generated correctly and worked fine.

Hope this helps someone.

Today I experienced what appears to be a small WSSF gotcha :)

If you have a Data Contract which has a Data Member called Value (for example contract is ParameterInfo, so having a member called Value might make sense), the code that gets generated by WSSF looks like so:

private string value;

[WcfSerialization::DataMember(Name = "Value", IsRequired = true, Order = 1)]

public string Value

{

  get { return value; }

  set { value = value; }

}    

Obviously, what happens is that in the property setter...well...nothing happens ;). The code generator doesn't prefix the assignment with "this", so we'd have "this.value = value", meaning that the data member will always have the default value for its type (in this case, because it's string, that'd be null).

Now I admit that having a property named "Value" is questionable, but I might argue that, using WSSF, the whole point is to model the contracts in an implementation-oblivious manner, so it should be perfectly fine to have such a data member name.

Anyway, you probably can poke into the code generation and fix this, and probably I would've tried it, but it turns out that my "Extending the WSSF Hands-On-Labs.chm" is not working ("page cannot be displayed"). So if anyone has a fix for this (other than renaming the data member), please shout ;)

It's been there for a while, but I just found out about it yesterday. There's a free ebook from InfoQ called "Domain Driven Design Quickly", which I think is a great introduction to DDD. It talks about the main concepts of DDD and presents them in a very focused yet easy and enjoyable-to-read way, with little or no actual code in one particular technology.

The book is a light read and, at 106 pages, it's packed with great info and insight about modelling, communication within teams, organizing your business logic etc. Even if you won't do DDD, I think the book is still well worth reading.

http://www.infoq.com/minibooks/domain-driven-design-quickly

Last year I had the pleasure of receiving a copy of the book Entity Framework Tutorial by Joydip Kanjilal from Packt Publishing and I recently got the time to read it so I thought I'd share my impressions on it.

I have to confess to having great expectations from the book: it was from Packt, the publishers of the excellent Programming Windows Workflow Foundation by K Scott Allen and it was on Entity Framework, a topic which I had been meaning to read up on for a while.

Like the WF book, EF Tutorial takes a very hands-on approach to the problem. In fact, since the book itself is quite small (some 200 pages), there's clearly no space to waste with marketing talk. Also like the WF book, EF Tutorial comes loaded with a lot of screenshots and code examples and is nicely structured so it progressively  but steadily goes from light topics to some more advanced ones. Unfortunately, the similarities with Programming WWF stop here.

In all honesty, I was quite dissapointed with the book. While the WWF book (no hidden advertising here, honest! :)) was also short, it was incredibly focused and, to me, made it seem like every word counted: there were no rants, no superfluous information, just facts, hints, tips, code (and some insights a la K. Scott Allen ;)). Straight up quality! In EF Tutorial, on the other hand, a lot of the time I got the feeling that either a) stuff was written just to fill the chapter or b) the author had no knowledge of the "inner workings" of something so instead he just wrote some generic stuff, without really explaining the "how"s and "why"s and moved on.

Examples:

• the edmx schema is glossed over very briefly - there are no explanations as to what each element means or why it was designed this way. Instead, we get the whole triplet thing (CSDL, SSDL, MSL) several times over, presented as a big thing. I'm sure it really is, but I'd like to know why ;)
• there's lots and lots and *lots* of xml mapping code - I'm not quite sure if anyone wanting to try to practice what's presented in the book will write all that code by hand in visual studio... reading it from the book. Also, as far as I'm concerned, presenting xml mapping code over several pages doesn't exactly help improve its readability. I would've certainly liked some highlights and some words instead of the same complete mapping code over and over.
  
• there's lots of screenshots - that could actually be a good thing, and in several places it is. But having screenshots of how to install the Entity Framework or .NET Framework 3.5 SP1 (yea, I mean screenshots of the actual install wizard!) is a bit overdoing it. Still, although annoying and pointless at times, there are quite a few helpful ones, like the EF designer and mapping details.
• there was more than one place in the book where the topics presented ended quite abruptly, without any real explanation - chapter 7, attaching entities or implementing complex types in the edm (where I found out that "a complex type is actually a structures property" and that's it) come off the top of my head.

Another negative point of the book is that, at least to me, it seems it never got a serious review (or reviews) before getting published: there are a lot of English language mistakes, which I can live with, but also a lot of code (or xml) mistakes. The latter part is especially bad as the book's target is someone who's completely new to EF and he or she might be put off or sent on the wrong track by these mistakes. It's too bad, because more often than not, they are not reasoning mistakes but probably just copy/pasting or late night working and, in my opinion, could have easily been corrected. Also, there are some rather dubious claims here and there, like mapping of stored procedures which return a scalar value (and thus don't have an entity set), for which the author's solution is (warning! wtf moment coming up!) to create a dummy table in the db and an entity type for it ;)

So, after all this, you might be wondering if the book's ANY good: it is. It's just that you have to know how to take it: for me it was reading through it and whenever I felt that a topic was not explained enough or contained dubious information I read about it on the net. So the book was more like an overview, a pointer towards the right directions to read and help to structure learning EF. And maybe this was its purpose. BUT, if you plan on reading this on a plane trip of a few hours, with no connection to the internet to look stuff up (and are the type of person who doesn't take things for granted but wants to knows the reasoning behind and inner workings of them), maybe you should look elsewhere.

I just installed .net 3.5 sp1, vs 2008 sp1 and thus got access to the latest version of the entity framework. Since I hadn't played with it before, I decided to try. My scenario was more than simple, bordering on lame: save some data in one table in a sql compact database.

So I quickly generated the .edmx using the wizard (which is pretty cool btw) and just ran the app. Unfortunately, when the ObjectContext derived class would be instantiated, i got the following FileNotFoundException:

"Could not load file or assembly 'System.Drawing, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' "

This was pretty strange, since I was targeting the 3.5 version of the framework and I didn't see any explicit need for the 1.0 version of System.Drawing.

After some digging, I came across this MSDN forums thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3926655&SiteID=1 . Craig Lee's post is particularly enlightening: "There is a note in the above MSDN page that outlines the effect of keeping the default "res://*" value that the designer writes out.  In your case, you should change this so that it uses explicit paths.  I suspect that because you have "res://*", the EF runtime is scanning your DLL and all referenced DLLs for any EF runtime artifacts".

As it turns out, I was actually using a 3rd party component which had a reference to System.Drawing 1.0 and, because of my default generated connectionstring by the entity model wizard (which should just work, right? :)) it looks like the EF was crawling all referenced assemblies to look for its definition files, ending up by not finding the 1.0 version of System.Drawing because...well... I haven't the 1.0 version of the framework installed :)

Fix was easy: change the connectionstring to use the assembly name, instead of the wildcard search, like so "res://SomeAssembly/<whatever else was generated>".

Hope this helps.