Visual Studio Hang developing SharePoint-hosted App
Over here at WTF HQ, we’re trying out some App Parts. Great, except that my normally patient & docile colleague is literally moments away from plunging his fist knuckle deep into his monitor.
App Part Architecture
App parts are pretty simple, really — an iframe web part with some initialization goo on a SharePoint page. It calls your server (provider hosted), an Azure server (autohosted) or an app web on your SharePoint infrastructure (SharePoint-hosted) and that’s about it. There’s some limited interactivity between app part & host page (and I mean limited), but not much. It’s good for…well, something. I’m not quite sure yet. But I’ll let you know.
Srsly, why so limited?
In theory, the app part really shouldn’t be so limited, but Microsoft has declared it so. Here’s how it works:
HTML5 has a nifty thing called postMessage — it lets an iframe send a message to its host page. Cool, except that the event listener has to be registered in the host page. Microsoft has gone to the liberty of doing this, giving us…one event listener: resize. Yes, ladies and gentlemen, we are on the brink of technical excellence here. It wouldn’t be so bad if they’d let us register new ones, but alas, we cannot. So it really doesn’t do much.
That’s not the point.
So, back to Visual Studio hanging every thirty seconds while developing a SharePoint-hosted app. We tried this with a few different scenarios, but any SharePoint-hosted app would just make the machine useless. Time for Fiddler.
I couldn’t replicate his troubles on my machine, but rather than lose a limb in a tragic monitor-punching accident, I elected I should look in. Here’s what we found.
First, Intellisense Is Cray
I turned on fiddler & couldn’t get anything bad to happen…but then I started typing a
<script> tag and this happened:
Cool, huh? Not really. Especially since a good portion of those files don’t even exist. But that’s not what was causing the full-blown UI hangs…
HTTP & HTTPS Script Tags
Writing in Office 365 is interesting, because you’re always bouncing back and forth between HTTP & HTTPS — HTTP on the public site, HTTPS on the private site and when authenticated to the public site. Because of this, we use protocol-free script tags from CDNs. Like this one:
Note there’s no ‘http’ or ‘https’ listed — this way, the browser will use whatever protocol you’re currently connected on. This really is cool and incredibly useful.
That is, of course, until you factor in WebDAV, that old creaky protocol for fetching files over the web. Some deeper inspection of our previous
<script> tag Fiddler explosion above gave us some insight into what was going on — not only was Visual Studio trying HTTP, it was trying WebDAV, sending OPTIONS requests to the ASP.net CDN:
The fact that we’ve all been happily coding along in MVC for months/years without this ever happening leads me to believe it has something to do with the SharePoint project type, perhaps the fact that so many files are available over WebDAV with SharePoint.
Solution? There really isn’t one.
- Develop to a local SharePoint server, at least then the latency won’t be too annoying.
- Swap out http(s) with some server-side variables
- just use one or the other for debugging…but remember to change before publish!