Nuget - the new dll hell

Back in the early 2000's, when I first started programming on the Microsoft stack, COM objects were all the rage. This of course had a side effect of something known as dll hell, where an application could change a version of a dll your application depended on, thus breaking your application in the process or causing subtle bugs that where hard to debug. .Net was supposed to change all of that with side-by- assemblies and versioning and for the most part that has worked well. Enter Nuget, nuget was intended to centralize project dependencies and libraries. So for example if you needed to parse JSON files in your application, you could locate a package that contained a JSON parsing library and add it. The reference to the nuget package could be easily shared across teams and build systems. The problem is that many of these libraries come with a proliferation of their own dependencies and in some cases those dependencies are older versions. A case in point, on a an application that I'm currently working on, I have a dependency on JSON.Net, I upgraded to the latest version 8.0.2 only to find out that another package that was referenced had a dependency on 6.0.0 so upgrading broke functionality in the other library (the other library BTW is a Microsoft Library). The eventual work around was a binding redirect in the app config. But this still points to a bigger problem that of library maintenance and vetting libraries that are available on nuget. No one to my knowledge vets these packages and updating certainly isn't enforced. So now we have come full circle in the dll hell story, we are essentially right back were we started in the COM days.

Restore missing Item templates in Visual Studio 2012

I’m working on a large Silverlight to WPF project migration and came across a issue where item templates where not being displayed from the Add new Items dialog. After a bit of searching it became apparent that this was a fairly common problem and there are a number of ways to fix the issue. Of the the various suggestions I found one seemed to work the best, although it was originally for Visual Studio 2010. So here is how you can get those missing templates back.

• Navigate to C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE
• Delete the ItemTemplatesCache folder
• In the ItemsTemplate folder navigate to the templates you want to display and for each template open the vstemplate file in a text editor and set ShowByDefault from false to true
• run devenv /installvstemplates

You may need to run this as an administrator. Once this is done open your project in Visual Studio and right click “Add New Item” your templates should now appear.

The Problem with Windows 8 Apps

I have to admit I was skeptical of Windows 8 when it was announced. Since it was released I’ve migrated my laptop and desktop as well as purchasing a Surface and HTC 8X windows phone. While I’ve been happy with the phone apps I’ve downloaded from the store, the Windows 8 apps are another story.

First let me set the bar, I look for apps where the developer took some time to develop an icon. If I see an app in the store with the default Visual Studio App Store app template you’ve lost me. Even if it is the greatest app since the internet the fact that you could not take a few moments to build even a basic icon tells me you really don’t care about your work. There are literally dozens of these app icons in the store.

I expect the app to be responsive. If the data is stale or not updated or the app just plain says it updated and I can go somewhere and see this in not the case you’ve lost me. A case in point are twitter apps, I can look at twitter on the web and compare what is displayed in the app and I can tell you’ve lied. Both Rowi and Metro Twit done this. Facebook apps have similar issues. If you have an app in the store that uses social networking it better update consistently.

I expect apps to provide the advertised functionality, if your app won’t even provide the advertised functionality you’ve lost me.

I have taken the stand of not paying for a single app until I can be reasonably sure that what I pay for will work. The biggest hurdle that Microsoft needs to overcome is not the number of apps in the store, but the quality. you can have a million garbage apps (ask google) but when you have quality apps that work as advertised and provide value then you only need a few to be profitable and build user loyalty.

Maybe the message to developers should change from “Build apps for the store quick and easy” to “Make quality apps and create revenue”. I’m still skeptical about the future but all it will take is quality in the store.

Some thoughts on the Metro UI in Visual Studio 2012

The Metro UI in the Visual Studio 2012 is horrible  The icons and graphics make navigating a solution nearly impossible. The Light Theme and Dark Theme are equally unreadable. The geniuses that came up with this UI concept should be tarred and feathered. Even with the improvements in search and the solution explorer I still find myself being less productive because I have to study each file to make sure that’s what I want to work with. Lets not even start on the ALL CAPS MENU, really?

I appreciate the IDE improvements but how about a choice? Dear Microsoft, Metro doesn’t work for everything. 

What a difference a release makes

It's been pretty hectic the last couple of months for me. I'm now involved in a one man enterprise project (yes they exist) and between vetting requirements, architecting and coding there really hasn't been a lot of writing time.

One of the things that is at the top my priority list for this project is to provide a high quality and consistent user experience. To that end I had planned to use the DevExpress Silverlight toolset. This looked like a good choice as they're support had been good and the control set looked to be expanding in areas that I would certainly need, such as Charting. But the DevExpress 10.2 release fell flat for me in more areas than it should of. From lack of documentation for new controls (in mean no documentation) to bugs that had not existed in DevExpress 10.1 and where now closed as "Microsoft's problem" (really it worked fine in the last release) to Themes not working with prisim modules, I decided I needed to rethink my choice.

I decided to take another look at Telerik. To be honest, I really didn't want to change, as it's always hard to say "hey maybe I was wrong", but sometimes you just have to rethink your approach. I was pleasantly surprised by the depth of the documentation and ease of use of the toolset. The Telerik controls provided a consistent data binding experience, so no longer did I have to ask "ItemsSource or DataSource or is it something more obscure?" or dig through reams of docs to find examples, it worked flawlessly with prisim and provides great support for commanding. The GridView also supports Hierarchical data, which is something that I will need. Overall I've been very impressed with the toolset and in the future will also make use of the MVC extensions as well.

 

Silverlight and MVVM

I've been very heads down lately on a very large .Net project. The project team should be 5 or larger given the scope, but in the spirit of "do more with less", it's just me. Part of the application contains an internal facing UI, which is being done in Silverlight. In an effort to streamline the work I decided to go with the MVVM approach. While MVVM is the "end all be all" rage these days I am encountering a number of problems. First is in the application flow. I am working from screen designs rendered in photo shop by an offsite designer (he's not interested in xaml or learning). These screens tend to be busy and in my opinion very ADD. This makes it extremely difficult to isolate a clean View Model. What I've discovered is that a number of views may need to access the same data so you end up creating a Master View to coordinate the children. Also the no code model in the views is very difficult to achieve when complex interactions are required. I know that I can use Unity or any number of other MVVM frameworks to alleviate some of the issues, but add to the download overhead, which because of the inclusion of third party components is already larger than it need to be.

So while MVVM may be a panacea to some, I see a number of issues with the approach and until the model is built into the framework core it will continue to be a problem.

 

DXWindow and DXDialog as Silverlight a UserControl

Here is a quick example of making a DXDialog or DXWindow a user control in your Silverlight applications.

Add a reference to DevExpress.xpf.Core to you Silverlight application.

Modify the xaml so that it is a DXWindow (or DXDialog).

<dec:DXDialog x:Class="DevExpressWindow.Dialog"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:dec="clr-namespace:DevExpress.Xpf.Core;assembly=DevExpress.Xpf.Core.v10.1"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">    
    <Grid x:Name="LayoutRoot" Background="White">
        <TextBlock Text="Your UI here." HorizontalAlignment="Center" VerticalAlignment="Center"/>

    </Grid>
</dec:DXDialog>

 

 

And modify the code behind so that instead of deriving from UserControl, derive from DXwindow (or DXDialog) like so.

using System;
using DevExpress.Xpf.Core;

							
namespace DevExpressWindow
{
    public partial class Dialog : DXDialog
    {
        public Dialog()
        {
            InitializeComponent();
        }
    }
}

 

And to use it from within the application

  private void btnNewDialog_Click(object sender, RoutedEventArgs e)
  {
            Dialog dlg = new Dialog { Title = "My Dialog",Height=200 };
            dlg.ShowDialog();
  }

 

The result is a reusable dialog or window.