The application runs in a call center. Assume there are 100 users and 100 computers. Any user can use any machine on a given day. Assuming everyone uses a different machine each day for 100 days then each day they will have to install the application on the machine they are using and by the 100th day each machine will have 100 installations of the app. Clearly not a desirable situation.

How do we go about solving this ?

The quick answer is that you cannot solve it using ClickOnce in a straightforward manner. The reason ? ClickOnce installations are always per user. It is by design and not a side effect or even a configurable option. When you install a ClickOnce application it goes into C:\Users\<User>\AppData\Local\Apps\2.0\<Blah>. Here <Blah> is a set of folders with names that doesn’t make much sense. For example, here is an actual example of the full path to a ClickOnce installation – C:\Users\<User>\AppData\Local\Apps\2.0\8Y7PD2RC.9VE\L1OL139M.4W2. These names would be different on different machines. This makes it very hard to find the location of the installation, so we cannot share the installation between users (assuming that other users have access to this folder). Other users would not get desktop shortcuts and Start->Programs shortcuts. Also AppData is a hidden folder which makes it even harder to find for non-technical users.

So what do we do ?

For the specific scenario here, ClickOnce does not fit the bill as the deployment strategy. MSI is a better choice. XCopy might also work depending on the application requirements.

It has been a long time since I got excited about a programming book as much as I did with Programming F#. I have all the books on F# available in the market today. But I should say that this is the best book for learning F# if you have no experience with functional programming. I am not sure how this book would be for a person who is totally new to programming (chances are they would find this ahead of their curve). But for a person who has good experience with imperative programming this book would get you up and running with F# in specific and functional programming in general.

The book by Don Syme Expert F# (Expert’s Voice in .Net) (who invented F#) is also good but not as good as Programming F# for new functional programmers. But once you have read this book, Don Syme’s book might be a good follow up.

The strongest point of this book is the clarity with which concepts are explained and the choice of good examples to explain a concept. They are concise and to the point. It also made the book surprisingly small (at a little less than 400 pages). But no worries, everything that you need to get a firm footing in F# is in here.

This is truly a 5 star book. Highly recommended.

The table of contents:
Part I. Multiparadigm Programming

Chapter 1. Introduction to F#
Chapter 2. Fundamentals
Chapter 3. Functional Programming
Chapter 4. Imperative Programming
Chapter 5. Object-Oriented Programming
Chapter 6. .NET Programming
Chapter 7. Applied Functional Programming
Chapter 8. Applied Object-Oriented Programming

Part II. Programming F#

Chapter 9. Scripting
Chapter 10. Computation Expressions
Chapter 11. Asynchronous and Parallel Programming
Chapter 12. Reflection
Chapter 13. Quotations
Appendix A. Overview of .NET Libraries
Appendix B. F# Interop

F# Syntax

F# has two syntax forms available – a lightweight syntax and a verbose syntax. The lightweight syntax uses indentation to mark the beginning and end of code blocks. This naturally results in more concise code. The verbose syntax uses additional keywords to demarcate code blocks making the code lengthier than it needs to be but it makes the code less sensitive to indentation (imagine copy-pasting and sending code in email etc).

The lightweight syntax is on by default. You can explicitly set it to on by using

#light

The verbose syntax is always on which means you can still use the verbose keywords even if the lightweight syntax is on.  We can enforce the verbose syntax by switching off the lightweight syntax as follows

#light “off”

The lightweight syntax is in more prominent use than the verbose syntax and it seems that going forward the verbose syntax might be obsolete.

Only spaces can be used for indentation in F#, TABs are not accepted. Visual Studio by default converts TABs to spaces. This can be set in Tools –> Options dialog under Text Editor –> F# –> Tabs.

Tail Recursion

I had mentioned about recursive functions in my previous post on Functions in F# but I did not mention anything about tail recursion. Given the importance of recursion in F#, this is a very important topic and I want to thank Binil for bringing it to my notice.

First, let me provide some background info on what is bad about recursive functions and why tail recursion is the preferred way to write recursive functions.

When is function needs to be executed, a block of memory is allocated on the system stack for the function and is called a stack frame. When the function completes execution, this memory is reclaimed and is called unwinding the stack.

Recursive functions call themselves repeatedly until an exit condition is met. This means that a new stack frame has to be created each time the recursive call is made. Given enough nested function calls there wouldn’t be any more space on the system stack and would cause an undesirable condition called stack overflow. The program execution is terminated forcefully by the runtime.

If the function calls are not recursive, for example calling a function 1000 times in a for loop, the memory block for a function can be reclaimed when the function execution is over. So what we need to try to achieve is to write the function in such a way that the stack frame of the calling function need not be maintained while execution proceeds to the next function call. The way to do this is to make the recursive call as the last statement in the function. When we do that the compiler produces different code which allows the stack frame of the calling function to be unwound and the memory reclaimed, in effect making it similar to calling the function in a loop. This technique is called tail recursion.

Let us look at some code to make this more clear. Here is the recursive implementation of factorial that I wrote in my previous blog post.

let rec factorial x=
    if x <= 1 then
        1
    else
        x * factorial (x-1)

Here it might look as if the recursive call is the last statement in the function, but it is not. It would become clear if we wrote it this way:

let rec factorial x=
    if x <= 1 then
        1
    else
        let product = x * factorial (x-1)
        product

Now it becomes clear that the last statement in the function is returning the value of product. We also see that the function has to maintain the value of x in its stack frame and multiply it with the value returned by the recursive call. So if the function is written as shown above, there is no way to reclaim the stack memory until the chain of recursive calls return. So let us re-write the function in using tail recursion.

let factorial x =
    let rec tailRecFactorial x prod =
        if x <= 1 then
            prod
        else
            tailRecFactorial (x-1) (prod * x)
    tailRecFactorial x 1

Here we have a nested function which takes the product up to the current stage as a parameter which means nothing needs to be stored on the stack of the calling function. The stack frame can be safely reclaimed. The compiler is able to spot the tail recursive calls and generates code as if the function was called in a loop. Execution returns the original calling point when the exit condition is met.

The method I showed above to achieve tail recursion is called accumulator pattern. Another way is to use Continuations.

Trivia

When I was writing the non tail recursive factorial function, by mistake I wrote it this way:

let rec factorial x =
    if x <= 1 then
        1
    else
    x * (factorial x-1)

Can you spot the problem ?

Hint: It causes a StackOverflowException when executed.

• Learning F# and
• Reducing my weight.

I have been trying to learn F# for over a year now (maybe even a little more). I have all the F# books in print now as well as the PDF for the upcoming Manning MEAP – Functional Programming for the Real World. But they been collecting dust on my shelf. Functional programming requires a new mindset and hence requires a little more effort for me than studying a new imperative language. The first book that I bought is Expert F# which is definitely the wrong book for a beginner. It is written by Don Syme et.al. who is the primary designer of the language and is a little dense. It is a good book with a lot of information but it is just not good for somebody new to functional programming. Once you have grasped the main ideas behind functional programming, it is a good book to have. The second edition of this book is coming up soon.

The game changer for me was Programming F# by Chris Smith which, IMHO, is the best book out there today to learn F#. It is a surprisingly small book and is written with such clarity that even somebody with absolutely no exposure to functional programming languages would be able to learn from it. It makes the ideas accessible and has some brilliant examples to showcase some of the features of F#. It kind of feels like an easy-going friend, which is exactly what you need when exploring unfamiliar grounds. I was so impressed with the book that I wrote a review of the book on Amazon giving it 5 stars.

I am not entirely comfortable with F# yet. But I have my feet wet and I plan to make the plunge in 2010.

Another thing that I want to tackle in 2010 is my weight (and fat). I am 190 lbs now. I used to be something like 175 lbs 3 years ago when I came to USA. 15 lbs in 3 years ! I am definitely worried about this. So is my wife. I had taken diets a couple of times previously and had always managed to reduce weight. But it always came back with a vengeance. So I am not sure whether another diet is the solution. Being on a diet is one of the most worst experiences that I have been through. Food is always on your mind and you can’t eat it. You are constantly fighting the sugar craving (I was on a low-carb diet). It is hell.

Although I haven’t made any specific plans, I think I would concentrate more on exercise and less on diet this time. Let us see how it goes.

Happy Holidays !

…functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions…

The point I wish to make here is that functions are the  most important “things” in a functional programming language. You can say that functions are “first class citizens” in a functional programming language. This means that functions can be passed around as parameters and return values of other functions, just like any other data. Functions which can take other functions as parameters and/or return values are called Higher-Order Functions.

Functions and Type Inference

Here is an example of a simple function in F#.

let triple x = 3 * x

Here triple is the name of the function and x is the name of the parameter passed to the function. Contrary to C# naming convention for function, F# uses camel casing. Even though we have not specified any type information, the compiler is able to infer that this function takes an integer as parameter and returns an integer. This is called Type Inference and makes your F# program more concise.

How did I know that the compiler inferred the parameter and return value as int? I typed in the above functional declaration in F# interactive and terminated it with ;; and hit Enter. F# showed me:

val triple : int –> int

This means that triple is a function which takes an integer as parameter and returns an integer. If we try to call the function with a float as parameter

triple 3.0

it will spit out an error message as follows.

stdin(4,8): error FS0001: This expression was expected to have type
    int   
but here has type
    float   

We know that * (multiplication operator) works with floats as well, so why this error ? The reason for this is that in the absence of any additional type information the compiler simply defaulted the type to integer. So triple is a function which can take an integer as parameter and return an integer which is equal to three times its input. It is equivalent to the following C# function.

static int Triple(int x)
{
      return 3 * x;
}

Since the function expects integer, a parameter of type float will produce an error.

So what do we do when we need a datatype other than the default type that the compiler is able to infer? We give a hint to the compiler via type annotation.

let triple (x: float) = 3.0f * x

Note: In the above example type annotation is not strictly required because the compiler would infer x as float because 3.0f is float. But it does show you how to annotate a function parameter with its type.

Higher Order Functions

The functions mentioned above are not a higher-order functions because they do not take a function as parameter, neither do they return one. List.map and List.filter are examples of higher order functions. List.map takes a function and applies it to each item in the list (also passed as parameter to it) and returns a new list with the output values. List.filter takes a function and list as parameters and returns a new list. The output list contains those values from the input list for which the input function returned true. An example is shown below which makes use of both these higher order functions.

let triple x =
    3 * x

let isEven x =
    x % 2 = 0

let actOnEven action numbers=
    List.map action (List.filter isEven numbers)

[<EntryPoint>]
let main(args:string[]) =
    let results = (actOnEven triple [1 .. 10])
    Console.WriteLine (results)
    0

Here actOnEven is itself a higher order function.

Recursive Functions

Recursive functions are functions that call themselves. An important tenet of functional programming is the use of recursion instead of looping. We can create recursive functions using the following syntax.

let rec factorial num =
    if( num <= 1) then
        1
    else
        num * factorial (num - 1)

The rec keyword is a helping hand to the compiler for type inference. Personally, I don’t like it but I think they couldn’t find a way around it.

Function Currying

Currying (named after Haskell Brooks Curry) is an interesting technique in which you pass one of the arguments to a function and it returns another function which takes the rest of the arguments. For eg., consider the function

let add x y = x + y

If you run this in F# interactive, you will see the following message:

val add : int -> int –> int

This means that add is a function which takes an integer and returns a function which takes another integer as parameter and returns an integer. So if we call add with just one parameter, it will return another function which takes the second parameter.

let addToTwo = (add 2)

To be clear, addToTwo is a function that takes one integer parameter and returns an integer.

For eg,

addToTwo 8

will return 10.

Here addToTwo is the curried function and this technique is called function currying. Although this may look like a strange and useless language feature, it has interesting and powerful applications in functional programming (like the pipe forward operator). I will write more about this in future blog posts.

Nested Functions

In F#, a function can contain another function. Here is a simple example.

let printList numbers=
    let print num=
        printfn "%i" num
    List.map print numbers

Here print is a function nested in printList.

Some of the feature that I have mentioned here would be new to C# programmers and might feel a little strange. But have hope, for all will become more clear with time. We need to see some solid examples to appreciate the power of some of them. I have mostly presented useless examples but I hope a reader would have gleaned atleast a little information about functions and its usage in F# from this post. There is more to write but it is getting late (3 am) and tomorrow is a working day, so I gotta go. Will be back with more on F#.

References:

Programming F#

Expert F#

Some time in the recent past I stumbled on Live Writer. It was quite nifty and did a pretty good job with identifying your blog engine and templates and previewing your post. But when you copy pasted code from Visual Studio, it was not so pretty. Thankfully Douglas Stockwell had written a plugin for Live Writer to paste your code from Visual Studio. Together they did an amazing job in formatting source code as you can see below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
using System.Security.Principal;
using System.ServiceModel;

namespace WindowsFormsApplication1
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Form1());
        }
    }
}

Happy blogging.

As I mentioned in a previous post, one of solutions for the access denied issue was to pre-load the assemblies in the Global.asax Application_Start event handler. For preloading a specific assembly (lets call it foo.dll) I did something like this:

MyNamespace.MyClass.Equals(null, null);

Things worked fine in the debug build, but in the release build we were getting Access denied for the foo.dll assembly. It was a little weird because all the other assemblies were getting loaded as network service and they all succeeded. Foo.dll was getting loaded under the identity of the user and was failing. I decompiled the foo.dll using Reflector (can’t say how many times this nifty little tool saved the day) and found that the code was optimized by the compiler to this:

object.Equals(null, null);

It does make sense. In hindsight.

We tested the solution in debug build where there was no optimization and everything worked as expected.

So my advice is – if you are deploying the release build of an application, you should be testing the release build of the application.

P.S. – There was an interesting discussion in the MSDN forums a couple of years ago which displayed a similar problem. I will blog about it later, for a little while it got me real frightened about my understanding of the .net platform.

Could not load file or assembly ‘MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. Access is denied.

This was very frustrating to say the least. The first thing to do was search the internet with the error message and sure enough, several other people had faced the same issue but nobody had a good solution for the problem. The problem was that the code was running under the identity of the user (because we were using impersonation) and when the assemblies were shadow copied to the “Temporary ASP.NET Files” directory (C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files), the user did not have write permissions to that directory and hence the Access denied error.

Note: I should say that the Fusion Log Viewer was extremely helpful in identifying the problem and helping to make sure that the problem was resolved.

The obvious solution is to give users write permission to that folder. The testing team decided that this could a potential security issue (even though this was an internal application and permissions were given only to authenticated users). So we began hunting for other solutions and came up with more solutions.

• Run aspnet_regiis –ga “authenticated users”.

This seemed to fix the problem, but it turned out that it was just a variation of granting authenticated users permission to the Temporary ASP.NET Files folder. What this command does is add the user/user-group to the IIS_USRS groups which is already set to have modify permissions on the Temporary ASP.NET Files folder. It works, but we are back to square one.

• Disable Shadow copying of assemblies

As I mentioned earlier, the problem was occurring while shadow copying the assemblies to the temp location. The primary purpose of shadow copying is to do dynamic compilation and hot-swapping files. Dynamic compilation does not apply to WCF as much as for ASP.NET. Also we were not very concerned about the hot-swapping of files, so this was a credible option for us. But what concerned us was that we couldn’t find any info about any other side effects of disabling shadow copying. To disable shadow copy, add the following in your web.config inside the configuration section.

<system.web>
    <hostingEnvironment shadowCopyBinAssemblies="false"/>
</system.web>

The good thing about this option is that it does not require a code change and is easy to revert and also there doesn’t appear to be any security issues.

• Move impersonation to the end of the call stack

Since the problem occurs because the assembly loading happens in the identity of the user, we could do away with declarative impersonation and do an imperative style impersonation where impersonation is done only when making calls to the backend system. To make it more clear, we were doing impersonation like:

[OperationBehavior(Impersonation = ImpersonationOption.Required)]
public Response DoSomething(Request request)
{
        return request.Execute();
}

Instead we could do impersonation only while calling the backend code:

WindowsIdentity callerWindowsIdentity = ServiceSecurityContext.Current.WindowsIdentity;
if (callerWindowsIdentity == null)
{
    throw new InvalidOperationException("The caller cannot be mapped to a WindowsIdentity");
}

using (callerWindowsIdentity.Impersonate())
{
    // Make backend calls
} 

This is definitely a good solution, but has atleast two drawbacks. The first problem (not a big one) is that it requires a code change. The second problem is a performance one and happens only if the backend calls are webservice calls. The reason for this is that the webservice calls usually require a XmlSerializers dll which is generated by Visual Studio and usually deployed along with the application. If this assembly is not present, the runtime will create one dynamically. This can cause a perf hit. Since we do impersonation before making the backend call, the XmlSerializer assembly is loaded in the identity of the user and will fail. But the CLR, failing to bind the assembly, will synthesize one for you thus causing a perf hit.

If your backend calls are not webservice calls, then this is a reasonable workaround for you.

• Pre-load the assemblies

What we understood from the Fusion Logs was that the assembly loading was happening under the identity of the end user who does not have adequate permissions. So one thing we can do is to pre-load the assemblies when the service is running as the network service account. To do this, we created a Global.asax file and in the Application_Start event handler, we refer to types in all the assemblies of the service, thus forcing them to be loaded even before the first request is processed. The code looks something like this:

namespace MyService
{
    public class Global : System.Web.HttpApplication
    {

        protected void Application_Start(object sender, EventArgs e)
        {
            //Make sure all the dlls are loaded
            Action action = new Action(null);

            EntityOperations.EntityOperationsFactory.CreateOperation();

            DataAccess.DaoFactory.CreateDao(); 

            WebServiceLibrary.WebServiceGateway.Initialize(null);
        }

     }

}

Using the Fusion Logs we were able to see that the assemblies were getting loaded under the identity of the network service account. We could also see that the XmlSerializers were also getting loaded correctly.

This solution might feel a little icky because of its unconventional nature but I think it is a brilliant solution and it seems to work correctly. We have decided to adopt this solution for our project.

• Change the shadow copy directory to a directory inside the website directory

Frankly I never tried this one out and don’t know if it works, but it is worth some investigation if none of the solutions outlined above works for you.

I will make a follow up post or edit this one, if I find problems with the solutions mentioned here or if I find better solutions.

We had to move from ClickOnce to MSI (for reasons bizarre) and we chose Wix (it was easy considering the fact that there was only one option to chose from).

While Wix doesn’t help much in easing the pain (and in some ways it makes things worse), it sure does help in automating the creation of your MSI. While I would like to see a much simpler, automate-able solution for creating MSIs, if you need to do something today Wix is the way to go. Wix is a little complex and unintuitive to use (maybe because of the nature of the underlying technology – MSI). Whatever the reason, I found that creating shortcuts is not as straight forward as one would expect it to be. I would expect to set some attribute to true (like in ClickOnce) and be done with it, but it was not so. Hence this blog post.

The following steps are for creating desktop shortcuts, it differs for creating shortcuts in the Start->Programs list.

First, you need to add the following line

<Directory Id="DesktopFolder" Name="Desktop"/>

Then add a shortcut node under the File node corresponding to the file for which you want the shortcut.

<File Id="StartupExecutable" Name="$(var.StartupExecutable.TargetFileName)" Source="$(var.StartupExecutable.TargetPath)" DiskId="1" KeyPath="yes">
               <Shortcut Advertise="yes"
                         Id="MyProductDesktopShortcut"
                         Directory="DesktopFolder"
                         Name="Name of desktop shortcut"
                         WorkingDirectory="INSTALLLOCATION"
                         Description="Some description"
                         Icon="Icon.exe">
                 <Icon Id="Icon.exe" SourceFile="$(var.StartupExecutable.TargetPath)" />
               </Shortcut>
             </File>

To give a perspective, the whole thing should look like this:

<Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="DesktopFolder" Name="Desktop"/>
      <Directory Id="ProgramMenuFolder">
        <Directory Id="ApplicationProgramsFolder" Name="My Company Name"/>
      </Directory>
      <Directory Id="ProgramFilesFolder">
        <Directory Id="MyCompanyFolder" Name="My Company Name">
          <Directory Id="INSTALLLOCATION" Name="My Product Name">
            <Component Id="MyComponent" Guid="1c4ba634-0428-4bcd-ad46-c7cf232e007b">
              <!-- Add our project output dll's -->
              <File Id="StartupExecutable" Name="$(var.StartupExecutable.TargetFileName)" Source="$(var.StartupExecutable.TargetPath)" DiskId="1" KeyPath="yes">
                <Shortcut Advertise="yes"
                          Id="MyProductDesktopShortcut"
                          Directory="DesktopFolder"
                          Name="Name of desktop shortcut"
                          WorkingDirectory="INSTALLLOCATION"
                          Description="Some description"
                          Icon="Icon.exe">
                  <Icon Id="Icon.exe" SourceFile="$(var.StartupExecutable.TargetPath)" />
                </Shortcut>
              </File> 
              <!—Rest of your project assemblies –>
              <File Id="MiddleTier" Name="$(var.MiddleTier.TargetFileName)" Source="$(var.MiddleTier.TargetPath)" DiskId="1" />
              <File Id="Backend" Name="$(var.Backend.TargetFileName)" Source="$(var.Backend.TargetPath)" DiskId="1" />

        </Component>
</Directory>

I hope this was helpful for you fellow journeyman.