Archive for the ‘C#’ Category

TaskWsdlImportExtension–a hidden gem in the C# vNext async CTP samples

4 Comments »

NoWhen I first heard about the new async functionality in C# at PDC 2010 last week, my immediate reaction was; how can this be used to ease the development of asynchronous WCF/WF services (and clients).

Well, it turns out that someone on Microsoft has thought about the same thing; in the samples that accompanies the recently released C# async CTP, there’s a sample named (C# WCF) Stock Quotes. This picked my interest, and lo and behold; when I opened up the solution, I immediately noticed the TaskWsdlImportExtension.

Basically, the project contains an extension to WCF that plugs into the WSDL import pipeline, and customizes the output of the generated code you get when you use the Add Service Reference functionality (ASR) in Visual Studio. Now, I have to admit that I’m not the greatest fan of ASR and I normally write my own clients instead, but you can get the extension importer to work with svcutil.exe on the command line as well by pointing to a app.config wiring up the extension with the /SvcutilConfig:<file> parameter (or creating file named exactly Svcutil.exe.config in the same directory as you are doing the import in). More information can it can be found in the WSDL Import section in this MSDN article.

With this extension wired up, the C# client proxy code that is generated looks like this:

Now, that looks kinda complicated – and it is, but you don’t really need to understand what is to start using it. Since System.Threading.Tasks is a new feature in .NET 4.0, there is really nothing that stops you from using the extension right away – it doesn’t rely on the async/await keywords that we’ll see in C# vNext!

Now, if Microsoft hasn’t thought of it already; it would be nice to see a similar way of using System.Threading.Task/C# async in the implementation as well. I’m guessing it wouldn’t be too hard to create and it would probably involve a custom dispatcher invoker that would replace the default dispatcher in WCF (hint; I’m looking into this now).


The book shelf of a Connected Systems MVP

3 Comments »

A few days ago, Gøran Hansen of Capgemini and a an active member of the Norwegian Microsoft scene – as well as active in the Twittersphere, wrote a blog post called “A Software Craftsman’s Bookshelf” containing a picture of his book shelf with Software Development-related books, as well as a brief review of the titles. He tagged a bunch of other people – including me, so here’s my contribution to this book shelf meme

(I actually wonder why a UI-geek like Gøran chose a dull jpeg for visualizing his book shelf, so I’m stepping up – to show off that Mr. Non-UI guy can use the Stitch functionality in Deep Zoom Composer. The final product is hosted on DeepZoomPix – a Microsoft site for hosting Deep Zoom pictures.)

Update: Seems like the stupid wordpress.com blog hosting strips javascripts and object tags, so until I’ll get around to move this blog to a more sane hosting provider, I’ll have to put up a preview picture that hyperlinks to the DeepZoomPix site :-(

bookshelf_preview

(A click on the image will bring you to the real Deep Zoom image)

I actually thought about rotating the stitched picture counter-clockwise, so that the titles of the books would be easier to read, but I postphoned it to a moment when I have more time to stuff like this :-)

A description of the books + Amazon links, as well as a list of people I’d like to tag will be added later.


Parsing the command line with MGrammar – part 2

2 Comments »

In the first installment of this series we took a look at the basic grammar for parsing the command line with MGrammar. In this part I’ll show you how we can load in a compiled version of the MGrammar and parse the input (i.e. the command line) to produce a valid MGraph that we in turn can process in the backend code.

A quick reminder from part 1; the code is located here:
http://github.com/larsw/larsw.commandlineparser

You can download the code either by using git or downloading it as an archive. Once you’ve done that, open the solution LarsW.CommandLineParser.sln in Visual Studio 2008.

imageMost likely you will be presented with the following dialog box, informing you that opening the solution (or more correct the LarsW.CommandLineParser C# project inside) can pose a security risk. The reason for this is that I’ve included the a MSBuild task for compiling MGrammar files (.mg) into .mgx is that included in the Oslo SDK. Select the “Load project normally” and press OK.

We can first take a look at the extra plumbing I’ve added to the project to get the .mg file to compile. Right-click the LarsW.CommandLineParser project in the Solution Explorer, and choose Unload Project. Next, right-click it again, and choose Edit LarsW.CommandLineparser.csproj. This should bring up the project file will be shown as raw XML in the editor window.

In the first <PropertyGroup> I’ve added seven lines that I borrowed from a project created with the “M” template. They basically set’s up the path to various M-specific tools and auxiliary files.

The only line of these that really matter and that I had to tweak in order to get this right is the <MgTarget> element. Out of the box this is set to Mgx, that instructs the Mg compiler to spit out the result of the compilation as a .mgx file. As we will see later, the value needs to be set to MgResource in order to get the DynamicParser to load the .mgx as a resource.

If you navigate to the end of the project file, I’ve also added an <Import> element that imports some MGrammar specific MSBuild tasks and the most important thing; in the last <ItemGroup> section I’ve changed the element type from <None> to <MgCompile> for the cmd.mg file.

Well, we’ve been mucking around in the MSBuild plumbing too long now, haven’t we? Right-click the project again and choose Reload Project. When the project has loaded up again, build to ensure that everything is fine and dandy. Even though I haven’t stated it before, it should be obvious that the project depends on the latest (as of now that is the January 2009 CTP Refresh) Oslo SDK.

The core component is the CommandLineProcessor class.

It loads up the language (the compiled version of the cmd.mg) with DynamicParser.LoadFromResource(). The reason why we had to specify MgxResource as the MgTarget earlier is that if we don’t, and add the compiled .mgx file as a plain resource, the .LoadFromResource() method won’t find it. As of now, it seems that it will only look for resources with the .resource extension.

We then pass in the command line with a StringReader instance to the .Parse<T>() method on the DynamicParser instance. Even though it’s not specified, the T has to be object or a type that implements System.Dataflow.ISourceInfo. The internal/inner Node classes in GraphBuilder is what that will be handed out per default, but you can also create your own GraphBuilder and produce nodes from your own domain model.

So, by calling parser.Parse<object>(null, commandLineReader, ErrorReporter.Standard) we will get an instance to the root of the Abstract Syntax Tree (AST) returned if the input matches the grammar. The AST is basically a representation of the MGraph.

The next step is to traverse the AST and act upon the different node types. The grammar for this project is quite trivial and is mostly done by the private ProcessParameter() method in the CommandLineProcessor class. I suggest that you take a look at it if you’re interested in doing something similar.

So, just create an instance of the CommandLineProcessor and pass in an instance of an arbitrary class that contains method that will handle the command line arguments. To specify that a method is a argument handler, decorate it with the CommandLineArgumentHandler attribute. It will take in three parameters; short form & long form of the argument keyword and a description. For now the description isn’t used for anything but the idea is that the command line processor can auto generate a usage screen for you (typically shown with –?).

That’s about it – if you find it useful or modify the code, please let me know. With git you can push me a change set and I will try to merge it if you’ve come up with a cool feature.


Parsing the command line with MGrammar – part 1

1 Comment »

Let’s take a look at how we can use MGrammar to create a mini-DSL for a language most developers knows quite well; command line arguments. Most applications that accepts arguments on the command line in Windows (or in Linux/Un*x for that matter) is on the form:

Application.exe /a /b 123 /c “some input string goes here”

Some applications uses / as the “marker” that an argument is following, while other use - or . It is also quite common to allow both a verbose and an abbreviated version of the same command.

Well, that was the Command line 101. Here’s a brief explanation and some code on how we can do this with MGrammar + C#.

Here’s a screenshot of Intellipad where the MGrammar for the command line parsing DSL is displayed in the second pane (Click the image to show the picture in full size):

image If anyone has a Windows Live Writer plugin that does syntax highlighting of of M & MGrammar – please send me and email :-)

[Side note: Since the grammar for M & MGrammar is shipped as a part of the Samples in the Oslo SDK, it should be quite easy to put together a basic HTML syntax highlighter for both languages by loading the compiled grammar up and use the Lexer in System.Dataflow. Note to self: Investigate this further]

If you’re not familiar with MGrammar, I’ll walk through the cmd.mg for you. The general idea is that MGrammar helps you transform text (the input) into MGraph, a Directed-Label Graph, that can contain ordered an unordered nodes. The MGraph can then be traversed and acted upon.

The language CommandLineLang resides in a module named LarsW.Languages. the module keyword works pretty much as namespace NNN in C# and is used to divide the world into smaller pieces. Things that lives inside a module might be exposed to the outside by using the export keyword (not shown in the example) and thing from the outside might be welcomed in by using the import keyword.

The same way void Main(string[] args) is the default entry point in a C# application, syntax Main = …; Is the entry point in a MGrammar-based language.

In general, there are two things we need to work with in a MGrammar; syntax  and token statements. Last thing first; tokens are regular languages (regular expressions) where you can define the set of characters that will make a match using unicode characters, sequences of these and the normal Kleen operators; ? for optional elements, * for zero-to-many and + for one-to-many. Paranthesis – () – can be used for grouping of sets and | is used for choosing between two options. If you are familiar with regular expressions, writing tokens should be quite easy. Not that you can, and will, write the tokens in a hierarchical fashion, since your grammar would turn into a complete mess if you have to expand a lot of the regular expressions.

Syntax rules describe the context languages and can be made up by tokens and other syntax elements. You also have the possibility to project the matched tokens differently with the => operator. Without this you would have to do a lot more of coding in your backend code, so you will definitely want to exercise your grammar in Intellipad with some samples until you’re satisfied with the MGraph it outputs.

   syntax Rule = tToken tString tStatementTerminator;
   syntax Rule = tToken string:tString tStatementTerminator
             => Rule { Value { string }};

While not used in this sample, recursive rules is an essential building block in order to build grammars that can consume things like a comma-separated list (or repeating elements in general).

A repeating rule can look something like this:

   syntax Items = item:Item => Items {item}
                | items:Items item:Item
                 => Items {items, item};
   syntax Item = ...;

As you probably notice, the Items rule is used inside itself – so this rule is recursive. The “problem” with this type of syntax rules is that they produces nested nodes in the MGraph. This isn’t really a problem, but it makes the traversing in the backend more tedious. To mitigate this, The Oslo team came up with the valuesof() construction that will “flatten” out a set of hierarchical nodes for you:

   syntax Items = item:Item => Items {item}
                | items:Items item:Item
                  => Items {valuesof(items), item};

The Interleave keyword basically tells the lexer which tokens it can ignore. This will typically be whitespace and comments.

So now that we know some of  the basics, lets take a look at cmd.mg again. It basically consists of four syntax rules and four token rules. I’ve applied custom projections to most of the rules so that the MGraph production looks reasonable sane.

In the next installment of this series I will discuss how we can create a backend that will consume the MGraph and take action on the command line parameters.

The source is released under the Apache License 2.0 and can be found here: http://github.com/larsw/larsw.commandlineparser . This is the first project I release on GitHub, and if the experience is good, I believe I’ll continue to use it.

There’s a Download button that you can use to download either a zip or tar ball of the source tree, if you haven’t installed git.

kick it on DotNetKicks.com


The Future of C#

No Comments »

Live from the session:

Will cleanup later:

evolution

1.0 – 2.0 – 3.0

impedence mismatch – programming languages and data

LINQ

Trends: Declarative / Dynamic / Concurrent

Declarative Programming

Imperative –> Declarative
How           -    What

 

Dynamic Languages

* Simple and succinct
* Implicitly typed
* Meta-programming
* No compilation

Static Languages

* Robust
* …

Concurrency

The elephant in the room
Moores law has stopped working
Not one single silver bullet

C# 4.0

Dynamic programming

Dynamically types objects
Optional and named parameters
Improved COM interoperability
Co- and Contra-variance

Dynamic Language Runtime
* Expression trees
* Dynamic dispatch
* Call Site Caching

IronPython & IronRuby today

Tomorrow: C# and VB.NET and others…

Object Binder: .NET
JavaScript Binder: Silverlight
Python Binder: python
Ruby Binder: Ruby
COM Binder: Office

Calculator calc = GetCalculator();
int sum = calc.Add(10, 20);

object calc = GetCalculator();
Type calcType = calc.GetType();
object res = calcTYpe.InvokeMember(…);
int sum = Convert.ToInt(res);

C# 4.0:
dynamic
calc = GetCalculator();
int sum = calc.Add(10, 20);

=   : dynamic conversion
.Add  : Dynamic method invocation

dynamic x = 1;
dynamic y = “Hello”;
dynamic z = new List<int>  {1, 2, 3, 4};

When operand(s) are dynamic

* Member selection deferred to run-time
* At run-time, actual type(s) substituted for dynamic
*
Static result type of operation is dynamic

IDynamicObject ( duck typing)

optional and named parameters:

OpenTextFile(string path, Encoding encoding = null, bool detectEncoding = true, bufferSize = 1024);

OpenTextFile(….);

Improved COM interop

No more ref missing…  doc.SaveAs(“Test.docx”);

Co- and Contra-variance

string[] strings = GetStringArray();
Process(strings);
void Process(object[] objects) { … }

C# 4.0 supports safe co- and contra-variance.

public interface IEnumerable<out T>
{

}

out = Co-variant Output positions only

public IComparer<in T>
{

}

in = Contra-variant input positions only

Variance in C#4.0

*Supported for interface and delegate types
* “Statically checked definition-site variance”
*Value types are always invariant
** IEnumerable<int> is not IEnumerable<object>
** Similar to existing rules for arrays
* ref and out parameters need invariant types

Compiler as a Service

Source files –> Compiler –> .NET Assembly

* Meta-programming
* Read-Eval-Print loop
* Language Object Model
* DSL Embedding

CSharpEvaluator ev = new CSharpEvaluator();
ev.Usings.Add(“System”);

[Damn, all this is so cool]
ev.Eval(“for (int i = 0; i < 10; i++) Console.WriteLine(i * i)”);