Marius Gheorghe

Building software : make it work, make it good, make it fast

It's just a binding failure

A GitHub extension VS bug caused some serious damage for some dude. It was very sad to see the actual cause of the bug though. A frigging WPF checkbox binding failure case GitHub projects to always be created public.
It's funny because a lot of people who do XAML figured out that MVVM/binding is the wrong way to tackle UIs of a reasonable complexity but on the other hand it's still sad to see it fail so miserably.

Immutable collections in .NET

Dealing with immutable collections in .NET  is very easy with the help of the ImmutableCollections package on nuget .

Here's a example :

ImmutableList initial = ImmutableList.Empty;
ImmutableList immutableList = initial.Add("stuff");


Any operation on the collection will create a duplicate collection (so in the above example the "initial" collection is still empty).
Another much simple way would to be use the IReadCollection from .NET 4.5
List initial = Enumerable.Range(1, 10).ToList();
ReadOnlyCollection readOnlyCollection = initial.AsReadOnly();

Now you can pass readOnlyCollection and obviously the initial collection will remain unchanged.

NET Core : 1 step forward, 2 steps back

There's are some interesting developemnts in the .NET land lately. Microsoft announced .NET Core , a Micrososft supported cross platform initiative to run .NET on Linux and OSX. The immediate result is that ASP.NET vNext will run on Linux (although not integrated with Apache or any other webserver, with OWIN we'll be albe to run in our own custom process). Obviosly this is good news but it's one of those 1 step forward, 2 steps back situations.

Good things :
- deploy ASP.NET on Linux (it's not like somebody cares about OSX server).
- with a official, high performance supported runtime (which Mono isn't), this might "open the gates" in the future for a QT port and we could write cross platform desktop apps.

Bad things :
- .NET Core is actually a (small) subset of the full .NET Framework. Most likely the full functionality will be somehow similar with Silverlight runtime. Anyone who did SL development and wanted to "port" code from full .NET to SLL knows how painful is that because of the missing things.
- EntityFramework 7 (which will launch along with ASP.NET vNext) will not be feature complete.
- right know is not exactly clear what exactly will be shipped as .NET Core so people can't start porting their commercial libraries to .NET Core.
- no AppDomains. Overall that is pretty bad but since you'll be running a single app per process, is not that bad.

Make no mistake though, having .NET runtime on Linux/OSC supported by Microsoft is pretty huge.

On EntityFramework Code First approach

I'm not a big fan of code first approach. The "code" part is fine (and it was great was the EntityFramework designer still used ObjectContext and generated all the code in a single file), but i think migrations are not such a great idea. Writing C# code that is equivalent of SQL DDL feels wrong. It means ignoring great tools such as RedGate SQLCompare (which handles very nicely schema changes) and just writing a bunch of code.

So i basically i use :
- "code first" for mapping
- use Database.SetInitializer(null) for initialization.
- mostly use SQLCompare to handle schema changes.

Activation of app failed with error: The app didn't start. See the Microsoft-Windows-TWinUI/Operational log for additional information.

  Stumbled upon a really dumb thing today. I was working on a Metro app and i opended the Visual Studio solution from a usb stick. When i tried to run it, i got the above message. Copying the files to hdd and opening the solution from there did the trick. I've run the app with no problems. I've also try to run the app from a TrueCrypt drive and got the same thing (didn't have a usb HDD around so i couldn't test that).
So if you get the above message when running a Metro app from Visual Studio, make sure you're opening the solution from a hdd.

Tracing code execution at runtime

Basically there are 2 ways to do this :


- using the new CallerInfo attributes in .NET 4.5 . This is mostly useful for debugging bindings in WPF/WinRT.
- dumping the call stack at runtime (unfortunately without parameter values) using the StackFrame.

I've just added support for this to Microruntime.

Beware of deploying VCLibs in a package build on Debug

The other day i found a deployment problem with a WinRT apps that left me (almost) speechless. Basically deploying VCLibs (dependency required by Bing Maps) in a app package build on Debug makes the app crash on startup with a XamlParserException. On Release it works fine (of course i was doing a QA build and did in debug to get proper stacktraces).
So, there you go. Always build on Release (even for QA builds) if you plan to deploy that package on a machine without Visual Studio installed.

Saving a synchronization context switch with await

If you're not interested in using the result of a async method on a UI thread (which happends implcitely when awaiting a method from the UI thread), you can save a synchronization context switch by using :

await DoMyStuffAsync().ConfigureAwait(false);

Passing false to ConfigureAwait will prevent the switch to UI thread.

Async wrongly named

I was thinking that await keyword has to be one of most "wrongly" named keyword (volatile being the other contender) from the language. I noticed that most people when learn about async + await have the impression that the current thread "stops" when encounters the await keyword (obviously not the case).

Maybe "concurrent" or even "parallel" would have been better.

Resharper 7 XAML member navigation

 

Resharper 7 member navigation (Cltr + F12 for old school R# users) breaks in XAML if you have a resource dictionary which doesn't inherit directly from ResourceDictionary. The inheritance chain is something like MyDictionary  : DictionaryBase : ResourceDictionary.

 

Async brainteaser

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApplication1 {
class Program
{
    static void Main(string[] args)
   {
      (new A()).Run();
      Console.WriteLine("end main");
      Console.ReadLine();
   }

}

public class A
{
    public async void Run()
    {
      await Task.Run(() =>
     {
       X();
       Console.WriteLine("end x ");
     });

        Console.WriteLine("end run"); }

     public void X()
     {
       for (int i = 0; i < 500; i++)
       {
         long f = 12345 * 12;
       }
     }
  
  }

}

 


Run this code (requires async ctp or vs 11 ) and try to guess the order of items written at console. Also run it multiple times and study the results...

My Visual Studio

Here are my Visual Studio 2010 settings & customizations. I'm using a black theme made by me (i call it MoonSorrow) . Here is how it looks in action :

If you want to try it here are the files :


- This is the VS Color Theme Editor156. Make sure you have the VS Color Theme editor installed to use it.

- my complete Vs settings file157 (be very careful with this and make a backup of your settings before importing this one).

- and finally my Resharper settings file 158 which includes the custom code formatter. Obviously back up your R# settings before trying out this one.

 

That' all. Happy Visual Studio customization :)

Few general tips for Windows Phone development

- don't use ZUNE for deployment. Use WPConnect (a tool which comes with the SDK. You'll find it in \Windows Phone\v7.1\tools\wpconnect). It's much lighter than Zune and it also allows you to debug launchers/choosers.

- don't close the emulator. Never.

- learn the difference between pivot/panorama and use them accordingly (if it helps think of the pivot as a tab control).

- it's a good idea to not hardcode colors and use the accent color (for instance where you want to "highlight" a specific text).

- make sure you test your app in both themes.

- think of the navigation flow of the app. Remove pages from the navigation stack when it doesn't make sense for the user to "get back" with the back key.

- fast, Fast, FAST. I can't stress so important is to have a app which feels fast.

- the JPG decoder is faster than PNG. Consider this when choosing the format of images for splash screen, backgrounds etc.

- make sure you understand the difference between "content" and "resource" when dealing with app resources.

RewritePath issue on ASP.NET 4

  Ported a app from ASP.NET 2 and 4 and had a interesting issue with HttpContext.RewritePath.  Basically I was doing url rewriting using to ashx handler to get nice urls on asp.net 2. When I moved the app to 4 all postbacks on pages with rewritten url were broken (even if I was running the app with the backward compatible settings).

Found a workaround (not perfect but it gets he job done). Basically RewritePath has a parameter called “rebaseClientPath” which “updates” the path after url change. This rebase doesn’t seem to work anymore on ASP.NET 4 so make sure it set the param value to false.

Hope this helps someone.