dynamitey and dynamic MVC models

So today I’m building out my new MVC application and get to writing this small block of code

  return View(new { Items = model });

ANDDD

Server Error in ‘/’ Application.


‘object’ does not contain a definition for ‘Items’

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: ‘object’ does not contain a definition for ‘Items’

Apparently what I want to do is literally impossible. Ironically I had already commented on one of these answers.

Eventually the rabbit hole leads me to dynamitey (github)   and now I can do:

  return View(Build<ExpandoObject>.NewObject(Items: model });

 

Debugging layered http calls with fiddler

You may reach a point where all you want to know is EXACTLY what is a web server returning to you over http whether it’s from a webservice or even just regular http call. At times this can become very tricky to get access to the raw responses when your requests go through a webservice client like WCF or a http client like EasyHttp.

Yesterday this cropped up that I wanted to get access to the raw response of a web application that I consume from another web application over EasyHttp.

The simplest way to make sure a request goes to the fiddler proxy is replace localhost with ipv4.fiddler (or ipv6.fiddler if that’s what you’re interested in). However there are many scenarios where this won’t work, especially in .NET tools that this results in

The remote name could not be resolved: ‘ipv4.fiddler’

The way I was able to accomplish this:

Instead of having app1 call localhost/restful to change the url to be machineName/restful.

In addition to this change you want to add this section to your web.config while debugging

<system.net>
<defaultProxy>
<proxy usesystemdefault="False" bypassonlocal="False" proxyaddress="http://127.0.0.1:8888 " />
</defaultProxy>
</system.net>

Between these 2 changes this should force the traffic to go across Fiddler’s proxy to be able to be properly captured.

BloggingContext.ApplicationInstance.CompleteRequest();