Sys.WebForms is undefined on iPad

Is your site working perfectly fine everywhere except as an iPad full-screen application?  Is it giving you a “Sys.WebForms” is undefined error in javascript? Or is it acting like ajax is disabled in some other way?

This was an incredibly difficult problem to track down, so I thought I’d share it here to pass on the knowledge.

In my case, I was using Telerik’s RadScriptManager, but later I found it wasn’t limited to Telerik’s controls, but to any ajax-related code.  However, I point out Telerik in particular because on their forums they offered a dozen solutions that led me in the wrong direction.

The root problem is that the iPad full-screen app gives a user-agent header that ASP.Net does not recognize, so it believes that the browser does not support ajax.  This results in the ScriptManager not including “MicrosoftAjaxWebForms.js” and all sort of other things related to ajax panels not loading.

So the solution is to tell ASP.Net that the user-agent in question does support ajax.  Luckly we have a custom base page for all of our ASPX files, so I only had to add this in one place:

protected override void OnPreInit(EventArgs e)
{
    if (Request.UserAgent != null && Request.UserAgent.IndexOf("AppleWebKit", StringComparison.CurrentCultureIgnoreCase) > -1)
    {
        this.ClientTarget = "uplevel";
    }

    base.OnPreInit(e);
}

I found this solution here.  Thank you! http://blog.lavablast.com/post/2011/05/29/Gotcha-iPad-versus-ASPNET.aspx#comment

WARNING: EF Code first may only be appropriate for children

I would like to warn anybody who wants to use code first (specifically TPC inheritance) to only use it when you plan to stick with the simple scenarios that you’ve already seen proven out through examples on the web.  Once you begin to stray from these examples, you’ll find yourself with code that doesn’t work with no way to fix it (since, per the Microsoft way, the important classes are all “private internal”).  Here are just a few examples of limitations that I’ve encountered:

1) If you want an entity base class that is not abstract (to, say, work around a bug in RIA services) with a TPC (Table per Concrete Type) configuration, forget about it… there is absolutely no way to do it.

2) Generic types are not supported as entities or as entity base types.

3) If you want to define the properties on your entity at runtime, using ICustomTypeProvider or IDynamicMetaObjectProvider… again, forget about it.

I could go on and on, but the point is that I’ve run into more “not supported” scenarios with this library than almost any other I’ve ever used.  That said, I love the concept… and once EF code first becomes at all extensible, I’ll fully support it.

Entity Framework Code First Migrations: Executing migrations using code, not PowerShell commands

Migrations are cool, but all the documentation only shows how to automatically update the database using the Visual Studio Package Mananager Console, like so:

Update-Database

However, I want my database to be updated through code like some of the older builds of Entity Framework Code First allowed.  Well, I did some digging, and here’s what I came up with.

var migratorConfig = new DbMigrationsConfiguration<NorthwindContext>();
migratorConfig.AutomaticMigrationsEnabled = true;

var dbMigrator = new DbMigrator(migratorConfig);
dbMigrator.Update();

If you’ve enabled migrations for your project using the Package Manager Console, you should have a file called Configuration.cs in your Migrations folder.  You can use this instead of using DbMigrationsConfiguration<>.  So with this setup, you’d have:

var migratorConfig = new ProjectNamespace.Migrations.Configuration();

var dbMigrator = new DbMigrator(migratorConfig);
dbMigrator.Update();

Lastly, you should be aware that the DbMigrator constror creates an instance of your DbContext.  So it’s very easy to create an infinite loop if you try to update the database from your DbContext contructor or from an implementation of IDbContextFactory.Create().  However, this is exactly what I wanted to do, so I just had to add some thread-safe checks around my database migration code:

public static int IsMigrating = 0;
private static void UpdateDatabase()
{
    if (0 == Interlocked.Exchange(ref IsMigrating, 1))
    {
        // Manually creating configuration:
        //var migratorConfig = new DbMigrationsConfiguration<NorthwindContext>();
        //migratorConfig.AutomaticMigrationsEnabled = true;

        // Using configuration defined in project:
        var migratorConfig = new ProjectNamespace.Migrations.Configuration();

        // 3
        //var dbMigrator = new DbMigrator(new Settings());
        var dbMigrator = new DbMigrator(migratorConfig);
        dbMigrator.Update();

        Interlocked.Exchange(ref IsMigrating, 0);
    }
}

Code first and WCF RIA services: Failed to get the Metadataworkspace for the DbContext type ‘{Type}’

While working with WCF RIA services, DbContext (DomainContext), Entity Framework code first, and Silverlight, I received this error quite a bit whenever I tried to run or compile the Silverlight project. 

The error means that there is something wrong with your code first model.  For me, it was usually some attribute that had a wrong string it.

It is annoying because it’s almost impossible to fix this error without knowing the tricks. Good news though!  The way to get around this error is to browse to your WCF RIA service. 

1) In order to make your service browsable at all (at least consistently), you should make your project use IIS rather than IIS Express.  Go into the project settings, under the web tab, and make sure “Use Local IIS Web server” is selected and “Use IIS Express” is not selected.

2) Now you need to find the URL your domain service uses. 

2.a) Make sure “Show all files” is enabled at the top of your Solution Explorer window. 

2.b) In your Silverlight project, expand the folder “Generated_Code”.  Open the file at the root of that folder.  Search for “http://”.  You’ll find a URL that looks similar to:

http://localhost/{WcfRiaServiceProjectName}/{Domain-Service-Namespace-And-Type-Name}.svc

3) Compile the web project by itself so that you have the most up to date error showing when you browse to the URL.

4) Browse to the URL!  It should give a much better error message.  Make sure you have the web project showing exception details. If you don’t, the web page will tell you how to do so.

VirtualBox 4.1.2 Installation freezes

I was having a lot of trouble getting VirtualBox 4.1.2 installed on Windows 7 x64.  It kept freezing at about 75%.  Eventually, I’d have to kill the installation process, but VirtualBox would still show up in my Programs and Features as being installed.  Here’s what I did to finally get it working.

1) I had various Citrix and Cisco VPN related products installed, so I uninstalled all of them.  During one of these installs, I was prompted about a VirtualBox install being suspended, though I don’t know if that was relevant.

2) I went into Device Manager and deleted some extra network adapters I had lying around.  The one that stuck out was one that was installed by OpenVPN a while back, even though OpenVPN is no longer installed.

Next time I tried the install, it went without a hitch!

Are the newer generation of developers reliving past mistakes?

Though I doubt many agree, I have to say: the recent fervor behind HTML 5, CSS3, and JavaScript feels like a step in the wrong direction.

Let me explain:

I come from a time when web development made you want to cry.  I happen from a time when each browser you chose to support would require one to develop an independent set of hacked CSS rules, JavaScript, and often, HTML; and each of these browsers would require testing after each and every change.  I’ve come from a time when debugging in JavaScript meant inserting “alert” statements in dozens of places within the code and then hitting refresh in a browser.  I come from a time when large web applications would contain scores of redundant code, and scores more of unused styles and JavaScript, which would be destined to remain in the application as if they were naught but malignant tumors.

Don’t get me wrong: application development is my passion.  But doing what needed to be done to get a web application working wasn’t development… it was pre-ordained bug fixing.

But as time progressed, things became more hopeful.  XML gave us a flexible way to store data.  Then XHTML gave us a way to read web pages without concern for misinterpretation.  Then SOAP allowed us the ability to share data with others.  Then Silverlight and Moonlight gave us hope of finally ridding ourselves of the shackles that are HTML, CSS, and JavaScript, forever.  Then Windows Phone 7 arrives, promising the market share the world needs in order to take XAML seriously.  And even if you chose not to embrace XAML, you knew that the holy grail was just around the corner.

But then Apple slew Moonlight. (And I will forever curse you, Apple, for your proprietary spells have cast a gloom on us simple software folk.)

And then the masses began to talk of HTML5 as though they’d forgotten how his ancestors had ravaged our towns.

And now I can’t help but wonder, as we progress into the future: will future generations of programmers be forced to deal with the same crap that we had to deal with, over and over again?

Will the technologies used in application development prove to follow a cyclic pattern?  Clothing style does this… just think of how both the 70’s and 80’s styles have come around.  In said fashion, will one generation reintroduce hacker mentalities and force the subsequent generation to deal with the consequences?

Or will advancement be more like some technological tug-of-war between the heroic Architects and the evil Hackers… both alternately giving and then gaining ground as one seeks to build and the other seeks to destroy?

My blog is moving!

I’m going to moving my blog to a new URL.

Please subscribe to http://blog.josh.mouch.name/.

Thank you!

Model Driven Development and Engineering

I have some exciting news for my near future!

I have had a strong desire to develop applications using models for years and years, now.  You can call it Model-driven development (MDD) or Model-driven engineering (MDE) or model-driven architecture (MDA) or whatever you want, but I have no doubt that it is the eventual future of software engineering.

In fact, being in the business as long as I have, a lot of common development tasks become pretty mundane.  And at this point, Software architecture and MDE are the only two things I still enjoy doing.

In the past, I’ve been able to develop only small portions or even a single layer of an application from models.  However, for the last couple years, I’ve taken it upon myself to make MDE a serious pet project, and I was able to re-write a large portion of my company’s flagship product using models and then generating code from those models.  Additionally, I was able to take portions of that effort and use it to generate portions of the existing application.

So what’s the good news?  Well, in the near future, a company may be hiring me to do something similar with their product, and I think this would be most exciting task I’ve undertaken in my 18 years of software development experience!

Here’s to hoping that this project becomes a reality!

Apple’s Dictatorship over Developers

Apple, as of their iPhoneOS 4.0, does not allow any applications to be developed in any language but the four they have chosen: Objective-C, C, C++, or JavaScript.

This means no Flash, no Java, no Silverlight (or any other Microsoft-derived infrastructure), Moonlight (or any other Novell-derived infrastructure, including MonoTouch).

What the #**#!, you say?  …as well, you should.  You don’t believe me?  Here is the relevant section from their agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Thank you, Miguel de Icaza, for pointing this out.

Denying tax credits to companies that ship jobs overseas

It’s obvious that the United States has passed it’s prime.  I’m convinced it’s mostly due to the massive flow of money from our economy to foreign economies.

That’s why I was a bit excited when I read today that Obama was considering denying tax credit to companies that ship jobs overseas.  In principle, I’m not much a fan of Obama due his super-star status getting him elected, however, if he actually invoked this idea, I would worship the land he walked on.

Steps like these obviously need to be made.  I don’t understand why people are so short sited to not realize that money that leaves the United States has little reason to come back.  I like to think of countries (read: economies) as bins of money.  People standing in our bin just keep throwing it into everybody else’s bins.  This is obviously from outsourcing jobs, but less obviously, even from charities (when you see those pictures of the ruined houses in Haiti and help build it up to ten times what it used to be, no one ever thinks about the fact that the money they donate is removed from our own economy).

As a “P.S.”, I don’t much get into politics or economics, so this opinion article may seem a bit simple to those better educated in those fields.

Follow

Get every new post delivered to your Inbox.