ASP.NET Weblogs

ASP.NET and IIS Performance Troubleshooting Tools: FREB, Perfecto, and PerfView

The Official Microsoft IIS Site — Sat, 11 Feb 2012 22:08:00 GMT

If you have an ASP.NET application running on IIS 7 or IIS 7.5 that is experiencing intermittent delays, you have three powerful troubleshooting tools at your disposal that you might not have known about: FREB , Perfecto , and PerfView . 1) IIS Failed Request Tracing ( FREB ) 2) Jose Reyes’ ASP.NET Perfecto tool 3) Microsoft’s PerfView tool 1) Failed Request Tracing Failed Request Tracing (sometimes called “FREB” from its formerly unwieldy name of “Failed Request Event Buffering”) gives you a lot...(read more)

Google AdSense: You suck

Jeff — Sat, 11 Feb 2012 18:08:00 GMT

Like a lot of Web publishers, I depend pretty heavily on AdSense to generate revenue and pay the bills. A good server isn't free. So imagine my horror when, on Thursday, the numbers dropped between 50 and 80%, depending on the site. Something is horribly wrong.

Nothing has changed at my end, so I'm working on the assumption that they changed something. I haven't yet figured out what. My suspicion is that it has something to do with the async code they switched to recently for DFP, but I can't be sure. Analytics and DFP show consistent numbers, and those are also Google products.

Here's what pisses me off the most though: I can't even contact them. I can make a post in their forums, which no one ever reads, and that's pretty much it. Unless you're in the top 1% of earners, humans are not available to answer your questions. I might be small, but I'd like to think after tens of thousands of dollars in revenue for them over the years, I'm at least entitled to a form e-mail.

I hate crap like this. Google, you suck.

ASP.NET MVC 2 Training

guino — Sat, 11 Feb 2012 04:08:00 GMT

ASP.NET MVC 2 Training

Hacking the browser cache with JQuery and ASP.NET MVC

cibrax — Fri, 10 Feb 2012 15:20:05 GMT

Although JQuery provides a very good support for caching responses from AJAX calls in the browser, it is always good to know how you can use http as protocol for making an effective use of it.

The first thing you need to do on the server side is to supports HTTP GETs, and identify your resources with different URLs for retrieving the data (The resource in this case could be just a MVC action). If you use the same URL for retrieving different resource representations, you are doing it wrong. An HTTP POST will not work either as the response can not cached. Many devs typically use HTTP POSTs for two reason, they want to make explicit the data can not be cached or they use it as workaround for avoiding JSON hijacking attacks, which can be avoided anyways in HTTP GETs by returning a JSON array.

The ajax method in the JQuery global object provides a few options for supporting caching and conditional gets,

$.ajax({

    ifModified: [true|false],

    cache: [true|false],

});

The “ifModified” flag specifies whether we want to support conditional gets in the ajax calls. JQuery will automatically handle everything for us by picking the last received “Last-Modified” header from the server, and sending that as “If-Modified-Since” in all the subsequent requests. This requires that our MVC controller implements conditional gets. A conditional get in the context of http caching is used to revalidate an expired entry in the cache. If JQuery determines an entry is expired, it will be first try to revalidate that entry using a conditional get against the server. If the response returns an status code 304 (Not modified), JQuery will reuse the entry in the cache. In that way, we can save some of the bandwidth required to download the complete payload associated to that entry from the server.

The “cache” option basically overrides all the caching settings sent by the server as http headers. By setting this flag to false, JQuery will add an auto generated timestamp in the end of the URL to make it different from any previous used URL, so the browser will not know how to cache the responses.

Let’s analyze a couple scenarios.

The server sets a No-Cache header on the response

The server is the king. If the server explicitly states the response can not be cached, JQuery will honor that. The “cache” option on the ajax call will be completely ignored.

$('#nocache').click(function () {

    $.ajax({

        url: '/Home/NoCache',

        ifModified: false,

        cache: true,

        success: function (data, status, xhr) {

            $('#content').html(data.count);

});

});

public ActionResult NoCache()

   Response.Cache.SetCacheability(HttpCacheability.NoCache);

   return Json(new { count = Count++ }, JsonRequestBehavior.AllowGet);

The server sets an Expiration header on the response

Again, the server is always is the one in condition for setting an expiration time for the data it returns. The entry will cached on the client side using that expiration setting.

$('#expires').click(function () {

    $.ajax({

        url: '/Home/Expires',

        ifModified: false,

        cache: true,

        success: function (data, status, xhr) {

            $('#content').html(data.count);

});

});

public ActionResult Expires()

    Response.Cache.SetExpires(DateTime.Now.AddSeconds(5));

    return Json(new { count = Count++ }, JsonRequestBehavior.AllowGet);

The client never caches the data

The client side specifically states the data must be always fresh and the cache not be used. This means the “cache” option is set to false. No matter what the server specifies, JQuery will always generate an unique URL so that will be impossible to cache.

$('#expires_nocache').click(function () {

    $.ajax({

        url: '/Home/Expires',

        ifModified: false,

        cache: false,

        success: function (data, status, xhr) {

            $('#content').html(data.count);

});

});

public ActionResult Expires()

    Response.Cache.SetExpires(DateTime.Now.AddSeconds(5));

    return Json(new { count = Count++ }, JsonRequestBehavior.AllowGet);

The client and server use conditional gets for validating the cached data.

The client puts a new entry in the cache, which will be validated after its expiration. The server side must implement a conditional GET using either ETags or the last modified header.

$('#expires_conditional').click(function () {

    $.ajax({

        url: '/Home/ExpiresWithConditional',

        ifModified: true,

        cache: true,

        success: function (data, status, xhr) {

            $('#content').html(data.count);

});

});

public ActionResult ExpiresWithConditional()

    if (Request.Headers["If-Modified-Since"] != null && Count % 2 == 0)

        return new HttpStatusCodeResult((int)HttpStatusCode.NotModified);

    Response.Cache.SetExpires(DateTime.Now.AddSeconds(5));

    Response.Cache.SetLastModified(DateTime.Now);

    return Json(new { count = Count++ }, JsonRequestBehavior.AllowGet);

The MVC action in the example above is only an example. In a real implementation, the server should be able to know whether the data has changed since the last time it was served or not.

Does the world really need "official" apps?

Bil Simser — Fri, 10 Feb 2012 14:42:00 GMT

The "buzz" exploded a few days ago with this site. "Official" application requests for Windows Phone 7, vendors and services that don't have a presence (an official one anyway) on the Microsoft phone platform. I have to ask though, do we really need an "official" app?

Okay, let's take a few steps back before we go forward. What exactly is an "official" app. I would say it's a) an app written by the service owner (Instagram, Pinterest, Twitter, etc.) or maybe b) an app officially endorsed by the service owner. In any case it's considered sanctioned, blessed, whatever. Foursquare, Flickr, Groupon, Twitter, YouTube, etc. all have apps like this. In the case of apps like YouTube and Twitter you'll see the application publisher is Microsoft. These guys might have deferred the creation of the apps to Microsoft or the publishing or both.

People see these apps as *the* app they should get if they want to use that service on their phone. Apps turn into verbs and users are told to use Evernote to use their service on their phone. With the moniker of being an official app I suppose it carries a bit of levity as far as stability and reliability.

Or does it?

In the case of longevity it might be the case. As long as ESPN is on the air, they'll have an ESPN ScoreCenter app. Or will they? Budgets come and go so if I was a manager and looked at "trimming the fat" I might consider lopping off the mobile developers and abandoning that early. After all, how much revenue does a free app on a phone get you? I do think once the genie is out of the bottle that organizations will at least try to keep that division running and we haven't seen too many apps fall by the wayside. So yeah, it's probably a safe bet that "official" apps will stay around as long as the service is there.

On the reliability side it's a different story. What's the number #1 request on the user voice site right now? Facebook. Wait, that has an "official" app doesn't it? It was built by Clarity Consulting but looking at the comments on the uservoice site and on the marketplace you see things like "They need to fix this", "Add some new features", and "Need a lot of work!!". The Twitter app, IMHO, is another fine example of an "official" app generally gone wrong. No live tiles, it's been out for 16 months and it's only on version 1.3 and last time I used it I couldn't even do a "reply all" on a tweet. Frustrating.

Official apps may be no better than 3rd party ones out there so don't be fooled by the "official" title. Indie apps are built by developers with a passion, official apps might in some cases be considered an IT expense.

The first thing you have to look at, does the vendor or service have an app? On any platform. If they don't then the next question (besides should they) might be, is there a way to get one on there? Are there any data sources available. Obviously if they have a web presence then they have data but it may not be publicly consumable. If they do have an app, is it good enough. What are the reviews like? Is it meeting the needs of the many and providing a way to access their services to do everything. Is that the purpose of the app? Sometimes apps are supplements to the on-site services they have available and not a substitute. Aside from services, does the app work correctly, doesn't crash, is quick to respond, is updated frequently to align to new features the service offers, etc.

If they do have an API is it a) publicly consumable and b) is it full featured? One stumbling block I hit with producing an Instagram app for Windows Phone was that they didn't provide a way for users to register new accounts or upload photographs, a cornerstone to the service itself. This can be frustrating so before you embark on perhaps building something check to see if you can do it.

So what's the value-add for you building an application, either as the only application on that platform or a supplement to a broken or limited-functional "official" app? Are you making it better or filling in the gaps the official app is missing? What happens when the official app maybe catches up and delivers that functionality. Now you're playing a game with the official team and you might not win that battle. Something interesting with something like Foursquare is that the reviews are not too horrible (some good, some bad) but looking at the reviews and functionality of something like 4th & Mayor is that the official app came out long after Jeff Wilcox's version. Was it too little and too late? Jeff constantly updates the app not only for stabilization but new features. The reviews, UX, and stability of this "unofficial" app outweighs the popularity of the "official" one, although I think this an exception to the rule. Again, this is a good example of a labor of love vs. an IT project.

I think it's great we have the official apps on the Windows Phone but I think it's even better that we have public APIs, a nice development platform, and a passionate community that wants to do better. If all we do is accept the official apps then we're not pushing the envelope. Sometimes that's just not good enough and we as a community deserve better. Support it by showing your voice on sites like the Marketplace Request site, by blogging about it, and by pushing services to provide the ability for developers to step in and help out.

As for vendors and service owners, please do us a favor by exposing your APIs and letting developers do what they do best, develop. Focus on your service if you want and put it out there for others to pick up the ball and run with it. Keep on top of what's out there, help us by helping you, and you might be surprised in what we might be able to accomplish. It's like I tell game studios, focus on building your game. The development community will stand up and provide the supplemental tools that will build the community for you, you just have to give us the tools to do what we're passionate about.

HTML 5 chegou de vez

renatohaddad — Fri, 10 Feb 2012 14:36:00 GMT

Vc já está preparado para o HTML 5? Saiba que isto se tornou padrão em diversos tipos de aplicações como WEB, celulares (para quem usa o browser dos devices), Win 8 (pelo menos a MS promete algo para). Bom, do ponto de vista de desenvolvedor WEB mudam diversas coisas em relação as tags de marcações HTML. Muitas não existem mais no 5 e quando tiveres oportunidade de ler sobre as novas tags ficará feliz em saber que tudo ficou bem mais fácil.

Claro que teremos que aprender CSS 3 para dar uma aparência descente para o site. Fora que aprender JavaScript (ué voltou???) tornou-se regra, ou seja é preciso aprender JS para diversas apps também. Vamos aguardar a MS lançar o VS 2012 (sem data ainda) para nos divertirmos com tudo isto.

Abraços

Entity Framework 4.3 lançado

renatohaddad — Fri, 10 Feb 2012 13:11:00 GMT

Olá pessoal, finalmente a MS lançou o EF 4.3 com algumas novidades http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-released.aspx . O que mais gostei foi do migrations que permite criar um banco e alterá-lo depois diretamente pelo code first. Quem quiser um guia veja http://blogs.msdn.com/b/adonet/archive/2011/09/28/ef-4-2-code-first-walkthrough.aspx e migrations em http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx

Outro tópico interessante é que agora podemos criar um arquivo de configuração para todas as conexões para banco de dados, veja detalhes em http://blogs.msdn.com/b/adonet/archive/2012/01/12/ef-4-3-configuration-file-settings.aspx.

Boa sorte e sucesso!

ArcGIS Editor for OpenStreetMap 2 beta 3 is up for download

albertpascual — Fri, 10 Feb 2012 04:46:00 GMT

Finally after lots of work, Esri released the ArcGIS Editor for OpenStreetMap.

The ArcGIS Editor for OpenStreetMap is a free, open source add-on for ArcGIS for Desktop that helps you become an active member of the growing OpenStreetMap (OSM) community. OpenStreetMap is an open and freely available database of geographic data. The editor makes it easy for you to download OSM data, make changes to the dataset, and contribute those changes back to the entire OSM community.

The OSM Editor provides

Simple tools to upload and download OSM data

An OSM-compatible geodatabase schema to locally store OSM data

An OSM symbology template for faster editing

Conflict-resolution tools for reconciling data back to the OSM database

The ArcGIS Editor for OpenStreetMap, its documentation, and its source code are available on CodePlex, Microsoft's open source repository, and released under the Microsoft Public License.

You can get all the information from this link http://esriosmeditor.codeplex.com/

Then make sure you download the latest beta here, just by clicking this link http://esriosmeditor.codeplex.com/releases/view/81830

SnowCovered.com finally gets an upgrade

Rob Chartier — Thu, 09 Feb 2012 18:38:48 GMT

When we (DNNCorp) originally took ownership of SnowCovered.com from Brice Snow it was running on DotNetNuke 2.1.2 (Release date was June 14, 2004), v1.0 of the .NET Framework and on a low-end hosting provider. Looking back, I recall that we were lucky to get 80% to 90% uptime in any given month. It was on its last legs. We knew, the community knew, we HAD to take action.

Fast forward a little while, and just over a year ago we launched an internal “Upgrade” project for SnowCovered.com. Here is how that story played out…

Our first initiative was to upgrade from the low-end hosting to our own infrastructure which brought up our stability immediately to 99.9% uptime. This was a huge gain for us and the community as a whole. It was nice to be able to rely on solid infrastructure. All of the negativity around the amount of downtime simply fizzled.

Our first significant win!

The next step was to tackle the DNN 2.1.2 issue. For those of you that don’t recall the history of DNN, 2.1.2 was release before the ASP.NET Team release the (then) new Personalization and Membership pieces. The team here spent hours ensuring that every single user in the SnowCovered membership database was upgraded. Countless tests and dry runs were performed, and in the end we prevailed. All users can and will be upgraded fully.

Another win for the team.

The largest task was the actual code base itself. There was a significant amount of rework and simply replacing much of the codebase (VB.NET to C#) as we transitioned it all to the 6.x family of the core framework. At that time we had just hired Nathan Rover and put him on this challenge. He gladly accepted and took the lead. For those of you want have not yet met Nathan, he is a marathon runner – just the man suited for this marathon upgrade and release schedule.

Over the year they took inventory of the feature points, upgraded code, reviewed artwork & designs, cried/yelled/screamed, held design meetings, drank a few gallons of redbull/monster/beaver buzz, QA, upgrade meetings, daily scrums, Unit Tests, more QA, frequent vendor reviews & demos. Project plans were scraped, created and scraped again. We have had churn in almost every aspect of the project.

The team kept running.

There were a few points over the past year were we almost gave up. The stress was high; the light at the end of the tunnel was just barely visible. Nathan and the team pushed on. We persisted.

The team kept running.

Finally the light was blinding. We invited many (~100) of the vendors in for a private Beta; received well over 40 issues, all of which were addressed with great care and attention, and finally accepted the final list of bugs in for the initial RTM release. The team worked day and night nailing these issues down in order to meet our aggressive release schedule, without sacrificing the level of quality we demanded in this release.

As of 3:00AM PST February 9^th, 2012 we crossed the finish line!

We are proud to announce that we have released initial public release of "DotNetNuke, The Store"

Congrats goes out to the entire team!

Here is a before screenshot, as of July 19, 2012:

and now…

..we are just getting started…

CSS3 Tips, Tricks, and Resources

Palermo4 — Thu, 09 Feb 2012 12:20:00 GMT

Do you need to take your CSS3 skills to the next level? The following resources are monitored and kept current. Bookmark these links!