It can be useful when mocking a function with Moq to use parameters passed into the Setup of a mocked function in the Returns function.

I created a unit test to illustrate the basic idea:

  
[TestFixture]
public class TestFixture1
{
   public interface ITest
   {
      int Func(int x, int y);
   }

   [Test]
   public void Test()
   {
      Mock<ITest> mockTest = new Mock<ITest>(MockBehavior.Strict);

      mockTest.Setup(x => x.Func(It.IsAny<int>(), It.IsAny<int>()))
         .Returns((int x, int y) => { return FuncData(x, y); });

      ITest test = mockTest.Object;

      Assert.AreEqual(5, test.Func(2, 3));
      Assert.AreEqual(3, test.Func(1, 2));
   }

   private int FuncData(int x, int y)
   {
      return x + y;
   }
}

The main idea is to use a lambda expression in the Returns function that specifies the arguments that can be used in whatever way is needed.

I created a short screen cast to demo how this works:

I hope this helps! Code on

There is no clear cut mechanism provided by the ASP.NET MVC framework to pass data from a view to it’s master page. I’ve been using a technique that I’m reasonably happy with, which I’ll describe in this blog post.

For starters, my example will be using the ITypeInstanceDictionary provided in the TTC Tools. Please read my blog post pass data from an ASP.NET MVC controller to view to learn more. The code shown in this blog post is included in a demo web application on the TTC Tools GitHub page.

There are many scenarios in which you want to drive master page values from the view. For example: some CSS styling that exists in the master page will be dependent on the view. Personally I feel this should not be driven by the controller, as there are many situations in which CSS styles are purely display driven.

I’ll summarize the basic concepts for passing data from the view to it’s master page.

• Create an interface that is used by the master page for use in the master page markup code, and allow the view to override these values.
• Setup the master page view data at the top of the master page
• Follow up the master page code with a content place holder.
• This content place holder will be used by the view to override any master page data values.

My example code will show how to override the pages body element id in the master page from a view.

The following code snippet shows an example master page implementation:

The view can override master page view data by creating a content control for the master page’s content place holder which follows the setup of the master page’s view data.

The ASP.NET MVC view engine rendering execution flow will start at the top of the master page and then flow into the content place holders. This allows the view to override the master page view data before it is used later in the master page markup code.

I created a screen cast which might help explain this technique in a bit more detail.

If you need any further explanation or have any questions please let me know. I hope someone finds this useful

The default mechanism for passing data from an ASP.NET MVC controller to the view is to use the ViewData property of the controller and view which is of type ViewDataDictionary. The ViewDataDictionary is a string indexed collection of type object. My main issue with this mechanism is two fold. I’m not a big fan of string indexed collections and I don’t want to have to cast to get at the type of the class instance in the collection.

The next option is to use the Model property of the ViewDataDictionary. The Model property of ViewData allows a strongly typed way to pass data from the controller to the view. The question becomes what type should be used? One choice is to use a specific type for each controller action and view, but this gets a bit cumbersome. Instead I propose using a collection indexed by type which is assigned to the Model property of ViewData.

I created a project called TTC Tools which houses the ITypeInstanceDictionary, which provides a generic mechanism to pass various types from controller to view in a more strongly typed way than the ViewDataDictionary.

I documented some basic usage scenarios for the type instance dictionary on my wiki. I also created a screen cast to document basic usage in an ASP.NET MVC application.

The basic idea is the dictionary provides the template functions Add<T>, Get<T>, and Contains<T>. The type T is used as the indexer of the dictionary, so instances of various types can be added and retrieved from the dictionary.

A very basic usage scenario from a unit test is illustrated as follows:

The type does not have to be specified for the Add call, as the declared type of the parameter will be used. The Get call must declare the type, as the type T is used for the dictionary index.

The type instance dictionary does allow multiple instances of the same type to be added, but only if some other type of instance identifier is supplied. For example an enumeration can be used to differentiate the types. An example of adding and retrieving multiple instances of the same type using an enumerated type for the instance id follows:

Basic use in an ASP.NET MVC application

For convenience, derive all your controllers from a base controller that provides a  property of type ITypeInstanceDictionary. My example uses a property named TypeViewData.  The code for the base controller follows:

   public class BaseController : Controller
   {
      ITypeInstanceDictionary _typeViewData = new TypeInstanceDictionary();

      public ITypeInstanceDictionary TypeViewData
      {
         get
         {
            return _typeViewData;
         }
         set
         {
            _typeViewData = value;
         }
      }
   }

Controller actions that return a ViewResult should use the controller View function overload which accepts the model argument. The TypeViewData property should be passed into the view function as follows:

The view should then use the template version of the ViewPage class, with the type set to TTC.Tools.ITypeInstanceDictionary. The template version of the ViewPage class strongly types the Model property of the View.  The Model property can then use the Get<T> function to retrieve the data sent from the controller. An example of the view code follows:

You can find the code, which includes a sample web site using the type instance dictionary, at the TTC Tools GitHub page. I’ve also created some basic documentation on my wiki.

If you have any questions please let me know!  I’m not sure if others will find this useful, but you never know

I was trying to create a strong name for an assembly in Visual Studio from the project properties using the dialog:

After clicking OK I received the following error message: The operation could not be completed. Access is denied.

I then tried from the command prompt using sn.exe and received the same type of message: Failed to generate a strong name key pair -- Access is denied.

I found the following blog post Create Strong Name Key - Access Denied Error, but it applies to Windows XP. I searched around for a RSA\MachineKeys folder and found three different locations but it seems the folder C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys is the magic place.

I gave my user the following permissions on the MachineKeys folder and then I was able to sign my assembly

When I changed the permissions on the folder it complained I could not change permissions on the files in the folder, so I cancelled out of the application of the file permissions. It looks like I’d have to take ownership of the existing files in order to change their permissions which I decided not to do at this point.

I hope this helps