CRM 4.0 and WCF Data Services

Standard

UPDATE: The below post has been sat in my drafts since March 2011. Not sure why I didn’t post it given the title of this site does contain the word musings! Anyway, 6 months on and two projects later I can summarise the Advanced Developer Toolkit as it’s known as follows:

It’s considerably better than Fetch-Xml but still has limitations given that it is essentially talking directly to the Web Services. Make fiddler your best friend and keep a close eye on the queries you’re producing. The expressions the API is building underneath are more than happy to produce pseudo select n+1 and given these are against the web servies this is very bad if you let it get out of control.

Managing the push of entity schema changes made in CRM into the typed entities produced by crmsvcutil can be a pain. However with a suitable build process in place and having setup the deployment of the binary through a corporate NuGet feed I have the deployment workflow setup pretty slick for us now.

The original post I failed to post back in March follows:
I can see a requirement dropping on us in the near future for exposing the contacts in our new CRM 4.0 system to the wider world. The wider world being other divisions within the organisation.

I’m not a CRM expert as we “got a man in” for that bit and one of the other devs on the team picked up the work with him. I am familiar with the plug-in architecture and the WS- based Fetch XML API into CRM having written a replication service from one of our legacy databases.

So, back to the point. We think we’re going to see a need for some querying capability over our CRM data and having had experience of the web services exposed by CRM I immediately decided that pointing the development teams of our other divisions at that API probably wasn’t ideal.

We need options and in this world of LINQ to absolutely everything I decided IQueryable needed to come to my rescue as there must surely be some form of LINQ provider available provided as either open source or better still through Microsoft. A quick Google came up with a project on CodePlex that whilst flagged as deprecated I was pleased to see its reason for deprecation was that Microsoft’s v4.0 of the CRM SDK included a LINQ to CRM Provider. Superb!

Advertisements

Clearing an observableArray in knockoutjs

Standard

I recently had the need to remove all items from a multidimensional observable array and discovered that doing this by reinitialising means you need to call ko.applyBindings(…) again. For performance reasons this isn’t something you want to be doing to often. The correct way to do this is call the RemoveAll() method directly on the observableArray itself.


var viewModel = {
    customers: ko.observableArray([]),
    moreprops: ko.observable('whatever');
}

ko.applyBindings(viewModel);

//If we now need to clear down the array (in our case this was to restart a quiz) 
//you do the following
viewModel.customers.removeAll();

//You can now add items back into the array without needing to call applyBindings again.

knockout 1.3.0 shaping up nicely

Standard

Although knockout 1.3.0 should be coming out of beta shortly I just wanted to put this post out there to express my delight in having seen the new features.  In particular the containerless control flow (which doesn’t strike me as a particularly intuative feature name) and access to the parent binding contexts.  These features will inevitably result in cleaner markup and hopefully both will result in simpler viewModels in support of list based binding.

However, I’m currently not convinced on the use of the class attribute to declare actions against your observables via jQuery live though.  That doesn’t in my opinion lead to particularly semantic html.  Couldn’t we see an additional data- attribute such as data-action?

More information on 1.3.0 available over on Steven Sanderson’s blog

Managing NuGet at the Visual Studio Solution Level

Standard

A particularly useful feature of the NuGet Package Manager extension within Visual Studio 2010 is the ability to manage your packages at the solution level. This can be really useful when you’re creating a new solution containing several projects and you want to share common packages across them all.

With the initial project structure as below let’s say we want to add log4net to both DaxaarInc.BlogSite.Web and DaxaarInc.BlogSite.Data projects.

We can achieve this by selecting Manage NuGet Packages… at the Solution level rather than at the project level.

As you can see below we now get the option to select which projects this package will be installed into. Whichever you choose they will all share the same version of the package held within a shared packages folder. Each project continues to get its own packages.config file so they can diverge on version if you really needed to.

Notice how our packages folder is now stored at the solution level and not at the project level on disk.

Finally, if the existing solution and projects are under TFS Version Control the packages folder is now also added automatically. I’m not sure which release of NuGet this arrived in as I haven’t kicked off a new solution for a few months now but it’s a welcome addition. I’m also unsure if this integration works when you have a different version control provider such as SVN integrated into VS. I’ll maybe give that a try in the near future using AnkhSVN.

 

Hope this proves useful. In an upcoming post I’m going to be looking at the Workflow for creating a new solution structure including setting up in TFS Version Control, Solution structure and creating your own Corporate NuGet Feed for providing an easy install process for your own common libraries.