Don't Upgrade to Windows Azure SDK 1.3 Yet
Friday, December 3, 2010 at 14:48Windows Azure SDK 1.3 released recently has a lot of features and some breaking changes.
My advice is to avoid upgrading your projects to it for now: there are too many problems, it is better to wait till Microsoft polishes this version.
However, if you have a day or two to invest - just give it a try. It could just work straight away or after a few fixes (some are listed below).
Some glitches were verified (i.e.: conditional header) some others are still blocking and outstanding (just browse Windows Azure forum for details).
For example, here's what I'm getting on a production project after the upgrade:
People report that launching without debugger leads to:
HTTP Error 503. The service is unavailable.
In my case we don't get that far - there is another problem - Lokad.CQRS settings provider (essentially a wrapper around RoleEnvironment and config settings) suddenly stopped retrieving settings from the Cloud runtime in this project. And debugging does not help since we can't attach debugger.
My wild guess is that .NET 4.0 runtime does not initialize properly on the Dev Fabric (Compute Emulator is the new name) for web workers (or communications are broken), so we can't retrieve azure-specific settings or attach debugger.
So if you are wondering about upgrading to Windows Azure 1.3 - don't do that, yet.
If you do, keep in mind that reverting back could be complicated, since Visual Studio upgrades your solutions (updating csconfig files) and references the new version of StorageClient (sometimes you need to do that manually).
Another tip: If you are using new Windows Azure Portal (Silverlight version) and have lots of errors - make sure to use use Internet Explorer with it. Otherwise you can get lot's of various problems and eventually crash Silverlight plugin. This was the case on my machine and the latest Chrome.
By the way, these problems were probably caused by good intentions - attempt to keep up with the promises of PDC'10. Microsoft teams have covered a big ground, essentially extending Windows Azure to be IaaS Cloud Computing Provider in addition to pure PaaS. It looks like they just need a bit more time.
Update - Sites Workaround
After publishing this blog post I've got a mixed feedback from the readers. Some of them had success with this release (esp. following the lines of Troubleshooting Azure Deployments or forcing Dev environment to use Hosted Web Core), some of them still were stuck with various problems.
I decided to install Azure SDK 1.3 one more time and invested another couple of hours into the problem. I was able to get a bit further: SEH Exception in Windows Azure Interop and partially frozen Visual Studio.
However, after forcing Visual Studio Azure Tools to use Hosted Web Core instead of IIS Web Site (this is done by manually editing ServiceDefinition.csdef file and deleting Sites section) I was able to start the project locally.
If you apply this workaround, then it is recommended to restore the section before publishing your project to the real cloud.
More details are available in one of MSDN Azure threads.
For now I'm rolling everything back to 1.2 again and still keep the recommendation to wait with Azure SDK 1.3 gets some fixes. I think it's not stable enough for the production.
Lokad.CQRS stays with 1.2 for now as well.
If you have some issues after deploying Windows Azure SDK and have some free time, please post them on Azure MSDN Forum or contact Steve Marx.
Quick FAQ on Azure SDK 1.3
Can ServiceDefinition.build.csdef be ignored by version control?
Probably, yes. It's auto-generated and I did ignore it.
What has caused so many troubles with Web Roles?
Web roles run using full IIS instead of Hosted Web Core. Additionally web.config is now modified more aggressively by Visual Studio (you might have problems if it is read-only).
BTW you can also try deleting Sites section in ServiceDefinition.csdef. This is supposed to force Hosted Web Core even 1.3 mode. The suggestion has been posted by Steve Marx on MSDN forums, but I didn't give it a try (already back to 1.2). If you do, please share your experience.
Since upgrading to SDK 1.3 I am unable to deploy
Try deploying locally. Make sure that web.config does not have any sections that are not known by Azure Guest OS (i.e.: uri web section). Make sure you are including all the referenced resources. If nothing helps - contact support.
I'm getting this message all the time: web.config file has been modified
Visual Studio is a bit aggressive with configs now. Just close the file in the editor.
Troubleshooting Azure Deployments
There also is a separate article outlining common Windows Azure Deployment problems and work-arounds. Some of these are highlighted by Microsoft, while the others come from our experience at Lokad. Check them out!
Reader Comments (10)
Check out this link to an MSDN resource for deployment issues with the latest bits in the 1.3 SDK.
http://msdn.microsoft.com/en-us/library/gg465402.aspx
I've been having a host of issues with 32-bit and 64-bit machines and getting good deployments into Windows Azure lately.
Adron, thanks for the comment. I'm aware of these problems and workarounds.
Actual deployments are not a problem - we've been doing them on a regular basis in various configurations. However 1.2->1.3 just happened to break everything. Your mileage may vary, of course.
Wish I'd read this post about 6 hours ago.
Things are just generally "broken" here at present - trying to work out what. Will maybe try to head back to 1.2 soon.
Stuart, could you, please, provide more details on the things that are broken for you?
No major issues with 1.3 for us. I had to manually patch up StorageClient refs as ended up with a mismatch between projects causing a blowup in Azure.
RDP and Full IIS (rather than Hostable Web Core) were worth taking the plunge. Full IIS so we can upload files larger than 100MB.
Dave,
Thank you for the comment! I'm glad you had a successful experience.
I've reworded beginning of this post to encourage developers to give SDK 1.3 a try, if they have a bit of time to spare.
Wish I'd read this post about 3 hours ago.
I'm facing the trouble about deployment. When I try to deploy the package, it fails (Status turns to "Abort").
The same package did work on 1.2 SDK.
I have no idea to work it out.
Dev Takacs, I would recommend to contact Windows Azure support and provide them with the deployment ID for debugging. It's really hard to figure out otherwise.
Another option is to roll back to 1.2 and see if it still works.
I would love to hear, how this works out for you in the end. Good luck!
Dear Rinat,
Thank you for your reply.
It works when rolled back to 1.2.
For now I don't need the 1.3 features, so I have decided to keep using 1.2 in the end.
Unfortunately I don't have enough time to make contact.
But thinking about Windows Azure Connect, I will have to upgrade to 1.3 sooner or later.
If I would face the same problem, I would contact Windows Azure support.
Thanks again.
Rinat - I've hit deployment issues, I've hit documented issues with "Deleting" and then "Creating" containers causing new errors, I've had one solution which only half automatically upgraded, I've lost diagnostics (because I didn't notice that they're now configured differently) and I've now hit another random issue - which I'm not yet sure what the cause is. It's only 5 or 6 problems total... but they were problems I hadn't really anticipated in my time estimates.
Despite the problems, I am glad to see the storageclient move forwards - e.g. it's much better that the code now throws an exception when you try to "delete" and then "create" a blob container with the same name - much better than the previous "silent" failure which masked the underlying problem