MVC 4 Install on IIS 7 First time 404.14 Error

Ok, I have run into this a few times installing MVC for the first time on IIS.  You copy the file out to the server, set up the application and nothing happens.  Here are the steps I go through to solve the problem.

1. Make sure .Net is installed to the version of your site.  In the MVC case make sure you have 4.0 or better most likely and compile your site to that version by right clicking your Project Properties and setting the .Net version.  If you need a later version, install it on the server.

2. After IIS is installed, register that version of IIS there.
cd \
cd Windows\Microsoft.NET\Framework\v4.xxx.xxx
aspnet_regiis -i

3. If it still doesn't work you may have to look in your config file.  One line I had to add to get things working was the following.
<system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
    ...
<system.webServer>
4. If your still getting the 403, you need to start looking at the permissions used.  If the site is using windows authentication, do you have rights to use it on that server?  Perhaps you need to use impersonate like below.
<system.web>
    <identity impersonate="true" userName="domain\username" password="password"/>
</system.Web>
Another common line of code that will cause issues is the deny users, remove this from the config if need be, but make sure to take care of that authentication then.  
<authorization>
      <deny users="?"/>
</authorization>
Good Luck!

Publisher Subscriber WCF Implementation C#

The publisher subscriber software pattern was described several decades ago as a way to decouple messaging between systems.  It allows the source of data to let an unknown number of subscribers know about the data and have it without knowing who they are.  This is useful in modern day business software as many times you will have an object, say a new product that comes into the system, and several other systems want to know about that new product.  The challenge arises when we want to send that product to all sub systems.  Traditionally, we may have put the product in a table, and each other system would have a routine to look at the table for new products.  This is clunky and depends on schedules which is limiting in its own right. 
The next method to implement this traditionally was to have the process that loads the new product to go ahead and push its changes to all other systems as well.  This is much more real time, but does come with the catch that adding any new sub system will require a complete release and regression of all the other systems which is costly.
The publisher subscriber pattern tried to alleviate this by having a central broker take care of the communication from publisher to subscriber.  This 3rd party was historically very simple and really should be.  An interesting way to implement it is with WCF using web services to have more of a distributed setup.  Here is how I did it.
The first thing I did was create a new WCF project I called PubSub.  I had a product object defined to use as my message to pass in transport.  It ends up being passed as an event argument which I placed in a class.
public class ProductChangeEventArgs : EventArgs
    {
        public IProduct product;
    }
Next, I defined the interfaces for my WCF app.  I have a product contract as well as a the product Client Contract.  
[ServiceContract(Namespace = "http://ProductContract.Service", SessionMode = SessionMode.Required, CallbackContract = typeof(IProductClientContract))]
    public interface IProductContract
    {
        [OperationContract(IsOneWay = false, IsInitiating = true)]
        void Subscribe();
        [OperationContract(IsOneWay = false, IsTerminating = true)]
        void Unsubscribe();
        [OperationContract(IsOneWay = true)]
        void PublishProductChange(IProduct input);
    }

    public interface IProductClientContract
    {
        [OperationContract(IsOneWay = true)]
        void ProductChange(IProduct input);
    }
As you can see, the IProductContract has 3 methods.  Subscribe, Unsubscribe and PublishProductChange.  The publishing agent(s) call this routine with the product.  The subscribers call the subscribe method, which is not one way, so it is a connection held open until unsubscribe is called.  The concrete implementation of the IProductContract (ProductService) shows how subscribers are pooled and managed though the subscribe and unsubscribe method and have IProductClientContract called back to them with the product information when it is published by the publisher.  In effect, this WCF app is the broker.
// The Service implementation implements your service contract.
    [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
    public class ProductService : IProductContract
    {
        public static event ProductChangeEventHandler ProductChangeEvent;
        public delegate void ProductChangeEventHandler(object sender, ProductChangeEventArgs e);

        IProductClientContract callback = null;

        ProductChangeEventHandler productChangeHandler = null;

        //Clients call this service operation to subscribe.
        //A price change event handler is registered for this client instance.

        public void Subscribe()
        {
            callback = OperationContext.Current.GetCallbackChannel<IProductClientContract>();
            productChangeHandler = new ProductChangeEventHandler(ProductChangeHandler);
            ProductChangeEvent += productChangeHandler;
        }

        //Clients call this service operation to unsubscribe.
        //The previous price change event handler is deregistered.

        public void Unsubscribe()
        {
            ProductChangeEvent -= productChangeHandler;
        }

        //Information source clients call this service operation to report a price change.
        //A price change event is raised. The price change event handlers for each subscriber will execute.

        public void PublishProductChange(IProduct product)
        {
            var e = new ProductChangeEventArgs();
            e.product = product;
            ProductChangeEvent(this, e);
        }

        //This event handler runs when a PriceChange event is raised.
        //The client's PriceChange service operation is invoked to provide notification about the price change.

        public void ProductChangeHandler(object sender, ProductChangeEventArgs e)
        {
            try
            {
                callback.ProductChange(e.product);
            }
            catch (Exception)
            {
                //todo bad subscriber, remove from queue
            }
        }
    }
It is worth noting that if the subscribers die and don't call unsubscribe, it will cause issues on the broker, some sort of child maintenance would be necessary to make this production ready.  If you need guaranteed delivery, you may consider having this insert into messaging queues vs. TCP/IP calls.

So here is a quick form that could be your Publisher to send messages.
namespace TestPublisher
{
    public partial class Form1 : Form
    {
        InstanceContext context = null;
        ProductContractClient client = null;

        public Form1()
        {
            InitializeComponent();
        }

        public class ServiceCallback : IProductContractCallback
        {
            public void ProductChange(IProduct input)
            {
                MessageBox.Show(input.Description);
            }
        }

        private void button1_Click(object sender, EventArgs e)
        {
            try
            {
                context = new InstanceContext(new ServiceCallback());
                client = new ProductContractClient(context);
                client.PublishProductChange(new IProduct() { Description = textBox1.Text });
                client.Close();
            }
            catch (Exception)
            {

            }
        }
    }
}
Here is an example of a command line app that acts as a subscriber.  You can spin as many of each up as you want and watch the fun as you publish.  
namespace PubSubClient
{
    class Program
    {
        public delegate void MyEventCallbackHandler(IProduct input);
        public static event MyEventCallbackHandler MyEventCallbackEvent;
        

        static void Main(string[] args)
        {
            Console.WriteLine("Starting.");
            new Program().go();
            Console.WriteLine("Waiting.");
            while (true)
                System.Threading.Thread.Sleep(1000);
        }

        void go()
        {
            Console.WriteLine("Initializing");
            InstanceContext context = new InstanceContext(new ServiceCallback());
            ProductContractClient client = new ProductContractClient(context);

            MyEventCallbackHandler callbackHandler = new MyEventCallbackHandler(UpdateForm);
            MyEventCallbackEvent += callbackHandler;
            client.Subscribe();
            Console.WriteLine("Initialized");
        }

        [CallbackBehaviorAttribute(UseSynchronizationContext = false)]
        public class ServiceCallback : IProductContractCallback
        {
            public void ProductChange(IProduct input)
            {
                Program.MyEventCallbackEvent(input);
            }
        }

        static void UpdateForm(IProduct input)
        {
            Console.WriteLine(input.Description);
        }
    }    
}

Restricting MVC site to an IP Range

At times it may become necessary to restrict a website to a particular set of IP addresses sometimes know as IP filtering.  I recently deployed an internal application for a company on the Azure platform hosted my Microsoft.  Deploying the app is content for a different article, but being that it is a internal site for the company in question, I wanted to restrict its access.  After some research, a simple config change can accomplish this in MVC, and Azure supports it.
<system.webServer>
<security>
      <!-- this line blocks everybody, except those listed below -->
      <ipSecurity allowUnlisted="false" denyAction="NotFound">
        <!-- removes all upstream restrictions -->
        <!--<clear/>-->
        <!-- allow requests from the local machine -->
        <add ipAddress="127.0.0.1" allowed="true"/>
        <!--allow network 83.116.119.0 to 83.116.119.255-->
        <add ipAddress="192.168.1.0" subnetMask="255.255.255.0" allowed="true"/>
        <!-- allow the specific IP of 83.116.19.53  -->
        <add ipAddress="208.255.192.122" allowed="true"/>
      </ipSecurity>
    </security>
  </system.webServer>
This can be used to either restrict ip ranges or grant depending on the ipsecurity tag's denyAccess flag is set.  In the example I allow access only to localhost, our network's IP range, and the public facing IP for the business.  Luckily we only have 1, so it was simple, if you have a range, one would just put the 0 in to cover all sets.

Add Tracing To WCF Messages

It sometimes becomes useful to trace messages coming into and out of a WCF service for debugging.  I find when I am doing soap integration's it is especially useful to be able to trace the soap messages for debugging.  The message isn't obviously stored, however there is a trace that you can attach to to get it though the system.diagnostics library.
<system.diagnostics>
  <sources>
      <source name="System.ServiceModel.MessageLogging">
        <listeners>
                 <add name="messages"
                 type="System.Diagnostics.XmlWriterTraceListener"
                 initializeData="c:\logs\messages.svclog" />
          </listeners>
      </source>
    </sources>
</system.diagnostics>

<system.serviceModel>
  <diagnostics>
    <messageLogging 
         logEntireMessage="true" 
         logMalformedMessages="false"
         logMessagesAtServiceLevel="true" 
         logMessagesAtTransportLevel="false"
         maxMessagesToLog="3000"
         maxSizeOfMessageToLog="2000"/>
  </diagnostics>
</system.serviceModel>
Simple enough and now you will have a log file with your requests.

Re-doing a paver path

So I wanted to redo the paver path behind my house.  After I tore the old one out, I only had a few good pavers left and couldn't find matching ones.  Being that my budget was tight on the redo before a family picnic, I decided to rip some 2x4 s into 2x2 and create a frame for the existing pavers to elevate them above the ground and fill the rest in with a washed stone.  I also put the new planter in on the left, but that's a job for another post. 
So first the final product in case you don't want to look any further.  Now how I did it.
I started by laying out the blocks I had and figuring out the gap I needed between each to make my distance.

Once I had this, I started making a frame for the blocks.
I put a little strip of wood under each one to make sure the paver wouldn't work its way through and the wood become elevated around them.  
It was about 20 feet so I made 2 of them that fit together.  I then stained them up to match the deck stain on the house.  It took a few coats, I realize they won't last forever, but it should get me a decade or so, at which point it will probably need to be freshened up again anyways, so a quick fix that I think turned out good.  One last pic after install before the gravel.