Bulb Flash:- Azure Development Quick Tip!!

Recently we were stumped with the following error while working on an Azure project

Error 1 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets 202 5 OrderManagement

After a lot of head-banging, a simple Quick-Fix was to move the project to a root directory like a C: or a D: (Basically reduce the path of the project)

Hope you get to this quick-fix before you get to the head-bangingSmile


Bulb Flash:-SQL Azure tip; Firewall rules: allow all incoming IPs during testing and Development!

Before we even show you how , do note that this should be done only during testing of non-critical data which will cause no issues if accessed from unintended applications..

SQL Azure tracks the IP address for the purpose of security . However sometimes during development( and co-development) when you don’t have a static IP, it becomes quite a pain to keep checking the Firewall rules every time the app starts misbehaving…so during testing and development you can see the firewall rules to allow all connections by giving it the following settings..



Hope this saves you some time and headache…do remember to change these during production and when testing with critical data!

Until next time!


Bulb Flash:- Some practical WPF MVVMLight tips!

One of our major projects recently used WPF 4.0 with MVVM pattern.We used the MVVM Light Toolkit for implementing the MVVM Pattern.

The MVVM Light Toolkit definitely has a lot to offer to make your life easier but the documentation is not exemplary!

Few things we learnt down the road as we came to a close on the project are

1. You are better off using the ViewModalLocator. We didn’t use it initially and realized that our ViewModels are not getting Disposed, multiple view models are getting created especially when using the “Commanding” feature!

2. When using Commands , if you are not using the ViewModalLocator, try not to set the IsDataSource property as it will change the DataContext of your screen to the new ViewModel and there will be inconsistency during commanding as previously set variables will not be available in the new VM. Or if you do need to set the IsDataSource property send all data needed by the command handler as arguments( because previously set data will not be available to the new VM)

3. You need a default empty constructor in all your ViewModels or your XAML screens commands won’t work(They instantiate the empty construtor)

4. You can pass event args parameters in commands using PassEventArgsToCommand="True" in your EventToCommand XAML

5. When using messaging use the method overload Send<TMessage>(TMessage message, object token).Using the token to register and send messages ensures it is delivered only to valid subscribers!

6. Every time you register for an event using the Messenger.Default.Register….ensure you Unregister also using the Messenger.Default.Unregister or else you might have memory leaks!!

Will try to write more elaborate posts detailing out these and more issues .Meanwhile drop a note at anshulee@cennest.com if you have any queries/ need more tips related to MVVM…

Until then!


EF 4.0 Bulb Flash!:- Load only what you need!!

A small tip for those working with Entity Framework 4.0:- We all know the concept of Lazy Loading in the Entity Framework: With lazy loading enabled, related objects are loaded when they are accessed through a navigation property.

With lazy loading a drawback is that an object retrieved from the database comes loaded with all its navigable Objects so you may be querying an “Order” class but it comes loaded with the Order.Customer object .

[Thanks to Julielerman for pointing out this inconsistency.  Lazy Loading loads related entities on Navigation and does not come “loaded” with them]

While you may want this in some cases, it makes sense to disable this feature in performance oriented applications and load only what you need!

As against what is written in MSDN , our experience is that when an entity context object gets created, its LazyLoadingEnabled property is defaulted to true!… This is also a reported issue with microsoft

So first step would be to disable the LazyLoadingEnabled!

ProgramEntities entityContext = new ProgramEntities();
entityContext.ContextOptions.LazyLoadingEnabled = false;

List<Order> orderList= entityContext.Orders.ToList();

Next, load what you need!

orderList.ForEach(p => entityContext.LoadProperty(p, "Customer"));

Now you can access the Customer as Order.Customer while ensuring you did not load other related  navigable properties like Order.Contents etc etc.

Hope this helps “lighten” up your code a bit!!

Cennest !!

Bulb Flash:-Returning Complex objects from Stored Procedures in Entity Framework!

Sometimes when using the Entity Framework we decide to encapsulate a complicated piece of SQL into a stored procedure and call it directly from your code.

But how to you extract the result of the Stored Proc if it returns a combination of columns from different tables?

Consider the following Stored Proc which returns a list clients recently worked on.

Notice that columns returned span 2 tables (Joined) so you can’t just make the SP return a List of Clients..

select top(@number)c.Client_Name as ClientName,c.ClientID asClientID,Max(p.EndTimeStamp) asLastTimeWorked
fromClients c joinTimeLog p
c.ClientID =p.ClientCode
Group Byc.Client_Name,c.ClientID
Order byMAX(p.EndTimeStamp)desc

So now you add the Stored Procedure in your Entity Diagram, but what will be its return type?

  • If you double click the StoredProc in the Model.Store to get the following screen


  • If your SP returns a combination of columns click on the “Get Column Information” button to get the column names returned by the SP


  • Click on “Create new Complex Type” to create a new class for this group of columns


Now you can use the RecentClients_Results(Rename if you like) as a normal entity class in your code!

Hope this helps!

Until next time!


Commanding within DataTemplates in MVVM!

A quick post about setting commands within DataTemplates when using the MVVM pattern!

When you are inside a DataTemplate the DataContext is changed to the  the current item, so to access the command you will need to use the “relative source”

Something like

 <Button Content="Delete" Width="Auto" 
Command="{Binding DataContext.RemoveCommand, 
RelativeSource={RelativeSource FindAncestor,
 AncestorType={x:Type ItemsControl}}}" 

Hope this real quick note helps save you some time!!

Until next time!


Improving WPF/Silverlight- WCF Communication!

While working on a recent assignment related to establishing and optimizing duplex communication with Silverlight and WCF,we learnt quite a lot of new concepts like HttpPollingDuplex binding  with multiple messages mode Http Long Polling designs etc.

While most of these concepts were new we did get a bulb flash on how to improve basic WPF/Silverlight WCF communication!!

All WPF/ Silverlight applications share the same threading model . They have a UI thread and a rendering thread. The rendering thread takes care of the background processing while the UI thread takes care of painting the screen, resizing and the overall look and feel. Whatever happens on the UI thread is primarily synchronous and blocks the UI.

Now whenever we need to work with WCF services without blocking the UI we go for asynchronous calls(In Silverlight we have no option anyway), but the mistake we make is we call the WCF service directly from the UI thread(on say a button click). Now since the webmethod was called from the UI thread its Async Event Handler is also executed on the same thread. So this event handler becomes one of the many tasks the UI thread has to be performed and the end result is a slower UI update. An advantage here is that since we are on the UI thread we can update the UI element directly(else we would have to use a dispatcher!)

How else should we do this?:- An ideal way here would be to separate the task of the UI thread and disturb it only when needed i.e when we need to update the UI.

So basically use worker threads to invoke the webservices and handle their responses and use dispatchers  to update the User Interface! So the downside is slightly more complex code to finally update the UI but then you used WPF/Silverlight to get a great and responsive UI..it does come at a cost:-)

Hope this Bulb Flash helps you improve your app performance!!

Until some more flashes!