GeekFest #6 - WebApiProxy Update
Friday, January 30, 2015
It's been a long wait but the time has finally come for more interesting features on WebApiProxy. This video briefly outlines some of the many great features that were added to WebApiProxy in the past couple of months.
You can read more on this project by going to this introductory blog post or at my recent blog about the update.
You can follow and contribute to the project on GitHub here
Labels:
ASP.NET Web API,
GeekFest,
GitHub,
MEX,
WebApiProxy
An update on WebApiProxy
Saturday, January 24, 2015
This project initially started as a proof of concept but quickly grew into something very useful. For the past year or so it became quite popular and plenty of bugs came out of the cracks, but also useful feedback for features too!
You can download the packages straight from NuGet: WebApiProxy Provider and Web API C# Proxy Generator
You can download the packages straight from NuGet: WebApiProxy Provider and Web API C# Proxy Generator
Release notes
Here are a quick summary of issues resolved and features introduced in the latest version:
WebApiProxy Provider (version 1.0.2.4)
- OWIN support and compatible with self-hosted Web APIs
- Custom MEX endpoint address
- Enums and Constants support in DTOs
- Support for IHttpActionResult
- Extended documentation on DTOs
- Plenty of bug fixes & refactoring
WebApiProxy C# Generator (version 1.0.3.21)
- PCL compatible
- Generated code now contained inside project
- Opt-in for automatic code generation during build (now disabled by default)
- On-demand code generation using NuGet Package Manager Console
- No more reloading project for unresolved types
- Cleaner config file
Labels:
ASP.NET Web API,
C#,
MEX,
nuget,
Powershell,
Silverlight,
Web Api Proxy,
WebApiProxy,
Xamarin
Fiddling around with XML responses
Tuesday, January 6, 2015
My year started with new challenges, first of which is malformed and unformatted XML. One of the requirements of a new project I'm working on is to read a simple XML response from a web service and do something with the data. How hard could it be?
Like any other developer, debugging tools like Fiddler is my friend. After capturing the response, I noticed that the contents were malformed and not properly formatted, but still "valid" XML.
Viewing the actual raw response, I realized that the apparent XML elements within the root 'string' element where actually encoded literal strings:
After accepting that I can't change the world, but definitely change the way you think about it, I decided to create a helping aid in the form of a Fiddler extension to help me make sense of the so-called XML.
Now we can get coding! Add a new class to the project with the following assembly attribute:
To make this class visible to Fiddler we need to implement the IAutoTample interface and in the AutoTamperResponseBefore function, we can modify the response before it is served to the client.
This will use the provided Session object and replace the XML encoded angle brackets < and > as < and > respectfully. While we at it, I've also decided to brand the response by adding a "Response-Hijacked-By" response header just because we can.
Lastly we need to build the project and copy the DLL to the Fiddler Scripts directory at %programfiles(x86)%\Fiddler2\Scripts\
Note: You may need to restart Fiddler if it was running.
Till next time!
@FanieReynders
Like any other developer, debugging tools like Fiddler is my friend. After capturing the response, I noticed that the contents were malformed and not properly formatted, but still "valid" XML.
Viewing the actual raw response, I realized that the apparent XML elements within the root 'string' element where actually encoded literal strings:
After accepting that I can't change the world, but definitely change the way you think about it, I decided to create a helping aid in the form of a Fiddler extension to help me make sense of the so-called XML.
Creating a Fiddler Extension
The first thing we have to do is create a new class library project in Visual Studio. We are going to target Fiddler version 4, so make sure the .NET target framework is set to 4.0.
Next, we need to add a reference to our project to the Fiddler assembly located at %programfiles(x86)%\Fiddler2\Fiddler.exe:
Now we can get coding! Add a new class to the project with the following assembly attribute:
To make this class visible to Fiddler we need to implement the IAutoTample interface and in the AutoTamperResponseBefore function, we can modify the response before it is served to the client.
This will use the provided Session object and replace the XML encoded angle brackets < and > as < and > respectfully. While we at it, I've also decided to brand the response by adding a "Response-Hijacked-By" response header just because we can.
Lastly we need to build the project and copy the DLL to the Fiddler Scripts directory at %programfiles(x86)%\Fiddler2\Scripts\
Note: You may need to restart Fiddler if it was running.
Testing the goodness
Now when we execute the request, the extension kicks in and alters the response as proper XML:
We even got a special signature:
2014 Rewind: My year in review
Monday, December 29, 2014
About this time last year I started blogging more often and made a decision to spend a little more time giving back to the community and completely re-branded myself to be more efficient in what I do. Oh boy was it a year!
Looking back on 2014 brings back both happy and sad moments, but also life changing events as well. Unlike the other technical articles I've written in the past year, this one will be different and completely dedicated to 2014, my year...
Looking back on 2014 brings back both happy and sad moments, but also life changing events as well. Unlike the other technical articles I've written in the past year, this one will be different and completely dedicated to 2014, my year...
Labels:
2014,
Happy Holidays,
Review
GeekFest #5 - AngleSharp with Florian Rappl
Sunday, November 23, 2014
There are a few good HTML & CSS parsing libraries out there, but AngleSharp definitely stands out among them by giving .NET developers all the same possibilities of modern browsers using JavaScript. In this fifth episode of GeekFest, Florian Rappl takes us through what AngleSharp actually is and why it is not "just another head-less browser". He briefly outlines some impressive performance metrics of this portable class library and takes us through some cool features like built-in CSS parsing and DOM querying.
Although the library hasn't reached it's official 1.0 release yet, it's fully extendable from the get-go and the project is already inviting pull-requests on GitHub. You can also grab it from Nuget.
Please feel free to leave your feedback on the subject. Enjoy.
Although the library hasn't reached it's official 1.0 release yet, it's fully extendable from the get-go and the project is already inviting pull-requests on GitHub. You can also grab it from Nuget.
Please feel free to leave your feedback on the subject. Enjoy.
Labels:
.NET,
AngleSharp,
C#,
CSS,
Florian Rappl,
GeekFest,
HTML5,
Parser
Subscribe to:
Posts (Atom)