Specify Name and Port for Website Project in IISExpress

When using IISExpress to develop a Website project it is nice to have a specific machine name and port to refer to.

You can specify the machine name and port by editing the binding in the IISExpress applicationhost.config file. The following information was gleaned from this answer on StackOverflow.

  1. Open your applicationhost.config file. It most probably will be %userprofile%\Documents\IISExpress\config\applicationhost.config, but inspect the output from iisexpress.exe to be sure.
  2. Locate your WebSite entry and add following binding with your machine name.
         <binding protocol="http" bindingInformation=":50333:your-machine-name" />
    
  3. Restart IIS Express

I actually specified my machine name as well as the local domain.

bindingInformation=":8013:my-machine-name.my-domain.local"

This seems to be working just fine for me. If you are wanting to actually share that url for others to access (maybe within your own work network) you might have to run this in a administrator command prompt as specified in this StackOverflow answer:

netsh http add urlacl url=http://vaidesg:8080/ user=everyone

 

Deserializing JSON to a .NET Object

Generally in .NET MVC you would use the default model binders to deserialize JSON to a .NET object. However, there are some cases, involving “complex” collections, where this becomes a bit tedious to do. Microsoft provides a few ways around this, but none are satisfactory. Unlike the default model binders, the JavaScriptSerializer provides support for deserializing JSON to a .NET object with complex collections.

Take the following simple class and method signature for example:

// simple class
public class SaveInformation
{
    public string Name { get; set; }
    public Dictionary<string, List<SaveItem>> Components { get; set; }
}

// method signature
public ActionResult Save(SaveInformation saveInformation)

Below I’ve included some simple JSON that we will pass to .NET via AJAX:

{"SaveToSession":false,"Name":"My Stupendous Thing","Components":{"Component1":[{"ProductId":"1234"}]}}

We are passing the JSON to .NET using AJAX with the “application/json” contentType. Because we are using the “application/json” contentType, .NET will automatically call the JsonValueProviderFactory and map the information over to our SaveInformation model. It seems pretty straight forward, the Save method will receive a SaveInformation object when it is called.

Not so straightforward unfortunately, the Save method does receive a SaveInformation object. If we inspect our SaveInformation object we see the Name is populated perfectly fine, but the Components dictionary ends up being null.

The reason for this? It seems that the JsonValueProviderFactory doesn’t fully support pure JSON syntax. In order for .NET to properly parse a complex collection, you actually have to give it a numerical index.

From http://msdn.microsoft.com/en-us/magazine/hh781022.aspx:

Though it’s somewhat counterintuitive, JSON requests have the same requirements—they, too, must adhere to the form post naming syntax. Take, for example, the JSON payload for the previous UnitPrice collection. The pure JSON array syntax for this data would be represented as:

[
    { "Code": "USD", "Amount": 100.00 },
    { "Code": "EUR", "Amount": 73.64 }
]

However, the default value providers and model binders require the data to be represented as a JSON form post:

{
    "UnitPrice[0].Code": "USD",
    "UnitPrice[0].Amount": 100.00,

    "UnitPrice[1].Code": "EUR",
    "UnitPrice[1].Amount": 73.64
}

I know right? It was hard for me to read this as well due to the anime-sized tears in my normal-sized eyes. The problem is, no browser I know of has a JSON.serializeForDotNet function. So this leaves us with two options, make our own JSON serializer, or make our own ValueProvider/ModelBinder. Neither of these options sounded very appealing to me, so I went with the hidden third option. Pass in a string 🙂

You can use the JavaScriptSerializer class, located in System.Web.Script.Serialization, to deserialize JSON information and, as an added bonus, it actually handles properly formatted pure JSON!

So, the new method looks like this. We pass in a string value and deserialize it using the JavaScriptSerializer. Now we receive a SaveInformation object with a fully populated Components dictionary.

public ActionResult Save(string saveInformation)
{
    // instantiate a JavaScriptSerializer
    JavaScriptSerializer serializer = new JavaScriptSerializer();

    // use the JavaScriptSerializer to deserialize our json into the expected object
    SaveInformation saveInformationObject = serializer.Deserialize<SaveInformation>(saveInformation);

The Case of the Disappearing Cookie

If you are working on a site that doesn’t have a proper TLD (i.e. http://localhost:8013) you will notice that setting cookies on the browser doesn’t seem to work the way it should. Sometimes your cookie, which works perfectly fine on a site with a TLD, will not show up on your local site.

For example, this code will work perfectly fine on a site with a TLD but not on your local site.

newCookie = New HttpCookie(ConfigurationManager.AppSettings("YOUR_SPECIAL_COOKIE_NAME"))
newCookie.Domain = ConfigurationManager.AppSettings("BASE_DOMAIN")
HttpContext.Current.Response.Cookies.Add(newCookie)

At this point you might be thinking, ‘I did everything right, where did my cookie go?‘.

This comes down to how the browser handles setting cookies that have a specified domain. The browser prepends a ‘.’ (that’s a dot) to the beginning of any domain specified for a cookie. On normal domains this basically just says that this cookie is valid for this domain and any subdomains. The following non-doctored image proves it:

Set two cookies, one with a specified domain and one without.

Setting Test Cookies
JavaScript to set test cookies for the superfrogadventures.com domain.

This results in the following two cookies

Shows the results of the first cookie set.
Shows the results of the first cookie set.
The Second Test Cookie
Shows that the domain does not have a dot.

You will notice that the domains are a bit different. One has a ‘.’ while the other does not.

So. All this to say, if you are developing locally (or on a site without a TLD) then you will need to save your cookies without a “domain”. This will ensure that the cookie is accessible. Otherwise you will probably need to create yourself some sort of domain with a TLD.

Alternative to Eval() and Casting in Databound Control

Some of you might already know this, however I found it interesting and helpful. For the case of this example let’s say you have a Person object defined somewhere in your ASP.NET code.

Public Class Person
	Public Property FirstName As String
	Public Property MiddleName As String
	Public Property LastName As String

	Public ReadOnly Property FullName As String
		Get
			Return String.Join(" ", FirstName, MiddleName, LastName)
		End Get
	End Property
End Class

Say for example you have a collection of Persons that you’ve assigned to a webforms repeater. In your ItemTemplate you would like to access the properties of whatever object you’ve bound to the repeater. .NET 4.5 introduced some new options that allow you to strongly type your ASP.NET data controls.

First let’s go through the way it used to be done…

.aspx.vb File (CodeBehind)

'// declare a list for our repeater to use
Dim persons As List(Of Models.Person)

'// populate the list with persons (returned by this random function, who cares what it does)
persons = _personDAO.GetPersons()

'// assign the list to the repeater and bind 'em up
repPeople.DataSource = persons
repPeople.DataBind()

.aspx File

<asp:Repeater ID="repPeople" runat="server">
	<HeaderTemplate><ul class="people"></HeaderTemplate>
	<ItemTemplate>
		<li class="col_12 peopleWrap">
			FullName: <%# Eval("FullName")%>
		</li>
	</ItemTemplate>
	<FooterTemplate></ul></FooterTemplate>
</asp:Repeater>

You can use Eval to evaluate a string and output the related value like is done in the example above. This uses reflection to figure out what the current object is and outputs whatever property that you’ve specified in your string. This is just a string so you don’t get any intellisense and you have to remember (ugghhh – remembering what’s that?) what properties you have access to.

You can also cast the object to the type you know that it should be. This is nice because it avoids expensive reflection and it also gives us intellisense. After casting you can access the properties normally with intellisense help. (Not to mention warnings and errors should a property on the source object ever change). I.E. Full Name: <%# CType(Container.DataItem, Models.Person).FullName%>
Casting is nice and all, but it can get a bit tedious and messy, especially if you have to cast every time you want to access a property.

Using .NET 4.5 — Strongly Typed Repeaters
However, thankfully, .NET 4.5 decided to help us out and allow us to strongly type our repeaters. This gives us the best of both worlds, we get intellisense, avoid expensive reflection, and also can easily access properties without extensive use of CType. All you have to do is set the ItemType attribute on the repeater itself.

<asp:Repeater ID="repPeople" runat="server" ItemType="Models.Person">
	<HeaderTemplate><ul class="people"></HeaderTemplate>
	<ItemTemplate>
		<li class="col_12 peopleWrap">
			FullName: <%# Item.FullName%>
		</li>
	</ItemTemplate>
	<FooterTemplate></ul></FooterTemplate>
</asp:Repeater>