Thursday, May 12, 2011

Long live .NET Reflector. Part II “The New Hope”

Great news! Jet Brains, the magicians behind Resharper and Team City, are out on a quest to save us from misery show us the light. dotPeek is their brand new .NET decompiler, still in early build, but live and kicking.
I sincerely mourned the Reflector’s untimely “departure” and the timing couldn’t be better! The new tool is free-of-charge, which is against any commercial sense, according to the Red Gate. And I am pretty sure that Jet Brains will figure out some smart licensing, as they did with the awesome Team City (even if it won’t be free in the future, I’d rather pay for dotPeek, than Reflector).

The interface is pretty slick and should look familiar to Resharper users – it even has the same Usage windows! Tabs in the code window is definitely a welcomed addition. There are tons of other features which I didn’t have time to explore yet.
The only thing I am missing so far is the Reflector-style navigation using type names as links. There are few bugs, but remembering Resharper early days I am perfectly OK with it – Jet Brains proved that they can quickly react on user’s feedback. Application size is noticeably bigger, than Reflector but it will be probably eventually optimized down.
Undeniably the best part in this news – we have a choice again.

Sunday, May 08, 2011

Why I enjoy software development

Because I have one of these moments weekly

seen on Damn LOL

Saturday, May 07, 2011

Managing workflows with WorkflowControlClient

How the heck does it work?! MSDN is surprisingly unhelpful on this matter (list of class members with couple of very obvious one-line snippets is a mockery of documentation).
Unfortunately, when configuring the IWorkflowInstanceManagement interface you have to be very precise. Let’s do it step by step, and while we are at that, let’s make the service implementation more WCF-compliant.
1. Make your workflow service implement a contract. There won’t be a magic but rather a trick – the workflow service will think that it exposes an interface, name of which you typed in the ServiceContractName of your Receive shapes after {} (if you didn’t – do it) and it accidentally matches the interface with the same name in your code (or something similar to that).
In our case let’s name the XAML interface {}ITeddyBearService and our “artificial interface” - TeddyBearStore.Contracts.ITeddyBearService

2. Make WF service look like good old WCF. By default WF service, hosted in IIS is exposed as a magic no-name service: service tag is completely missing and only nameless ServiceBehavior allows some primitive configuration.

<serviceMetadata httpGetEnabled="true"/>
<!--<sqlWorkflowInstanceStore connectionStringName="WF4Persistence" />-->
<serviceDebug includeExceptionDetailInFaults="true"/>

You can make it more WCF-like by adding a real service in the configuration file and naming the behavior:

<service name="TeddyBearService" behaviorConfiguration="workflowServiceBehavior">
<endpoint address=""
binding="basicHttpBinding" bindingConfiguration="myBasicHttpBinding"
contract="ITeddyBearService" />

Very, very important for the Workflow Control Client – the service name must match exactly the ConfigurationName property (can be found at the top of the XAML file or in the Properties window in the workflow designer window).

3. Add the Workflow Control Endpoint:

<service name="TeddyBearService" behaviorConfiguration="workflowServiceBehavior">
<endpoint address=""
binding="basicHttpBinding" bindingConfiguration="myBasicHttpBinding"
contract="ITeddyBearService" />
<endpoint address="wce"
binding="basicHttpBinding"  bindingConfiguration="myBasicHttpBinding"
kind="workflowControlEndpoint" />

4. Add standard endpoint description. They might be accessible by default but I did not bother to test this assumption, so add them in the web.config anyway. This is your last step for the service side.

<service name="TeddyBearService" behaviorConfiguration="workflowServiceBehavior">
<endpoint address=""
binding="basicHttpBinding" bindingConfiguration="myBasicHttpBinding"
contract="ITeddyBearService" />
<endpoint address="wce"
binding="basicHttpBinding"  bindingConfiguration="myBasicHttpBinding"
kind="workflowControlEndpoint" />

5. Add client endpoints, one for your service (remember the “artificial” TeddyBearStore.Contracts.ITeddyBearService contract?) and another - for the Workflow Control Client functionality, which is essentially gives you an access to the AppFabricesque goodness. Note that the latter has /wce added to the address because the XAML service will refuse to expose both contracts from the same address.

<endpoint  name="TeddyBearEndpoint" address="http://localhost/TeddyBearStore/Services/TeddyBear.xamlx"
binding="basicHttpBinding" bindingConfiguration="myBasicHttpBinding"
<endpoint  name="TeddyBearControlEndpoint" address="http://localhost/TeddyBearStore/Services/TeddyBear.xamlx/wce"
binding="basicHttpBinding" bindingConfiguration="myBasicHttpBinding"

6. Embrace the power. Now finally you have a fine-tuned control over you workflow services:

WorkflowControlClient client = new WorkflowControlClient("TeddyBearControlEndpoint");


Special thanks to: Leon Woo, Funky Mule, Ron Jacobs
Thanks to: StackOverflow
No thanks to: MSDN

Thursday, May 05, 2011

Long live .NET Reflector

Of course it has happened.

I’ve blogged about .NET Reflector acquisition two years ago. I called news “gruesome” and reflected (sic!) on my (recent then) experience with the Red Gate.

I’ve got called out on both cases by Joint CEO Simon Galbraith:

["free community 30-day trial"] – … isn't our plan.
We bought the website a couple of years ago and there was similar concern from the sql professional community then. Since then we've kept the site free, removed most of the ads, upped the quality and multiplied traffic by 3 - there are now more than 850,000 members up from ~200,000 at the time of purchase.
We've not ironed out exactly what we'll do with Reflector (because we've not had a chance to interact with the Reflector user community) but we bought it because it is popular and has a passionate user base - we'd be fools to damage either of those things.
Simon Galbraith
Joint CEO
Red Gate Software

As it turned out he spoke the truth: there is no plans for the “Free Community 30-days trial” there is a “14-day Trial” version, it is a big difference, folks. Neither I can deny that is still around – as a marketing tool, collecting emails from subscribers (oh, wait! I remember the site now – it is in my Google excluded searches list, because when you are in a hurry to find an answer, it offers you to register).


Comments sum it up nicely. I can’t agree with some emotions, but I share the feelings.

I sincerely hope that commercially senseless Spolsky and Atwood both are or will be millionaires – god speed! Stack Overflow is an example of how you can turn a respect of the community to a profit.

Sad but true – trust is unprofitable. As developers in hearts, the decision makers are probably sympathetic but there is nothing personal – it’s strictly business. There is still a hope though, and example being the Scott Gu’s team, which most likely has no commercial sense either, although it probably costs the Microsoft more, than Reflector to the Red Gate.

P.S. Oh, by the way, we’ve eventually given up on our SQL Toolbelt Continuous Integration project. We got stuck in those licensing cobwebs, our management lost patience and I haven’t considered Red Gate for my automaiton projects ever since.

also check Feed Burner

Wednesday, May 04, 2011

MVC Scaffolding exception


Don’t optimize your NuGet package libraries until you know exactly what are you doing. I screwed something up eventually, so when I tried to use the awesome “Add Controller”  wizard, I’ve got “The term ‘Get-Scaffolder’ is not recognized as the name of a cmdlet…” error.

Solution is pretty simple: uninstall MVC Scaffolding and install from the Package Manager Console :

PM> Uninstall-Package MvcScaffolding -RemoveDependencies
PM> Install-Package MvcScaffolding

also check Feed Burner

Tuesday, May 03, 2011

Crazy Project: Two steps forward, one step sideways

I would be definitely long done should I use my hammer familiar tools for the work, but I would miss all the fun. I am positively in love with MVC3 – the Microsoft team is doing an amazing job! Elegance with which they embrace the latest C# additions makes my cry Bazinga! Let me list some lessons I’ve learned so far on Crazy Project.

MVC3 Scaffolding – not just for Entity Framework

I almost got ready to bitch about MVC team again but discovered a neat expansion (it is fully expandable!) for the MVC 3 Scaffolding – in addition to default EF-centric and empty view templates it can use repositories. All you need to do is navigate to View->Other Windows->Package Manager Console in Visual Studio and type Install-Package MvcScaffolding. It would be nice to have them installed by default - all it does is generate CRUD-compatible Views and Controller and it really needs to know only the underlying entity type. It could cover 99% scenarios out there, including EF one.

MVC validation and Java Script manipulations

Building an interactive (Java Script-backed) form I hit a problem with the built-in validation (generated from Model validation attributes) – I was hiding some fields with Java Script but the validation was still firing for them. Quick search provided a solution: the Form element can be told to exclude fields decorated with certain class from the validation:

ignore: ".ignore"

Which means that no validation should be performed for a field decorated with the class=”ignore” attribute.

Unfortunately this didn’t work for me after I added the code snippet to my document.ready event (I guess, that I just misused the functionality but I don’t know better yet and hope for my audience help). As an immediate measure I had to change a bit the jquery.validate.unobtrusive.min.js file which is included with MVC3 template: right after success: a.proxy(j, d) text I added ,ignore: “.ignore”.

Similarly it should work in a wider scale: when ignore: “:hidden” rule is used instead, all hidden fields will be excluded from validation – the jQuery is smart enough to consider field hidden if it is inside a hidden container, like div tag. Search the jquery.validate.unobtrusive.js file for an unscrambled version of the code to understand better what it does – the resulting function should look like this:

function validationInfo(form) {
    var $form = $(form),
        result = $;

    if (!result) {
        result = {
            options: {  // options structure passed to jQuery Validate's validate() method
                errorClass: "input-validation-error",
                errorElement: "span",
                errorPlacement: $.proxy(onError, form),
                invalidHandler: $.proxy(onErrors, form),
                messages: {},
                rules: {},
                success: $.proxy(onSuccess, form),
                ignore: ":hidden"
            attachValidation: function () {
            validate: function () {  // a validation function that is called by unobtrusive Ajax
                return $form.valid();
        $, result);
    return result;

I can’t say enough about awesomeness of MVC3’s adherence to the web standards. No more weirdo ASPX tricks – just pure old DOM, CSS and HTML!

Update: Aforementioned is still not enough - ModelState server-side validation will fail, because it is still going through all fields. Undesired properties should be removed from the ModelState:

if (payeeViewModel.Currency==US)

Get Postal

I am new to MVC and jQuery, so I am stepping on the same mines, which my more experienced colleagues know by heart. I had this as my first jQuery exercise, which was returning a JSON list using AJAX get:

$.getJSON('@Url.Action("GetItems")', { id: selectedCategory }, function (response)
    each(response.items, function (index, iteml)

I was really proud of it until realized that simply by navigating to u

Technorati Tags: ,,,,,
ser will get a nice (or weird, depending on a purpose) JSON array with my items back. Not good. So I changed it a bit:
$.post('@Url.Action("GetItems")', { id: selectedCategory }, function (response)
    each(response.items, function (index, iteml)

And GetItems action, which does the job, accepts only HttpPost verb, while another one by the same name throws back a HttpNotFound result (back to the nature!). The solution is not perfect, as POST is not that difficult to hack (of course I have a security on top of it) but at least it won’t be stumbled upon accidentally.

Shaping workflow service to WCF

The default implementation of the WF4 service, which can be seen in 90% of presentations, uses Service Reference. If you ask me it is a part of Poor Man’s SOA Toolset - an ugly and inflexible technique. Here is an excellent post about how to avoid it – “How to make a WorkflowService implement a contract”. A couple tricks with ChannelFactory and you have a Service Reference-less project!

Workflow correlation

The sad discovery of the day – workflow can not use the same operation twice. Which kind of makes sense and doesn’t at the same time. It is all about correlation – the area where WF4 shares voodoo magic with BizTalk.
This particular post helped me to get better understanding the WF4 correlation. At least the sample is not using string-based correlation handler, unlike many others.

© 2008-2013 Michael Goldobin. All rights reserved