Code Snippet

Retrieving Nested Properties from Lambda Expressions

EltonStoneman — Fri, 06 Nov 2009 04:14:55 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Supposing you’re using a lambda expression as a neat way to access a named property:

s => s.FirstName

- when what you really want is to access it without using a string for the property name (“FirstName”), for example to specify the source or target property for a mapping exercise.

It’s easy if the expression is a direct property of the parameter type – a member of the “s” in the expression; casting the whole expression as a MemberExpression gives you access to the member as a PropertyInfo. You can encapsulate it in an extension method of LambdaExpression:

public static PropertyInfo AsPropertyInfo(this LambdaExpression expression)

{

PropertyInfo info = null;

if (expression.Body.NodeType == ExpressionType.MemberAccess)

{

info = ((MemberExpression)expression.Body).Member as PropertyInfo;

}

return info;

}

- which lets you access the property like this:

Expression<Func<FullUser, object>> exp = s => s.FirstName;

PropertyInfo sourceProperty = exp.AsPropertyInfo();

But if the expression represents a property of a nested type, or a property of a nested type of a nested type:

s => s.Address.Line1

s => s.Address.PostCode.Code

- then it’s different.

What you want in this case is an executable expression which will access the containing object of the property (e.g. get you the Address property of the source object, or the PostCode property of the Address property of the source object). You also want the PropertyInfo of the target property (e.g. Line1 or Code). And you want both the property accessor and the PropertyInfo from the same expression.

This is not too difficult. It doesn’t require a stack of target objects and PropertyInfos as originally feared. Firstly store the PropertyInfo from the nested target in the normal way:

targetPropertyInfo = targetExpression.AsPropertyInfo();

- this gives us access to Line1 or Code. Then store the expression which retrieves the path to the containing object for the property from the original source - .Address or .Address.Postcode. In the expression tree, this is the expression which contains the root to the original parameter:

if (targetExpression.Body.NodeType == ExpressionType.MemberAccess)

{

MemberExpression memberExpression = targetExpression.Body as MemberExpression;

if (memberExpression.Expression.NodeType != ExpressionType.Parameter)

{

ParameterExpression parameter = GetParameterExpression(memberExpression.Expression);

if (parameter != null)

{

_targetExpression = Expression.Lambda(memberExpression.Expression, parameter);

}

The key line is the one which contains Expression.Lambda(). The parent expression is a MemberExpression (e.g. s.Address, or s.Address.PostCode) which itself is not executable. You can’t compile a MemberExpression and execute it on an object to get the member, as the expression needs to know the parameter it executes against.

Expression.Lambda creates a compilable, executable expression against a provided target parameter – which we already have from the “s” of the original expression, and we can find for any level of nesting:

private ParameterExpression GetParameterExpression(Expression expression)

{

while (expression.NodeType == ExpressionType.MemberAccess)

{

expression = ((MemberExpression)expression).Expression;

}

if (expression.NodeType == ExpressionType.Parameter)

{

return (ParameterExpression)expression;

}

return null;

}

So now we have the PropertyInfo for the nested target, and an expression which will give us the nested target, we can set the target property value like this:

object target; //this is the top-level object

//...

realTarget = expression.Compile().DynamicInvoke(target);

targetPropertyInfo.SetValue(realTarget, value, null);

It’s quite a complex requirement, but the solution is straightforward and the complexity is isolated from the calling code. Note that the example code above only deals with nested properties, not expressions with mixed properties and method calls (e.g. s.Address.GetPostCode().InwardCode), but it’s straightforward to cover those cases too.

jQuery Date Validation in Chrome

EltonStoneman — Thu, 29 Oct 2009 19:20:53 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

We had a fiddly issue with date validation in an ASP.NET MVC page failing for a valid date in Chrome, but passing in Firefox, IE etc. Tracing through our own code and xVal, the issue was narrowed down to the jQuery validation plugin (jquery.validate.js). For simple date validation, the library instantiates a date object from the given text value and lets JavaScript raise errors for invalid dates:

date: function(value, element) {

return this.optional(element) || !/Invalid|NaN/.test(new Date(value));

Chrome seems to ignore the current locale when it creates the date object, so a valid date in UK dd/mm/yy format – 29/10/2009 – fails as Chrome seems to interpret it in US mm/dd/yy format. Easy to test outside of all other code by entering some simple JavaScript into the address bar:

javascript:new Date('29/10/2009').toString()

Which Firefox renders as expected:

- as does IE (even IE6):

- but which Chrome renders as an invalid date:

You can also test it by navigating to the jQuery date validation sample page, and checking results for the same date in different browsers.

The fix is a simple change to the jQuery script to force the use of the current locale:

// http://docs.jquery.com/Plugins/Validation/Methods/date

date: function(value, element) {

//ES - Chrome does not use the locale when new Date objects instantiated:

//return this.optional(element) || !/Invalid|NaN/.test(new Date(value));

var d = new Date();

return this.optional(element) || !/Invalid|NaN/.test(new Date(d.toLocaleDateString(value)));

Resolving Special Folders in WiX 3.0

EltonStoneman — Tue, 29 Sep 2009 18:09:43 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

One of the frustrations of working with WiX is that when you want to do something out of the ordinary, chances are it's provided somewhere in a WiX extension, but unless you trawl through the XSDs you're not likely to find it. I had this issue when I wanted to resolve the special folder My Music through WiX, so I could put the full path into a config file.

Various special folders are already available as properties to the installer, including My Documents and My Pictures, but not My Music. Adding an extension to expose Environment.GetSpecialFolder() to WiX is a trivial implementation in a couple of classes (comments omitted for brevity):

public class EnvironmentExtension : WiXExtension

{

private EnvironmentPreprocessorExtension preprocessorExtension;

public override PreprocessorExtension PreprocessorExtension

{

get

{

if (this.preprocessorExtension == null)

{

this.preprocessorExtension = new EnvironmentPreprocessorExtension();

}

return this.preprocessorExtension;

}

public class EnvironmentPreprocessorExtension : PreprocessorExtension

{

private const string SPECIALFOLDER = "specialFolder";

public override string[] Prefixes { get { return new string[] { SPECIALFOLDER }; } }

private List<string> _specialFolders;

private List<string> SpecialFolders

{

get

{

if (_specialFolders == null)

{

_specialFolders = new List<string>(Enum.GetNames(typeof(Environment.SpecialFolder)));

}

return _specialFolders;

}

public override string GetVariableValue(string prefix, string name)

{

string result = null;

if (prefix == SPECIALFOLDER && SpecialFolders.Contains(name))

{

Environment.SpecialFolder specialFolder = (Environment.SpecialFolder)Enum.Parse(typeof(Environment.SpecialFolder), name, true);

result = Environment.GetFolderPath(specialFolder);

}

return result;

}

Reference the folder you want from the Environment.SpecialFolders enum as a property in your WiX script:

- and add the extension assembly to your light and candle calls, making sure the DLL is available at runtime :

candle -out x.y.z.WiXobj x.y.z.wxs -ext EnvironmentExtension

light -out x.y.z.msi x.y.z.WiXobj -ext EnvironmentExtension -cultures:en-us

But I suspect it's already available somewhere in WiX.

Lazy-Loading with Object Extensions

EltonStoneman — Wed, 23 Sep 2009 18:38:57 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

If you make heavy use of lazy-loaded properties, the repetitive if-backing-field-null-then-instantiate code can be centralized in an extension method on the object class:

/// <summary>

/// Extension methods for <see cref="Object"/>

/// </summary>

public static class ObjectExtensions

{

/// <summary>

/// Lazy-loads a property

/// </summary>

/// <typeparam name="T">Type of property</typeparam>

/// <param name="obj">Extended object</param>

/// <param name="field">Property backing field</param>

/// <param name="load">Property loading function</param>

/// <returns>Lazy-loaded property</returns>

public static T LazyLoad<T>(this object obj, ref T field, Func<T> load)

{

if (field == null || field.Equals(default(T)))

{

field = load();

}

return field;

}

Classes then define lazy-loaded properties using the extension method, specifying the backing field and the method used to populate it:

protected List<MediaItem> AllItems

{

get

{

return this.LazyLoad<List<MediaItem>>(ref this._allItems,

() => new List<MediaItem>());

}

- rather than:

protected List<MediaItem> AllItems

{

get

{

if (this._allItems == null)

{

this._allItems = new List<MediaItem>();

}

return this._allItems;

}

Only a tiny enhancement, but it isolates some general code and reduces the chances of causing an infinite loop by typing the property name rather than the field name.

Managing Concurrency over Service Boundaries

EltonStoneman — Thu, 16 Apr 2009 04:15:04 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Managing concurrency within an application boundary can be straightforward where you own the database schema and the application's data representation. By adding an incrementing lock sequence to tables and holding the current sequence in entity objects, you can implement optimistic locking at the database level without a significant performance hit. At the service level, the situation is more complicated. Even where the database schema can be extended, you wouldn't want the internals of concurrency management to be exposed in service contracts, so the lock sequence approach isn't suitable.

An alternative pattern is to compute a data signature representing the retrieved state of an entity at the service level, and flow the signature alongside the entity in Get services. On Update calls, the original data signature is passed back and compared to the current signature of the data; if they differ then there's been a concurrency violation and the update fails. The signature can be passed as a SOAP header across the wire so it's not part of the contract and the optimistic locking strategy is transparent to consumers.

The level of transparency will depend on the consumer, as it needs to retrieve the signature from the Get call, retain it, and pass it back on the Update call. In WCF the DataContract versioning mechanism can be used to extract the signature from the header and retain it in the ExtensionData property of IExtensibleDataObject. The contents of the ExtensionData property are not directly accessible, so if the same DataContract is used on the Get and the Update, and the signature management is done through WCF extension points, then concurrency control is transparent to users.

I've worked through a WCF implementation for this pattern on MSDN Code Gallery here: Optimistic Locking over WCF. The sample uses a WCF behavior on the server side to compute a data signature (as a hash of the serializable object – generating a deterministic GUID from the XML string) and adds it to outgoing message headers for all services which return a DataContract object. On the consumer side, a parallel behaviour extracts the data signature from the header and adds it to ExtensionData, by appending it to the XML payload and using the standard DataContractSerializer to extract it.

The update service checks the data signature passed in the call with the current signature of the object and throws a known FaultException if there's been a concurrency violation, which the WCF client can catch and react to:

Sixeyed.OptimisticLockingSample

The sample solution consists of four projects providing a SQL database for Customer entities, WCF Get and Update services, a WCF client and the ServiceModel library which contains the data signature behaviors. DataSignatureServiceBehavior adds a dispatch message formatter to each service operation, which computes the hash for any DataContract objects being returned, and adds it to the message headers. DataSignatureEndpointBehavior on the client adds a client message formatter to each endpoint operation, which extracts the hash from incoming calls, stores it in ExtensionData and adds it back to the header on outgoing calls.

Concurrency checking is done on the server side in the Update call, by comparing the given data signature to the signature from the current object state:

Guid dataSignature = DataSignature.Current;

if (dataSignature == Guid.Empty)

{

//this is an update method, so no data signature to

//compare against is an exception:

throw new FaultException<NoDataSignature>(new NoDataSignature());

}

Customer currentState = CustomerEntityService.Load(customer);

Guid currentDataSignature = DataSignature.Sign(currentState);

//if the data signatures match then update:

if (currentDataSignature == dataSignature)

{

CustomerEntityService.Update(customer);

}

else

{

//otherwise, throw concurrency violation exception:

throw new FaultException<ConcurrencyViolation>(new ConcurrencyViolation());

}

A limitation of the sample is the use of IExtensibleDataObject to store the data signature at the client side. Although this is fully functional and allows a completely generic solution, it relies on reflection to extract the data signature and add it to the message headers for the update call, which is a brittle option. Where you have greater control over the client, you can use a custom solution which will be more suitable – e.g. creating and implementing an IDataSignedEntity interface, or if consuming the services in BizTalk, by using context properties.

Making Logging Cheaper with Lambda Expressions

EltonStoneman — Thu, 16 Apr 2009 04:08:28 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The venerable log4net library enables cheap instrumentation with configured logging levels, so logs are only written if the log call is on or above the active level. However, the evaluation of the log message always takes place, so there is some performance hit even if the log is not actually written. You can get over this by using delegates for the log message, which are only evaluated based on the active log level:

public static void Log(LogLevel level, Func<string> fMessage)

{

if (IsLogLevelEnabled(level))

{

LogInternal(level, fMessage.Invoke());

}

Making the delegate call with a lambda expression makes the code easy to read, as well as giving a performance saving:

Logger.Log(LogLevel.Debug,

() => string.Format("Time: {0}, Config setting: {1}",

DateTime.Now.TimeOfDay,

ConfigurationManager.AppSettings["configValue"]));

For simple log messages, the saving may be minimal, but if the log involves walking the current stack to retrieve parameter values, it may be worth having. The sample above writes the current time and a configuration value to the log, if set to Debug. With the log level set to Warn, the log isn't written. Executing the call 1,000,000 times at Warn level consistently takes over 3.7 seconds if the logger call is made directly, and less than 0.08 seconds if the Lambda delegate is used:

With a Warn call, the log is active and the direct and Lambda variants run 5,000 calls in 8.6 seconds, writing to a rolling log file appender:

I've added the logger and test code to the MSDN Code Gallery sample: Lambda log4net Sample, if you're interested in checking it out.

Applying WCF Message Formatters Using Configuration

EltonStoneman — Sun, 05 Apr 2009 03:15:09 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The WCF message formatter interfaces IClientMessageFormatter and IDispatchMessageFormatter let you intercept WCF messages on the client or service side at the point of serialization and deserialization. They're useful injection points as they give you access to the input or output parameter values of the service call, and to the incoming or outgoing WCF Message object. The formatters allow you to inspect or modify the message content or headers, using the call parameters to drive your logic.

Formatters need to be applied as operation behaviors, so there's no direct way to add them via binding configurations – typically they're added programmatically to the client channel, or to the service as attributes on the operation contract. But if your requirements are to add the same formatter to every operation and you want the flexibility of the configuration model, you can add formatters by piggybacking onto other behaviors which can be specified in configuration – IEndpointBehavior on the client and IServiceBehavior on the service:

(more detail on the data signature project in a future post).

Client Side

DataSignatureOperationBehavior.ApplyClientBehavior adds a DataSignatureClientFormatter to a single client operation:

public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)

{

DataSignatureClientFormatter formatter = new DataSignatureClientFormatter();

formatter.OrginalFormatter = clientOperation.Formatter;

clientOperation.Formatter = formatter;

}

Adding the formatter to one operation cannot be specified in client-side configuration. However the DataSignatureOperationBehavior can be added to every client operation in an endpoint using IEndpointBehavior.ApplyClientBehavior. DataSignatureEndpointBehavior adds the client formatter to every operation, by using the existing operation behavior:

public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)

{

foreach (OperationDescription operation in endpoint.Contract.Operations)

{

operation.Behaviors.Add(new DataSignatureOperationBehavior());

}

The endpoint behavior is exposed in the client configuration mode by extending BehaviorExtensionElement, so the DataSignatureFormatter can be added to every operation in an endpoint by configuring the DataSignatureEndpointBehavior:

<endpoint address="http://localhost/x.y.z.svc"

binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ICustomerService"

behaviorConfiguration="dataSignatureBehavior"

contract="CustomerService.ICustomerService" name="BasicHttpBinding_ICustomerService" />

</client>

</behavior>

</endpointBehaviors>

</behaviors>

<add

name="dataSignatureBehavior"

type="Sixeyed.OptimisticLockingSample.ServiceModel.Behaviors.DataSignatureEndpointBehavior…/>

</behaviorExtensions>

</extensions>

Service Side

The service stack is the parallel of the client side – DataSignatureDispatchFormatter is added via an operation behavior using DataSignatureOperationBehavior.ApplyDispatchBehavior:

public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)

{

DataSignatureDispatchFormatter formatter = new DataSignatureDispatchFormatter();

formatter.OrginalFormatter = dispatchOperation.Formatter;

dispatchOperation.Formatter = formatter;

}

Again this behavior is not available in the service configuration model, but it can be added to every operation in the service using IServiceBehavior.ApplyDispatchBehavior, as is done in DataSignatureServiceBehavior:

public void ApplyDispatchBehavior(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)

{

foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints)

{

foreach (OperationDescription operation in endpoint.Contract.Operations)

{

operation.Behaviors.Add(new DataSignatureOperationBehavior());

}

This behavior also extends BehaviorExtensionElement so it can be configured, adding the dispatch formatter will be added to every operation in the service:

<service behaviorConfiguration="dataSignatureBehavior"

name="Sixeyed.OptimisticLockingSample.Services.CustomerService">

<endpoint address="" binding="basicHttpBinding" contract="Sixeyed.OptimisticLockingSample.Services.ICustomerService"

bindingNamespace="http://Sixeyed.OptimisticLockingSample/2009"/>

</service>

</services>

</behavior>

</serviceBehaviors>

</behaviors>

<add

name="dataSignatureBehavior"

type="Sixeyed.OptimisticLockingSample.ServiceModel.Behaviors.DataSignatureServiceBehavior…/>

</behaviorExtensions>

</extensions>

Additionally, the DataSignatureOperationBehavior extends Attribute, so for finer-grained control the declarative approach is available using the same stack.

Accessing Extended Data from IExtensibleDataObject

EltonStoneman — Fri, 03 Apr 2009 23:51:08 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

DataContract classes in WCF can be declared as implementing IExtensibleDataObject to provide in-built support for schema versioning. Any data contracts created through svcutil or Add Service Reference implement the interface, and it's good practice to implement it for any custom DataContract classes you write. On deserializing, elements which are not declared in the data contract are extracted by the DataContractSerializer and added to the ExtensionDataObject property, so unexpected data is not lost (see Vagif Abilov's blog post on backwards compatibility with IExtensibleDataObject).

Internally, the ExtensionDataMember holds a convoluted key-value collection of the unrecognised data members. If you want to inspect the contents of the collection it's a fiddly process as the members are non-public, and the types and interfaces of the members (ExtensionDataMember and IDataNode) are also non-public. The code below allows you to extract the value of an ExtensionDataMember given its name:

private object GetExtensionDataMemberValue(IExtensibleDataObject extensibleObject, string dataMemberName)

{

object innerValue = null;

PropertyInfo membersProperty = typeof(ExtensionDataObject).GetProperty("Members", BindingFlags.NonPublic | BindingFlags.Instance);

IList members = (IList)membersProperty.GetValue(extensibleObject.ExtensionData, null);

foreach (object member in members)

{

PropertyInfo nameProperty = member.GetType().GetProperty("Name", BindingFlags.NonPublic | BindingFlags.Instance);

string name = (string) nameProperty.GetValue(member, null);

if (name == dataMemberName)

{

PropertyInfo valueProperty = member.GetType().GetProperty("Value", BindingFlags.NonPublic | BindingFlags.Instance);

object value = valueProperty.GetValue(member, null);

PropertyInfo innerValueProperty = value.GetType().GetProperty("Value", BindingFlags.Public | BindingFlags.Instance);

innerValue = innerValueProperty.GetValue(value, null);

break;

}

return innerValue;

}

Obviously this is fragile and isn't appropriate for production solutions, but it can be useful for unit testing or debugging WCF calls, or when you want to confirm the effects of having data contracts which are out of sync between the service and the consumer. Similar code could be used to get the count of extended data members to identify if the DataContract schema is not the correct version, and interestingly, the value and innerValue properties are writeable, so you could update the contents of the unrecognised members.

Verify Long-Running Tests with Retrying Asserts

EltonStoneman — Sat, 01 Nov 2008 01:47:31 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

There are a few situations when you're unit testing a component which calls out to another worker – a SQL insert from a separate thread, or a file drop from an asynchronous service call. You want to verify that the worker's completed correctly, but don't want to make the test run any longer than needed. Previously I've used bespoke code in tests where this was required, but the number has been increasingly recently so I've added a RetryAssert method to our fixture base class, for tests to use like this:

this.RetryAssert(1, 10, "File not found", new Assertion(delegate() { return File.Exists("c:\\temp.txt"); }));

RetryAssert takes an Assertion delegate (an anonymous one in this example) and repeatedly invokes it, pausing for the specified retry interval between calls, until the specified timeout is reached or the assertion returns true. At the first true assertion, the test is passed. If the assertion is false for every call until the timeout is reached, the test is failed.

The code is straightforward, but handy to have in your base class:

/// <summary>

/// Runs the given assertion repeatedly, until it returns true or the operation times out.

/// </summary>

/// <remarks>

/// If the assertion returns true at any point, the call issues passes the test; if the assertion

/// fails every point up to the timeout, the call issues Assert.Fail.

/// </remarks>

/// <param name="retryInterval">Interval between assertion calls, in seconds</param>

/// <param name="timeout">Tiemout before test is failed, in seconds</param>

/// <param name="failureMessage">Message to write if test fails</param>

/// <param name="assertion">Assertion delegate to run</param>

protected void RetryAssert(int retryInterval, int timeout, string failureMessage, Assertion assertion)

{

bool assert = false;

this.StartAssertTimer(timeout * 1000);

while (!assert && !this._assertTimeoutReached)

{

assert = assertion();

if (assert)

{

this.StopAssertTimer();

break;

}

else

{

Thread.Sleep(retryInterval * 1000);

}

Assert.IsTrue(assert, failureMessage);

}

protected delegate bool Assertion();

private bool _assertTimeoutReached;

private System.Timers.Timer _assertTimer;

private void StartAssertTimer(double timeoutMilliseconds)

{

this._assertTimeoutReached = false;

this._assertTimer = new System.Timers.Timer(timeoutMilliseconds);

this._assertTimer.Start();

this._assertTimer.Elapsed += new ElapsedEventHandler(assertTimer_Elapsed);

}

private void assertTimer_Elapsed(object sender, ElapsedEventArgs e)

{

this.StopAssertTimer();

this._assertTimeoutReached = true;

}

private void StopAssertTimer()

{

this._assertTimer.Stop();

this._assertTimer = null;

}

Note that this is a straightforward example and isn't threadsafe, but is fine for the majority of cases.

Creating Shortcuts in MSBuild

EltonStoneman — Sat, 25 Oct 2008 00:13:52 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Windows shortcuts are .LNK files – a proprietary binary format which is not simple to generate. If you want to create shortcuts as part of an MSBuild deployment, the main issue is that the paths are not relative, they need to be explicit, so you can't create your own shortcuts and copy them. Alternatives are to create .URL or batch files containing relative paths, but they don't have the niceties of shortcuts.

You can generate .LNK shortcuts in MSBuild by shelling out to some VBScript at runtime, when you've deployed your files and know the exact paths. It's not a pretty solution, but it's fast and reliable. Create a .VBS file with the following content to generate a shortcut from given parameters:

'CreateShortcut.vbs

'Generates a .LNK shortcut to the specified program

'Usage: CreateShortcut.vbs <pathToExe> <exeName> <shortcutName>

Dim args, arg

Set args = WScript.Arguments

Dim workingDirectory, exeName, shortcutName

workingDirectory=args(0)

exeName=args(1)

shortcutName=args(2)

Dim WshShell

Set WshShell = WScript.CreateObject("WScript.Shell")

Dim objLink

Set objLink = WshShell.CreateShortcut("Shortcuts\" & shortcutName & ".lnk")

objLink.Description = shortcutName

objLink.TargetPath = workingDirectory & "\" & exeName

objLink.WindowStyle = 1

objLink.WorkingDirectory = workingDirectory

objLink.Save

Then call it from MSBuild after you've deployed the target file and know the path:

Points to note:

If you have any spaces in the arguments (C:\Program Files\etc) you need to wrap them in triple double-quotes ("""C:\Program Files\etc"""), otherwise each word is parsed as a separate argument in VBScript;
The friendly name of the shortcut can end in any extension – Windows hides the final .LNK , so if you specify a .EXE it will display as an EXE;
Shortcuts aren't limited to executables, if you pass a Word file as the exeName argument and end the shortcutName with .DOC, it'll launch the document in Word and show it with the Word icon in Explorer;
You have a lot of control over the link from the CreateShortcut call – including the startup window type, arguments and the icon. The example above is a straightforward one which just sets the minimum necessary.