In general, exceptions should be bubbled up to the highest possible level to be caught and processed.  For example, in our project, a search goes through the following logical tiers:

UI -> Services -> Data/SharePoint/Refinement -> Web Services

There are quite a few instances where we’re catching exceptions in the Data or Services layer, logging them using common logging components or configurations, and then swallowing the exception one way or another.

This is a bad practice for few reasons:

• This behavior is not transparent to developers that may be using the DLL but do not have access to the source code.
• Logging from lower tier components is generally a bad idea, as it either requires a static logging location embedded in the dll or creates a dependency on the UI to provide pre-determined logging mechanism (i.e. EntLib).   (This can get especially ugly with EntLib, and EntLib Logging and ExceptionHandling blocks generally use named “policies” for handling and logging exceptions, and referencing them from a middle-tier component requires any UI consuming it to implement the exact same logging configuration.
• Applications consuming the DLL do not know about or are not given the ability to choose how to react to exceptions in the code.
• Swallowing exceptions dilutes the effectiveness of unit tests testing these functions, as tests can’t explicitly test for scenarios that might cause specific exceptions,
• Swallowing exceptions can make debugging issues a nightmare (if not impossible) for developers that might consume this middle-tier component and not have access to the source code.
• Catch blocks have an inherent performance cost.  Catching exceptions unnecessarily results in unnecessary performance degredataion.

There are a few legitimate cases where this best practice might not be followed:

1. The Exception contains potentially sensitive information

If the exception or exception message contains potentially sensitive information such as user credentials, server names, or any other sensitive information, it likely makes sense to catch the exception, create an exception that accurately describes the issue without the sensitive information, then throw that exception.  Note however, there are very few scenarios where this should not occur at the UI layer.

2. The exception is too vague or needs more metadata to be meaningful to the code consuming it.

If the exception by itself is too vague or requires rebadging or augmented metadata to be useful to the code consuming it, it generally makes sense to wrap the exception by creating an exception that allows the original exception to be set as an “InnerException”, and augments the original exception with more information.  This new exception should then be thrown.

3. The exception that was caught should not affect the execution of the code

If an exception occurs that should not affect the execution of the code, it may be swallowed or ignored in limited cases.  However, exceptions really should not be being thrown unless there is a severe enough issue to potentially interrupt program execution, so I’d suggest reviewing the code throwing the exception you are swallowing in this case.

4. The Exception Occurs At A Physical Tier Boundary

Your multi-tier applications may not only contain multiple logical tiers, but physical tiers as well.  (for example, your web application may rely on a web service layer on a separate physical server).  While your web service layer may be “middle-tier” as far as the overall application is concerned, exceptions should be caught, processed, and logged at the boundary to that physical tier.  Logging on the machine where the services resides aides in issue resolution, and it gives an opportunity to review exceptions for sensitive information before sending them over the network, where they may be intercepted.

Practice #2: You Should (Almost Never) Catch System.Exception

You should almost never write the following:

This code says that you don’t know what type of exception to expect, so catch them all.

Any exception that the code is not expecting is, by definition, an unexpected or unhandled exception.  You probably want your application to crash (or gracefully exit) with an “Unhandled Exception” message if an unexpected exception occurs! How can you be certain of the stability of the currently running instance of your code if an exception occurred somewhere that you didn’t expect?

Also, catching specific exceptions helps greatly in diagnosing issues, and displaying useful and meaningful error messages to your users.  I think we all know how frustrating a generic error message such as “An error occurred.” can be.

If you think an exception might occur but you don’t know the type, either determine the type and catch it or don’t implement a handler at all!   If you need to throw an exception and there’s not an exception type available that is specific to the error that occurred, create a new one.

Practice #3: Always Null-Check Objects Returned from a Function Call

Review the 5 lines of code below.

What’s wrong with this picture?

If you said Null Reference Exception you’re right.  Never, ever access any member of any object that has been returned from a function without checking for null.  You should never assume that a function will return an instantiated object.

Never.

Even if you wrote the function you’re calling.

We all work on projects with multiple developers, and at any given time another developer (or even you) may alter the code and end up returning a null object without realizing that there is some expectation that an instantiated object be returned by some callers.

Taking the extra time to type 15-20 extra characters can mean the difference between stable software and buggy, error-prone code.

Conclusion

I wrote this as an e-mail to my team after doing some refactoring and realized that it could be beneficial to a wider audience being that violations of these practices are so common.  I’ve made these mistakes (as I’m sure many of us have) numerous times in the past, so writing this up was a good reminder for me to focus on these points when writing code.

Please feel free to post additions, corrections, questions, and concerns in the comments section below!  The dialogue will benefit all involved!

In Part 3 we will look at how to utilize Ninject’s features within our application, along with what kind of functionality can be delivered. At this point, let’s revisit our goals from Part #1:

1. dynamically set which service object(s) we are using to perform our application logic
2. dynamically set which view we are returning
3. dynamically set which partial views we are using

Hypothetically, let our application be a standard transactional system, with header records at the top level and child records below it. Furthermore, let it be an order entry system, so we will need to know about quantities, prices, have subtotals, etc. Our standard interface can be for Work Orders, and look something like the following:

WorkOrders.aspx:

We have some header information (Work Order #, etc.) and child records, and the ability to interact with the application to modify child records and add new ones. At this point, a large customer likes what you’ve done so far and wants to use your application to manage their shop. But instead of work orders, they need to use Purchase Orders. You need to make some major modifications without affecting your existing functionality, so you create a new page and use Ninject to inject the right functionality into the application. Because we implemented Goal #2 in Part 2, we merely need to modify our source repository to provide the PurchaseOrders.aspx page instead of WorkOrders.aspx.

From CompanyConfigProvider.cs:

                // construct our list of Views to be used throughout the application
                // for Goals #2 and #3
                foreach (KeyValuePair<string, string> item in r.getViews())
                {
                    cc.Views.Add(item.Key, item.Value);
                }

In addition, because these Purchase Orders are between your client and their own customers and not intra-company Work Orders, there are potential tax implications — as such, you will need to introduce a method of keeping track of tax when necessary. It will utilize the existing Purchase Orders functionality, but will need to augment it — the perfect usage of partial views.

TotalNoTax.ascx:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<p>Non-Profit Tax Code: <input type="text" name="taxinfo" /></p>

TotalWithTax.ascx:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<p>Tax Amount: <input type="text" id="taxinfo" name="taxinfo" /></p>
<script type="text/javascript">
    function updateTax() {
        var qty = parseFloat($("#quantity").val());
        $("#taxinfo").val(qty * 150 * .06);
    }

    $(document).ready(function() {
        $("#quantity").blur(updateTax);
        $("#itemType").change(updateTax);
    });
</script>

Very simply, we will use jQuery to manage a new form element that will include tax when necessary. Let’s start putting it all together. First, let’s take a look at our controller:

From OrdersController.cs:

using {etc}

namespace MultiTenantNinject.Controllers
{
    [HandleError]
    [ProvideCompanyConfig]
    public class OrdersController : Controller
    {

As you can see, we inherit from Controller like normal and utilize our ProvideCompanyConfig attribute so that we can be assured we have access to our company config upon rendering. Let’s take a look at an Action:

        public ActionResult Index()
        {
            ViewResult v = View(_companyConfig.Views["Order Management"]);

			// add view data items for the header and children;

			// add item to be used for determining if it's a taxable or non-taxable transaction:
			v.ViewData.add("taxState",repository.TaxState);

            return v;

        }

The first step in rendering the View to the user is ensuring we have an “Order Management” entry in our Views collection that establishes what type of major functionality to use. Our repository would load the config file with a text entry like “WorkOrders” or “PurchaseOrders” to correspond with “WorkOrders.aspx” or “PurchaseOrders.aspx”, respectively. We can set our ViewData at this point, perhaps using a service object (which we will explore soon) and then return the view. At this point, we have a solid understanding of achieving Goal #2, so let’s take a look at the few lines necessary to achieve Goal #3:

From PurchaseOrders.aspx:

    <% var configSettings = (MultiTenantNinject.Models.ICompanyConfig)ViewData["companyConfigSettings"];  %>
	<h3>Purchase Orders</h3>
	... etc ...
    <p><% Html.RenderPartial(configSettings.Views[string.Format("Taxes_{0}",ViewData["taxState"])]); %>

By utilzing the correct entry in our repository for the user’s state, we can provide the correct tax functionality. If the company’s location was in Florida, the repository could provide “TotalWithTax” for the “Taxes_FL” binding, and “TotalNoTax” for the other states. Obviously we can take it up a level of abstraction and determine whether or not this transaction is taxable in the controller or service object, but this serves as an adequate example of Goal #3. Lastly, let’s take a look at our solution for Goal #1 — it’s all well and good when we can provide custom front-end functionality for our users, but at some point we will need to implement logic and manipulate data. Let’s revisit the module where we inject our services:

From OrderModule.cs:

        public override void Load()
        {
            // use reflection to bind a list of types (from our Config's "Bindings" collection)
            // to be used when called upon during injection
            string serviceLocationPrefix = "MultiTenantNinject.Services.";
            foreach (KeyValuePair<string,string> item in _config.Bindings)
            {
                Bind(Type.GetType(serviceLocationPrefix + item.Key)).To(Type.GetType(serviceLocationPrefix + item.Value));
            }
        }

We will need to provide an interface and an implementation for our service(s). Firstly, the interface:

IOrderService.cs:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using System.Web.Mvc;

namespace MultiTenantNinject.Services
{
    public interface IOrderService
    {
        string Process(ViewDataDictionary viewdata);
        DataTable Orders { get; set; }
    }
}

and one of the implementations:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data;
using System.Web.Mvc;

namespace MultiTenantNinject.Services
{
    public class VideoCardOrderService: IOrderService
    {

        #region IService Members

        public string Process(ViewDataDictionary viewdata)
        {
            // here we do transactions pertaining to video cards
            return "Thanks for buying a video card!";
        }

        #region Orders
        private DataTable _Orders;
        public DataTable Orders
        {
            get
            {
                return _Orders;
            }
            set
            {
                if (_Orders == value) return;
                _Orders = value;
            }
        }
        #endregion

        #endregion

    }
}

Service objects can perform most of the functionality of your application, and do not need to be gone over in great detail, as they are as varied as anything else can be. Suffice it to say that it’s a standard interface/implementation pattern of development. Ninject allows you to set it up for injection, as we did in Part 2, so that whenever you call a particular interface for this user a particular implementation is used. “VideoCardOrderService” could easily be “MotherboardOrderService” or “CarOrderService”:

From OrdersController.cs:

        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult Save()
        {
            _orderService.Process(ViewData);
            return new RedirectResult("Index");
        }

Our controller, in the end, is completely agnostic of our major functionality, our minor (partial view) functionality, and our domain logic:

OrdersController.cs:

using {etc}
using Ninject;

namespace MultiTenantNinject.Controllers
{
    [HandleError]
    [ProvideCompanyConfig]
    public class OrdersController : Controller
    {
        ICompanyConfig _companyConfig;
        IOrderService _orderService;

        public OrdersController(ICompanyConfig pCompanyConfig, IOrderService pOrderService)
        {
            _companyConfig = pCompanyConfig;
            _orderService = pOrderService;
        }

        public OrdersController()
        {
        }

        public ActionResult Index()
        {
            ViewResult v = View(_companyConfig.Views["Order Management"]);

			// add view data items for the header and children;

			// add item to be used for determining if it's a taxable or non-taxable transaction:
			v.ViewData.add("taxState",repository.TaxState);

            return v;
        }

        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult Save()
        {
            _orderService.Process(ViewData);
            return new RedirectResult("Index");
        }
    }
}

Thus, the conclusion to our series about utilizing dependency injection within ASP.Net MVC to enhance a Multi-Tenant Architecture. We can provide service objects without our controller (or anything else) performing logic switches, we can provide major changes to functionality without creating a new codebase, and we can provide in-place customizations truly in-place. In addition, we’ve created our application such that we can utilize any kind of data layer or repository and we can utilize testing frameworks to test our code without having to rewrite anything. And lastly, although it’s taken a moderate level of effort to get to this point, we can be secure in the knowledge that additional changes can be implemented without affecting existing functionality, and we can easily swap out functionality when the situation arises with very little additional effort.

To start off with, let’s talk about using Ninject with ASP.Net MVC. You’ll need to download the appropriate Ninject version for your .NET framework. Our example will use Ninject 2.0 with ASP.Net MVC 1. Download Ninject from the homepage at http://ninject.org/ and visit the dojo and github to learn the basics. Ninject will manage our controllers for us (it needs to, so it can monitor for injection points) and so will need to be tightly integrated into our application. For starters, we’re going to need to change our global.asax.cs file. Take a look:

Global.asax.cs:

using System;
using System.Collections.Generic;
using System.Reflection;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
using Ninject.Web.Mvc;
using Ninject;
using Ninject.Modules;
using MultiTenantNinject.Controllers.Components;
using MultiTenantNinject.Models;

namespace MultiTenantNinject
{
  // Inherit from NinjectHttpApplication instead of HttpApplication
  public class MvcApplication : NinjectHttpApplication
  {
    public static void RegisterRoutes(RouteCollection routes)
    {
      routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

      // hack for visual studio's web server
      routes.IgnoreRoute("{*favicon}", new { favicon = @"(.*/)?favicon.ico(/.*)?" });

      routes.MapRoute(
        "Default", // Route name
        "{controller}/{action}/{id}", // URL with parameters
        new { controller = "Home", action = "Index", id = "" } // Parameter defaults
      );

    }

    // we use OnApplicationStarted, because Ninject is using Application_Started
    protected override void OnApplicationStarted()
    {
      // no big surprise here -- register our routes.
      RegisterRoutes(RouteTable.Routes);
      // register every controller in our application for injection
      RegisterAllControllersIn(Assembly.GetExecutingAssembly());
    }

    // this is called automatically from within the Ninject framework
    protected override IKernel CreateKernel()
    {
      // create a Kernel to manage injections.
      // have the Kernel process our "SetupModule" class
      IKernel k = new StandardKernel(new SetupModule());
      // have the Kernel process our "ConfigModule" class
      k.Load(new ConfigModule());
      // have the Kernel process our "OrderModule class
      // pass an instance of our company config that our ConfigModule calls for
      k.Load(new OrderModule(k.Get<ICompanyConfig>()));
      return k;
    }
  }
}

You can see how the CreateKernel() method loads a number of Modules to manage our Dependency Injection. Let’s take a look at these modules. The first module to investigate will provide bindings for our .NET MVC dependencies.

SetupModule.cs:

using {etc}
using Ninject;
using Ninject.Modules;
using Ninject.Web.Mvc;

namespace MultiTenantNinject.Controllers.Components
{
    // inherit from NinjectModule
    public class SetupModule : NinjectModule
    {
        // NinjectModule is an implementation of the Strategy design pattern and must implement "Load()"
        public override void Load()
        {
            // Let's inject .NET MVC framework dependencies, wow!
            Bind<IFormsAuthentication>()
                .To<FormsAuthenticationService>();
            Bind<IMembershipService>()
                .To<AccountMembershipService>();
            Bind<MembershipProvider>()
                .ToMethod(ctx => Membership.Provider);
        }
    }
}

Our next module will bind the heart of our Multi Tenant Architecture, the “Company Config”. This configuration object will be lightweight, cached server-side (ideally once for each company) and will be available during most operations of the page lifecycle.

ICompanyConfig.cs:

using {etc}

namespace MultiTenantNinject.Models
{
    public interface ICompanyConfig
    {
        // Task #1 -- provide service objects
        Dictionary<string, string> Bindings { get; set; }
        // Task #2 & #3 -- provide views and partial views
        Dictionary<string, string> Views { get; set; }

        String CompanyName { get; set; }

    }
}

ConfigModule.cs:

using {etc}

namespace MultiTenantNinject.Controllers.Components
{
    public class ConfigModule : NinjectModule
    {
        public override void Load()
        {
            // Ninject.Activation.Provider is a factory object.
            CompanyConfigProvider Provider = new CompanyConfigProvider(WebConfigurationManager.AppSettings);

            // Bind our service (ICompanyConfig) to its implementation using the
            // aforementioned Provider.  Bind it so that each request uses the same
            // instance of the service.
            Bind<ICompanyConfig>()
                .ToProvider(Provider)
                .InRequestScope();

        }
    }
}

Our next module will control the functionality for our example customizations revolving around Purchase Orders. In practice we could have multiple modules, perhaps one for each functional area of our application, but our single module will serve our purposes here:

OrderModule.cs:

using {etc}

namespace MultiTenantNinject.Controllers.Components
{
    public class OrderModule : NinjectModule
    {
        private readonly ICompanyConfig _config;

        // We see our first "Inject" attribute.
        // Here we will take an instance of our company config
        // and later use it to bind our application services
        [Inject]
        public OrderModule(ICompanyConfig companyConfig)
        {
            _config = companyConfig;
        }

        public override void Load()
        {
            // use reflection to bind a list of types (from our Config's "Bindings" collection)
            // to be used when called upon during injection
            string serviceLocationPrefix = "MultiTenantNinject.Services.";
            foreach (KeyValuePair<string,string> item in _config.Bindings)
            {
                Bind(Type.GetType(serviceLocationPrefix + item.Key)).To(Type.GetType(serviceLocationPrefix + item.Value));
            }
        }
    }
}

Let’s briefly revisit our goals from Part #1:

1. dynamically set which service object(s) we are using to perform our application logic
2. dynamically set which view we are returning
3. dynamically set which partial views we are using

At this point we can see the pattern unfolding. We use our Modules to dictate to the Kernel what strategies to use when binding implementations to our services. We can use reflection, we can use strings and types, and we can use Providers inside of our Modules during binding. We will be coming back to OrderModule.cs, as that is part of our implementation for Goal #1. Let us take a look now at our Provider from our ConfigModule:

CompanyConfigProvider.cs:

using {etc}
using Ninject.Activation;

namespace MultiTenantNinject.Models
{
    // inherit from Ninject.Activation.Provider
    public class CompanyConfigProvider: Provider<CompanyConfig>
    {
        // these settings are provided by our web.config in this example
        public CompanyConfigProvider(NameValueCollection settings)
        {
            Settings = settings;
        }

        protected NameValueCollection Settings { get; set; }

        // build and return an instance of our CompanyConfig using the specific context
        // IProvider is a Factory that will have its CreateInstance() method called
        // the first time that a CompanyConfig is injected
        protected override CompanyConfig CreateInstance(IContext context)
        {
            // use a caching mechanism to store our company config.  we cannot
            // cache in the Application cache because we have a Multi Tenant Application.
            // we can use Session in a pinch, although depending on your application's traffic,
            // you might need to use something else
            System.Web.SessionState.HttpSessionState Session = HttpContext.Current.Session;
            CompanyConfig cc = null;

            // if we don't have a cached company config:
            if (Session == null || Session["cc"] == null)
            {
                cc = new CompanyConfig();
                // our repository is extremely unsophisticated, but you should
                // get the idea of how this works.  it may very well be passed in
                // via constructor injection
                MultiTenantNinject.Models.Repository r = new Repository();

                // construct our list of Views to be used throughout the application
                // for Goals #2 and #3
                foreach (KeyValuePair<string, string> item in r.getViews())
                {
                    cc.Views.Add(item.Key, item.Value);
                }
                // construct our list of service bindings to be used throughout the application
                // for Goal #1 (previously seen in OrderModule.cs
                foreach (KeyValuePair<string, string> item in r.getBindings())
                {
                    cc.Bindings.Add(item.Key, item.Value);
                }
                // if we can cache our company config:
                if (Session != null && Session["cc"] == null)
                {
                    Session["cc"] = cc;
                }
                // set company name (normally would be from the repository)
                cc.CompanyName = "Widgets, Inc.";
            }
            else  // we have a previously cached company config
            {
                cc = (CompanyConfig)Session["cc"];
            }

            return cc;
        }
    }
}

To make our lives a little easier and yet more structured, let’s create an ActionFilterAttribute to inject our CompanyConfig into our Views:

From ProvideCompanyConfigAttribute:

    public class ProvideCompanyConfigAttribute : ActionFilterAttribute
    {
        [Inject]
        public ICompanyConfig Settings { get; set; }

        public override void OnActionExecuted(ActionExecutedContext filterContext)
        {
            filterContext.Controller.ViewData.Add("companyConfigSettings", Settings);
        }
    }

We use Ninject’s “Inject” attribute to provide the CompanyConfig to our Attribute, and then inject the config into the controller as a matter of course.

At this point we’ve seen how Ninject positions itself within our application (a controller factory and application superclass) and how we can use Ninject’s modularity to manage our bindings. We’ve touched upon Goals #1, 2, and 3, and can see it taking shape before us. We have a company configuration that encapsulates the customizations for the currently logged in user and provides the customized bindings and views for that logged in user. We have basically everything we need to begin working with our customized functionality.

To get this far we have made the following assumptions:

1. Your repository works.
2. You have an ASP.Net MVC application in otherwise working order.
3. You have downloaded and referenced the Ninject libraries.

In Part 3 we will look at our application controllers and views, and then explore what we can do to provide customized functionality to our users.

1. Your users all log into a single codebase. It might be load balanced, cached, the whole nine yards, but everybody is on the same build and accesses the same data.
2. Your users log into multiple codebases and/or multiple databases. Perhaps you have some high-powered customers who want custom functionality, and so you forked your codebase and created them their own functionality. Most likely, you can update your customer’s builds independently of one another.
3. Your users all log into a single codebase, but you use flags, connection strings, config files, etc., to logically separate out your users from one another. Your high-powered customers see their custom functionality, but it’s part of the main codebase and you are able to update your application in one fell swoop.

We’re going to talk more about option #3 — the Multi-Tenant Architecture. There is PLENTY of reading material out there for you to learn more about multi-tenancy. Suffice it to say that it allows you to satisfy multiple sets of requirements for your multiple customers via one codebase, and your customers, most likely, are logically separate in the database(i.e. they use one schema and one top-level data store) instead of physically separate.

In the past, (and present, for novice developers), it was a usual practice to utililze config files, database flags, etc., to turn on and off functionality. Your code may have looked something like:

<% if (showThisFunctionality) %>
<-- this widget is shown -->;
<% else %>;
<-- this other widget is shown -->
<% end if %>

Fig 1: Classic ASP

By utilizing a dependency injection framework you can provide features to your users, based on configuration and setup, without having to use logic switches inside of your application. This is above and beyond the existing benefits of using a dependency injection framework, which is not the scope of this essay but can be enumerated here, for instance. Our example will use Ninject and ASP.NET MVC, although you could use any DI and application frameworks.

Our challenge for this example will be to:

1. dynamically set which service object(s) we are using to perform our application logic
2. dynamically set which view we are returning
3. dynamically set which partial views we are using

Our example will utilize dependency injection to provide order fulfillment functionality for our customers. For goal #1, we will use Ninject's MVC integration to provide service objects for our controllers. Once Ninject is wired up, we can have our service objects perform our application logic against our Model, and as a matter of fact, Behavioral design patterns are a good fit here. Goal #2 is achievable fairly easily with ASP.Net MVC. Setting which view you're returning via any MVC framework is often a very simple operation and comes down to returning a string variable which represents the view in question. For ASP.NET MVC we can 'returnView("viewName")' where "viewName" is the name of the view we wish to return. There is also the obvious "return View(viewNameVariable)" override. Our example will use a configuration object to set which view is being called. Accomplishing goal #3 can be thought of as an extension of #2, but "finer grained". Where you have general and reusable functionality within your view, your partial views allow you to have specific customizations exposed to your user in a consistent fashion.

In Part 2 we will investigate both integrating Ninject with ASP.Net MVC as well as what shape our framework will take. In Part 3 we will finish up our framework architecture and explore how to use it to provide features to our users.

-Craig

1. Adding reference to SQLite.dll. After installing SQLite there will be a Compact Framework folder in the following path :C:\ProgramFiles\SQLite.NET\bin.  This folder contains the System.Data.SQLite.dll that needs to be referenced.

2 The same path will also contain the dll which Windows Mobile will need to invoke the methods contained in the SQLite.dll.  The following file needs to be added to the project which contains the main executable,  SQLite.Interop.065.DLL.

Once the interop dll is in the project you can start using SQLite in the Mobile Application just as you would for any other application.

Craig

Resolution:

So here is what I did to fix the issue (to get it to work using IIS):

1. Make sure that the dll in question is either set to “Copy to: Local). Go to References, right click on AjaxControlToolkit and select properties. In my case it was already set to Copy Local. So that was not the issue

2. Open IIS Manager, browse to the AppPool (in my case it was the DefaultAppPool… it is just a Dev box, ok!). Go to Advanced Settings, and set Enable 32-bit Applications to true. Now that did fix the problem I was having.

For Cassini:

1. I had to give modify rights on the asp.net temp folder  to the Apppool identity (in my case IIS users group).

Discussion

• On further research (i.e. “google”), I came to the conclusion that it was a permissions error related to the Temporary ASP.NET Files folder (C:\Windows\Microsoft.NET\Framework64\v2.0.50727). Some of the other fixes for this problem can be found on other blogs. They relate to the access permissions on the ASP.NET folder, Trust level Settings on the Website, and Anti-virus settings. Here is a link to some of them:
• What I found was that the main focus while resolving this error should be on the later part of the error that says ‘Access is denied’ or “Invalid Argument’ etc.. that will help you in attacking the issue. In my case it was the fact that I was running a 32 bit app on a 64 bit mc and a permissions issue as well on the Temporary ASP.NET folder.
• If you get an ‘Access Denied’..try checking the permissions on the Temp ASP.NET folder.
• If you get ‘Invalid Argument’ try cleaning the temp asp.net folder and restarting the web site.

http://lichao.net/eblog/fix-access-is-denied-exception-from-hresult-0×80070005-e_accessdenied-on-local-machines-200905307.html

http://weblogs.asp.net/joshuajohnson/archive/2008/12/22/could-not-load-file-or-assembly-ajaxcontroltoolkit-or-one-of-its-dependencies-the-parameter-is-incorrect-exception-from-hresult-0-215-80070057-e-invalidarg.aspx

http://msforums.ph/forums/t/46678.aspx

While testing the policy, we were unable to return a proper FaultContract from the WCF Service.  The only error that we received was the generic Communication Error:

System.ServiceModel.CommunicationException: An error occurred while receiving the HTTP response to (path of service).
 This could be due to the service endpoint binding not using the HTTP protocol.
This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down).
See server logs for more details. --->  System.Net.WebException: The underlying connection was closed:
An unexpected error occurred on a receive.
  System.IO.IOException: Unable to read data from the transport connection: An existing connection was
forcibly closed by the remote host.
 System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host.

This error is incredibly deceiving and led to many dead ends while trying to track down the root cause of the error. I re-wrote the app.config file and removed and re-added the service references, all to no avail.

The cause of the problem was simply in the name of the policy. If you don’t name your shielding policy “WCF Exception Shielding” verbatim then the policy will not be found and the error above will be thrown.  If you do name your policy something different or you implement different policies for different types of exceptions then you have to explicitly state in the ExceptionShielding attribute the name of the policy as follows:

C#:[ExceptionShielding("MyPolicy")]
VB: <ExceptionShielding ("MyPolicy")>

I renamed the policy to the default name and started receiving the Fault Contracts as expected.

Hope this helps eliminate some headaches for someone.

-Craig

This is not a JIT Compiler, but is a static compiler that turns .NET executables into native applications. 

For more information, check out the project at : http://www.mono-project.com/MonoTouch