Category Archives: visual studio

Hands on debugging an Azure application – what to do when it works locally but not in the cloud

I have been writing a Facebook application hosted on Microsoft Azure. I hit a problem where my application worked fine on the local development fabric, but failed when deployed to Azure. The application was not actually crashing; it just did not work as expected. Specifically, either the Facebook authentication or the ASP.NET Forms Authentication was failing; when I tried to log on, the log on failed.

This scenario, where the app works locally but not on Azure, is potentially a bad one because you do not have the luxury of breakpoints and variable inspection. There are several approaches. You can have the application write a log, which you could download or view by using Remote Desktop to the Azure instance. You can have the application output debug messages to HTML. Or you can use IntelliTrace.

I tried IntelliTrace. It is easy to set up, just check the box when deploying.

image

Once deployed, I tried the application. Clicked the Log On button, after which the screen flashed but still asked me to Log On. The log on had failed.

image

I closed the app, opened Server Explorer in Visual Studio, drilled down into the Windows Azure Compute node and selected View IntelliTrace Logs.

image

The logs took a few minutes to download. Then you can view is the IntelliTrace log summary, which includes a list of exceptions. You can double-click an exception to start an IntelliTrace debug session.

image

Useful, but I still could not figure out what was wrong. I also found that IntelliTrace did not show the values for local variables in its debug sessions, though it does show exceptions in detail.

Now, if you really want to debug and trace an Azure application you had better read this MSDN article which explains how to create custom debugging and trace agents and write logs to Azure storage. That seems like a lot of work, so I resorted to the old technique of writing messages to HTML.

At this point I should mention something you must do in order to debug on Azure and remain sane.  This is to enable WebDeploy:

image

It is not that hard to set up, though you do need to enable Remote Desktop which means a trip to the Azure management portal. In my case I am behind a firewall so I needed to configure Web Deploy to use the standard SSL port. All is explained here.

Why use Web Deploy? Well, normally when you deploy to Azure the service actually builds, copies and spins up a new virtual machine image for your app. That process is fundamental to Azure’s design and means there are always at least two copies of the VM in existence. It is also slow, so if you are making changes to an app, deploying, and then testing, you will spend most of your time waiting for Azure.

Web Deploy, by contrast, writes to your existing instance, so it is many times quicker. Note that once you have your app working, it is essential to deploy it properly, since Azure might revert your app to the last VM you created.

With Web Deploy enabled I got back to work. I discovered that FormsAuthentication.SetAuthCookie was not working. The odd thing being, it worked locally, and it had worked in a previous version deployed to Azure.

Then I began to figure it out. My app runs in a Facebook canvas. Since the app is served from a different site than Facebook, cookies may be rejected. When I ran the app locally, the app was in a different IE security zone, so different rules applied.

But why had it worked before? I realised that when it worked before I had used Google Chrome. That was it. IE worked locally; but only Chrome worked when deployed.

I have given up trying to fix the specific problem for the moment. I have dug into it a little, and discovered that cookie handling in a Facebook canvas with IE is a long-standing problem, and that the Facebook C# SDK may have bugs in this area. It is not essential for my sample; I have found I can get by with the Facebook session. To get the user ID, for example:

FacebookWebContext.Current.Session.UserId

The time has not been wasted though as I have learned a bit about Azure debugging. I was also amused to discover that my Azure VM has activation problems:

image

The frustration of developing for Facebook with C#

I am researching a piece on developing for Facebook with Microsoft Azure, and of course the first thing I did was to try it out.

It is not easy. The first problem is that Facebook does not care about C#. There are four SDKs on offer: JavaScript, Apple iOS, Google Android, and PHP. This has led to a proliferation of experimental and third-party SDKs which are mostly not very good.

The next problem is that the Facebook API is constantly changing. If you try to wrap it neatly in an SDK, it is likely that some things will break when the next big change comes along.

This leads to the third problem, which is that Google may not be your friend. That helpful article or discussion on developing for Facebook might be out of date now.

Now, there are a couple of reasons why it should be getting better. Jim Zimmerman and Nathan Totten at Thuzi (Totten is now a technical evangelist at Microsoft) created a new C# Facebook SDK, needing it for their own apps and frustrated with what was on offer elsewhere. The Facebook C# SDK looks like it has some momentum.

C# 4.0 actually works well with Facebook, thanks to the dynamic keyword, which makes it easier to cope with Facebook’s changes and also lets it map closely to the official PHP SDK, as Totten explains.

Nevertheless, there are still a few problems. One is that documentation for the SDK is sketchy to say the least. There is currently no reference for it on the Codeplex site, and most of the comments are the kind that produces impressive-looking automatic documentation but actually tells you nothing of substance. Plucking one at random:

FacebookClient.GetAsync(System.Collections.Generic.IDictionary<string,object>)

Summary:
Makes an asynchronous GET request to the Facebook server.

Parameters:
parameters: The parameters.

Another problem, inherent to dynamic typing, is that IntelliSense (auto-completion in Visual Studio) has limited value. You constantly need to reference the Facebook documentation.

Finally, the SDK has changed quite a bit in different versions and some of the samples reference old versions.

In particular, I found it a struggle getting OAuth authentication and access token retrieval working and ended up borrowing Totten’s sample code here which mostly works – though note that the code in the sample does not cope with the same users logging out and logging in again; I fixed this by changing his InMemoryUserStore to use a ConcurrentDictionary instead of a ConcurrentBag, though there are plenty of other ways you can store users.

I’m puzzled why Microsoft does not invest more in making this easier. Microsoft invested in Facebook and it is easy to get the impression that Microsoft and Facebook are in some sort of informal alliance versus Google. Windows Phone 7, for example, ties in closely with Facebook and is probably the best Facebook phone out there.

As it is, although I prefer coding in C# to PHP, I would say that choosing PHP as the platform for your Facebook app will present less friction.

ReSharper 6.0 arrives: intelligent editing and decompiling for Visual Studio

JetBrains has released ReSharper 6.0, an add-on for Visual Studio 2008 and 2010 that delivers a remarkable range of tools, mostly focused on code editing and static analysis. There is also a unit test runner and a source code decompiler.

The heart of ReSharper is refactoring, hence the name, and it adds a large number of refactoring options to Visual Studio. These are nicely integrated with the editor, not only as right-click menu options, but with light-bulb suggestions that appear automatically. Here, for example, ReSharper is telling me that I could use implicit type declaration, and offering to make the change for me, or alternatively to suppress this type of suggestion forever if I do not like it:

image

Source code decompiling is also nicely done. In the above code, IClaimsIdentity is part of the .NET Framework so the source code is not normally available. With ReSharper though, I can navigate to decompiled source:

image

This could be legally sensitive, so I have to pass a Decompiler Legal Notice in which JetBrains attempts to disclaim liability.

image

Then I am in, though the results are not exciting in this instance:

image

If you only want the decompiler, you may find the free dotPeek is all you need.

The what’s new list in ReSharper 6.0 is long. It includes support for JavaScript, ASP.NET Razor, CSS and HTML, better XAML support including creating properties and dependency properties from usage, and macros for file headers which automates things like inserting current date and time.

The pricing is not excessive: in the UK it costs £148 for a personal license or £259 for a commercial license. If you think ReSharper will save you time and improve your code quality, which it likely will, it will soon pay for itself.

Microsoft Office 365: the detail and the developer story

I attended the UK launch of Office 365 yesterday and found it a puzzling affair. The company chose to focus on small businesses, and what we got was several examples of customers who had discovered the advantages of storing documents online. We were even shown a live video conference with a jerky, embarrassing webcam stream adding zero business value and reminding me of NetMeeting back in 1995 – which by the way was a rather cool product. Most of what we saw could have been done equally well in Google Apps, except for a demo of the vile SharePoint Workspace for offline editing of a shared document, though if you were paying attention you could see that the presenter was not really offline at all.

There seems to be a large amount of point-missing going on.

There is also a common misconception that Office 365 is “Office in the cloud”, based on Office Web Apps. Although Office Web Apps is an interesting and occasionally useful feature, it is well down the list of what matters in Office 365. It is more accurate to say that Office 365 is for those who do not want to edit documents in the browser.

I am guessing that Microsoft’s focus on small businesses is partly a political matter. Microsoft has to offer an enterprise story and it does, with four enterprise plans, but it is a sensitive matter considering Microsoft’s relationship with partners, who get to sell less hardware and will make less money installing and maintaining complex server applications like Exchange and SharePoint. The, umm, messaging at the Worldwide Partner Conference next month is something I will be watching with interest.

The main point of Office 365 is a simple one: that instead of running Exchange and SharePoint yourself, or with a partner, you use these products on a multi-tenant basis in Microsoft’s cloud. This has been possible for some time with BPOS (Business Productivity Online Suite), but with Office 365 the products are updated to the latest 2010 versions and the marketing has stepped up a gear.

I was glad to attend yesterday’s event though, because I got to talk with Microsoft’s Simon May and Jo Carpenter after the briefing, and they answered some of my questions.

The first was: what is really in Office 365, in terms of detailed features? You can get this information here, in the Service Description documents for the various components. If you are wondering what features of on-premise SharePoint are not available in the Office 365 version, for example, this is where you can find out. There is also a Support Service Description that sets out exactly what support is available, including response time objectives. Reading these documents is also a reminder of how deep these products are, especially SharePoint which is a programmable platform with a wide range of services.

That leads on to my second question: what is the developer story in Office 365? SharePoint is build on ASP.NET, and you can code SharePoint applications in Visual Studio and deploy them to Office 365. Not all the services available in on-premise SharePoint are in the online version, but there is a decent subset. Microsoft has a Sharepoint Online for Office 365 Developer Guide with more details.

Now start joining the dots with technologies like Active Directory Federation Services – single sign-on to Office 365 using on-premise Active Directory – and Windows Azure which offers hosted SQL Server and App Fabric middleware. What about using Office 365 not only for documents and email, but also as a portal for cloud-hosted enterprise applications?

That makes sense to me, though there are still limitations. Here is a thread where someone asks:

Does some know if it is possible to make a database connection with Office365, SharePoint (Designer) and SQL Azure database ?

and the answer from Microsoft’s Mark Kashman on the SharePoint team:

You cannot do this via SharePoint Designer today. What you can do is to create a Silverlight or javaScript client application that calls out to SQL Azure.

In the near future, we are designing a way to make these connections using the base SharePoint technology called BCS (Business Connectivity Services) where then you could develop a service to service to SQL Azure.

If you cannot wait, check out the Cloud Connector for SharePoint 2010 from Layer 2 GmbH.

It seems obvious that Office 365 and Azure together have potential as a developer platform.

What about third-party applications and extensions for Office 365? This is another thing that Microsoft did not talk about yesterday; but it seems to me that there is potential here as well. It is not well integrated, but you can search Microsoft Pinpoint for Office 365 applications and get some results. If Office 365 succeeds, and I think it will, there is an opportunity for developers here.

Hands On with Appcelerator Titanium Studio

I spent some time today trying out Appcelerator’s new Titanium Studio. Titanium is a cross-platform framework that lets you compile apps for Apple iOS, Google Android, RIM Blackberry, and desktop operating systems. Its chief attraction is the mobile aspect, particularly as it claims to build “native apps”.

I am thoroughly bored of writing calculator apps, but having embarked on this this test case I am keeping going since it makes it easier to compare one with another. I started by writing it for Android on Windows. I had some setup issues, but once resolved it pretty much worked, though the development process was fairly painful.  There is no visual GUI designer and my calculator has quite a few buttons, so I ended up counting pixels and trying out my work by debugging in the emulator. Performing a build and running in the emulator is a lengthy operation, so this is a tedious way to work. Come back Visual Studio, all is forgiven!

I persevered though, and eventually had my calculator up and running on my HTC Desire.

image

The design could be improved; but it is good enough for my purpose. Unfortunately though the GUI is not as responsive as I would like. It is easy to lose taps if you tap a little too fast, which is a serious flaw in a calculator. In this respect, the Titanium build is better than the PhoneGap/JQuery app I built, but still not good enough for a production app.

Time to port to iOS. Here I ran into a number of difficulties. I installing Titanium Studio on a Mac, copied the project from Windows and tried to open it. Titanium Studio complained about the absence of the Android SDK and eventually froze trying to fully initialize the workspace. Force Quit, delete the project, and try again. This time I created a new project and just copied over the app.js file that has my source code. Titanium Studio was happier; but the app would not open in the iOS Simulator.

The problem: I have installed the latest Xcode and IOS 5.0 beta SDK. Even if you target iOS 4.x, Titanium is not quite compatible. However, my iPhone is still on iOS 4.3, and I was able to deploy the app to the device. Unfortunately the GUI was scrambled. This is how it looked:

image

Not good. Eventually I worked out the problem. On Titanium for Android there is no need to specify the height of buttons and labels; this automatically sizes to the content. On iOS though, if you do not specify the height it stretches the object from whatever you specify as top down to the bottom of the container.

I added height attributes to sort out the GUI, though I am still scratching my head over one issue. I specified a different value for the top attribute of a label and a button, but they were rendered at the same vertical position. Odd. I simply compensated for this and ended up with a workable GUI. Here it is on the iPhone:

image

The good news: this is by far the best performing of all the cross-platform solutions I have tried. I cannot out-tap it, and it would be fine in this respect for a production app.

Note that attempting to debug using the community edition raises this message:

image

No debugging without a subscription; a strong incentive to subscribe.

It is also worth noting that you can open the project generated by Titanium in Xcode. I wondered if that might shed light on the compatibility issues. It is an interesting thing to try, as you see the innards of Titanium’s code, complete with a number of reported issues.

image

I also get this:

image

Still, time to wrap up. I am impressed with the performance of my app on the iPhone, but disappointed on Android. On the other hand, the whole point of Titanium is to achieve cross-platform, otherwise you might as well use Objective C. Of course there may be ways to improve the performance; I just dived in and tried out the tool without chasing up possible optimisations.

Common sense on Windows 8, Silverlight and .NET

I am wary about writing another post on this subject in the absence of any further news, but since there is a lot of speculation out there I thought it would be worth making a few further observations.

Will Windows 8 support Silverlight and/or some other variety of .NET in its new touch-centric mode? I will be astonished if it does not. Aside from other considerations, this is an essential unifying piece between the Windows Phone 7 developer platform and the Windows 8 developer platform, which from what we have seen have a similar user interface. For further evidence, try an internet search for “Jupiter” and “appx”.

Why isn’t Microsoft already shouting about this? A good question. Part of the answer is that Microsoft wants to get developers enthused about the forthcoming build conference in September, and is holding back information.

Another part of the answer is that Windows historically has kept .NET as a layer above the operating system, rather than as part of it. We saw this in Windows 7, where to take advantage of new features like jump lists or thumbnail toolbars, .NET developers had to use a supplementary Windows API Code Pack. The Windows team delivered only native code or COM APIs.

Admittedly, there are differences this time around. The Windows team is not just delivering native code APIs, but also an HTML and JavaScript API. This is a break with the past, hence the talk of a new platform.

When it comes to desktop applications, would not Silverlight or something .NET based be a better choice than HTML5? I can see both sides of this. On one side is all the effort Microsoft has invested in .NET and Silverlight over the past decade. As I’ve noted before, I see Silverlight as what client-side .NET should have been from the beginning, lightweight, secure, simple installation, but with support for C# and much of the .NET Framework which developers know so well.

On the other hand, I can see Microsoft wanting to tap into the wave of HTML5 development and to make it easy for web developers to build apps for Windows 8.

In the end, developers will most likely have the choice. That puts pressure on Microsoft’s developer division to provide strong tools for two different development models; but I think that is what we will get.

Is .NET itself under threat? As far as I am aware, Microsoft has no plan “B” in terms of web and application server technology, and its Azure cloud is largely a .NET platform though there are are efforts to support other things like PHP and Java. Further, this aspect of the Microsoft Platform is under Server and Tools which is 100% behind .NET as far as I can tell. We have also seen Silverlight crop up in the user interfaces for new server products like InTune and System Center. On the server then, there is no evidence for .NET doubts at Microsoft; and considering the trend towards cloud+device computing the server is now at the heart of most business application development.

That said, Microsoft has challenges in sustaining .NET momentum. It cannot afford to fail with Azure, yet other platforms such as Amazon EC2 have greater developer mindshare as cloud computing platforms. VMWare with its Java-based Spring framework is another key competitor. Microsoft was late to the server virtualisation party with Hyper-V. I also see declining market share for IIS versus Apache in Netcraft’s statistics, although these figures are distorted by millions of little-used domains that get shunted from one platform to another by major hosting providers.

Further, it seems to me that the fortunes of .NET on the server cannot be completely separated from what happens on the client. One of the attractions of .NET is the integration between client and server, with Visual Studio as the tool for both. Windows has lost momentum to Apple in mobile, in tablets, and in high-end laptops, making Windows-only clients less attractive. In that context, the decision of the Windows team to favour HTML5 over .NET is a blow, in that it seems to concede that the future client is cross-platform, though I expect there will be some sort of outcry when we see all the proprietary hooks Microsoft has implemented to get HTML5 apps integrated into Windows 8.

Therefore these really are difficult times for .NET. I do not count Microsoft out though; it still dominates business computing, and amongst consumers the Xbox may prove an important new platform as Tom Warren notes.

While I have reservations about Windows 8, it does demo nicely as a new touch-centric operating system and Microsoft surely has chances in the corporate world with new-style tablets that integrate with its system management tools and which run Microsoft Office.

Finally, the angst over the role of .NET in Windows 8 shows that many developers actually like the platform, including Visual Studio, the C# language, the .NET Framework, and XAML for building a rich user interface.

Gang of Four member Erich Gamma joining Microsoft’s Visual Studio team

Microsoft’s Jason Zander has announced

that Erich Gamma will be joining the Visual Studio team as a Microsoft Distinguished Engineer

Gamma is one of the “Gang of Four” who shook up software development back in 1994 with the book Design Patterns: Elements of Reusable Object-Oriented Software.

The other authors are Richard Helm, Ralph Johnson and John Vlissides.

Gamma has previously been associated with Java rather than .NET. He was co-developer with Kent Beck of the JUnit unit test framework, and also worked on the Eclipse tools platform and at IBM Rational on application lifecycle management (ALM).

It is a prestigious hire and I would expect Gamma’s influence on Visual Studio to be a positive one, especially in areas like software quality, refactoring and ALM.

Considering Windows 8 as an HTML platform

Amongst all the fuss about whether Microsoft is deprecating Silverlight or even client-side .NET, it is easy to lose sight of the other angle on this. What are the implications of Microsoft embracing HTML and JavaScript as a new first-class Windows development platform? Here’s the quote again:

Today, we also talked a bit about how developers will build apps for the new system. Windows 8 apps use the power of HTML5, tapping into the native capabilities of Windows using standard JavaScript and HTML to deliver new kinds of experiences. These new Windows 8 apps are full-screen and touch-optimized, and they easily integrate with the capabilities of the new Windows user interface.

When Microsoft introduced IE9 with hardware-accelerated graphics, support for some key parts of HTML 5, and a new fast JavaScript engine, it was not only trying to recover ground in the browser wars. It also had in mind a new application runtime for Windows, for desktop as well as for web applications.

In order to achieve this, we can expect more hooks between the browser engine and the local operating system. There is potential security risk, but Microsoft of all companies will be sensitive to this and I would expect it to get the security right. The further implication is that some parts of a Windows HTML application will be Windows-specific. It is an “Embrace and extend” strategy, as I noted in this Register article back in September last year when former Silverlight product manager Scott Barnes broke the story of how the Windows team at Microsoft was favouring HTML and JavaScript above .NET.

The rationale for this is two-fold. First, I’m guessing that Microsoft thinks it will work better. Although .NET client apps are now commonplace, especially for custom business applications, problems like slow start-up and heavy memory requirements never really went away, though I would argue that in Silverlight they are almost eliminated.

Second, HTML and JavaScript is a universal programming platform. With the new model, any developer who can code a web page can also code a Windows app. Corporate VP Michael Angiulo said at Computex in Taipei:

Windows 8’s new application platform … is based on HTML 5, JavaScript and CSS, the most widely understood programming languages of all time. These languages form the backbone of the web, so that on day 1 when Windows 8 ships hundreds of millions of developers will already know how to build great apps for Windows 8.

These are both compelling arguments. Nevertheless, there are several reasons why making Windows an HTML platform might not be the instant hit that Microsoft will be hoping for. Here are a few:

  • Microsoft’s Visual Studio is .NET oriented. It does have a web design tool, Expression Web, which is OK but still falls short compared to Adobe Dreamweaver. Web designers tend to use Dreamweaver anyway, thanks to Mac compatibility and integration with other Adobe tools. Even Dreamweaver is not great as an application development tool, as opposed to a web design tool. Tooling is a problem, and it is fair to say that whatever goodies Microsoft comes up with in this area will likely be a step back compared to what it already has for C# or C++.
  • Standards are a mixed blessing if you are trying to sell an operating system. If Microsoft does such a good job of standards support that the same apps run with minor tweaks on an iPad and on Android, users may do just that. If Microsoft encumbers the standards with too many proprietary extensions, the universality of the platform is lost.
  • Windows plus HTML and JavaScript sounds a lot like Palm/HP WebOS, which has gained favourable reviews but has yet to take off in terms of sales. Otherwise, Palm would not have been taken over by HP.
  • The question of whether HTML and JavaScript will really take over app development is open. I certainly hear voices saying so. I interviewed Nitobi’s president André Charland, in charge of PhoneGap, and he makes a good case. On the other hand, App development today is still dominated by platform-specific development, Objective C for Apple iOS and Java on Dalvik, the Google Android virtual machine.
  • The standard in HTML/JavaScript app platforms is not Microsoft’s Internet Explorer, but WebKit, as used in iOS and in Google Android and Chrome. Microsoft did great work in standards support in IE9, but so far it has not stopped its browser share decline. Worldwide figures from StatCounter show Internet Explorer in continuing slow decline overall, and Chrome still growing and set to overtake Firefox in a year or so.

In other words, there is little evidence that embracing HTML and JavaScript as an app platform will ensure success for Windows 8.

That said, other factors count for more. Developers will go where their customers are, and if Microsoft turns out a version of Windows that wins substantial market share in the emerging tablet market as well as on traditional notebooks, the new platform will be a hit.

The risk though is that the market will continue to perceive Windows as an OS for desktop and laptop, and look to iOS or Android for mobile and touch devices. The dual personality of Windows 8 may count against it, if it means devices that are compromised by having to support both user interface models.

Microsoft refuses to comment as .NET developers fret about Windows 8

There is a long discussion over on the official Silverlight forum about Microsoft’s Windows 8 demo at D9 and what was said, and not said; and another over on Channel 9, Microsoft’s video-centric community site for developers.

At D9 Microsoft showed that Windows 8 has a dual personality. In one mode it has a touch-centric user interface which is an evolved version of what is on Windows Phone 7. In another mode, just a swipe away, it is the old Windows 7, plus whatever incremental improvements Microsoft may add. Let’s call it the Tiled mode and the Classic mode.

Pretty much everything that runs on Windows today will likely still run on Windows 8, in its Classic mode. However, the Tiled mode has a new development platform based on HTML and JavaScript, exploiting the rich features of HTML 5, and the fast JavaScript engine and hardware acceleration in the latest Internet Explorer.

Although D9 is not a developer event, Microsoft did talk specifically about this aspect. Here is the press release:

Today, we also talked a bit about how developers will build apps for the new system. Windows 8 apps use the power of HTML5, tapping into the native capabilities of Windows using standard JavaScript and HTML to deliver new kinds of experiences. These new Windows 8 apps are full-screen and touch-optimized, and they easily integrate with the capabilities of the new Windows user interface. There’s much more to the platform, capabilities and tools than we showed today.

Program Manager Jensen Harris says in the preview video:

We introduced a new platform based on standard web technologies

Microsoft made no mention of either Silverlight or .NET, even though Silverlight is used as the development platform in Windows Phone 7, from which Windows 8 Tiled mode draws its inspiration.

The fear of .NET developers is that Microsoft’s Windows team now regards not only Silverlight but also .NET on the client as a legacy technology. Everything will still run, but to take full advantage of Tiled mode you will need to use the new HTML and JavaScript model. Here are a couple of sample comments. This:

My biggest fears coming into Windows 8 was that, as a mostly WPF+.NET developer, was that they would shift everything to Silverlight and leave the FULL platform (can you write a Visual Studio in Silverlight? of course not, not designed for that) in the dust. To my utter shock, they did something much, much, much worse.

and this:

We are not Windows developers because we love Windows. We put up with Windows so we can use C#, F# and VS2010. I’ve considered changing the platform many times. What stops me each time is the goodness that keeps coming from devdiv. LINQ, Rx, TPL, async – these are the reasons I’m still on Windows.

Underlying the discussion is that developers have clients, and clients want applications that run on a platform with a future. Currently, Microsoft is promoting HTML and JavaScript as the future for Windows applications, putting every client-side .NET developer at a disadvantage in those pitches.

What is curious is that the developer tools division at Microsoft, part of Server and Tools, has continued to support and promote .NET; and in fact Microsoft is soon to deliver Visual Studio LightSwitch, a new edition of Visual Studio that generates only Silverlight applications. Microsoft is also using Silverlight for a number of its own web user interfaces, such as for Azure, System Center and Windows InTune, as noted here.

Now, I still expect that both Silverlight and native code, possibly with some new XAML-based tool, will be supported for Windows 8 Tiled mode. But Microsoft has not said so; and may remain silent until the Build conference in September according to .NET community manager Pete Brown:

You all saw a very small technology demo of Windows 8, and a brief press release. We’re all being quiet right now because we can’t comment on this. It’s not because we don’t care, aren’t listening, have given up, or are agreeing or disagreeing with you on something. All I can say for now is to please wait until September. If we say more before then, that will be great, but there are no promises (and I’m not aware of any plans) to say more right now. I’m very sorry that there’s nothing else to share at the moment. I know that answer is terrible, but it’s all that we can say right now. Seriously.

While this is clearly not Brown’s fault, this is poor developer communication and PR from Microsoft. The fact that .NET and Silverlight champion Scott Guthrie is moving to Windows Azure is no comfort.

The developer division, and in fact the whole of Server and Tools, has long been a bright spot at Microsoft and among its most consistent performers. The .NET story overall includes some bumps, but as a platform for business applications it has been a remarkable success. The C# language has evolved rapidly and effectively under the guidance of Technical Fellow Anders Hejlsberg. It would be bewildering if Microsoft were to turn its back on .NET, even if only on the client.

In fact, it is bewildering that Microsoft is being so careless with this critical part of its platform, even if this turns out to be more to do with communication than technical factors.

From the outside, it still looks as if Microsoft’s server and tools division is pulling one way, and the Windows team the other. If that is the case, it is destructive, and something CEO Steve Ballmer should address; though I imagine that Steven Sinofsky, the man who steered Windows 7 to launch so successfully, is a hard person to oppose even for the CEO.

Update: Journalist Mary Jo Foley has posted on what she “hears from my contacts” about Jupiter:

Jupiter is a user interface library for Windows and will allow developers to build immersive applications using a XAML-based approach with coming tools from Microsoft. Jupiter will allow users a choice of programming languages, namely, C#, Visual Basic and C++.

Jupiter, presuming her sources are accurate, is the managed code platform for the new Windows shell – “Tiled mode” or “Tailored Apps” or “Modern Shell – MoSH”; though if that is the case, I am not sure whether C++ in this context will compile to managed or unmanaged code. Since Silverlight is already a way to code using XAML, it is also not clear to me whether Jupiter is in effect a new Windows-only version of Silverlight, or yet another approach.

Cracks appear in Microsoft’s bundled installers for Visual Studio 2010 as I try ADFS

I am trying out Microsoft Active Directory Federation Services (ADFS), chasing the dream of single sign-on between on-premise Active Directory and the cloud.

Oddly, although ADFS has been around for a while, it feels more bleeding edge than it should. ADFS is critical to Microsoft’s cloud platform play, and it needs to build this stuff right into Windows Server and .NET rather than making it a downloadable add-on.

The big problem with installers, whether on Windows or elsewhere, is dependencies and versions. You get some variant of DLL Hell, when A requires the latest version of B, and C requires an old version of B, and you need both A and C installed. The issue on Windows has reduced over the years, partly because of more side-by-side installations where multiple versions co-exist, and partly because Microsoft has invested huge effort into its installers.

There are still issues though, and I ran into a few of them when trying ADFS. I have Visual Studio 2010 installed on Windows 7 64-bit, and it is up-to-date with Service Pack 1, released in April. However, after installing the Windows Identity Foundation (WIF) runtime and SDK, I got this error when attempting to start Visual Studio:

image

Only some of the Microsoft Visual Studio 2010 products on this computer have been upgraded to Service Pack 1. None will work correctly until all have been upgraded.

I’m guessing that the WIF components have not been updated to take account of SP1 and broke something. Never mind, I found my Visual Studio SP1 .ISO (I avoid the web installs where possible), ran setup, and choose to reapply the service pack. It trundled along until it decided that it needed to run or query the Silverlight 4 SDK setup:

image

A dialog asked for silverlight_sdk.msi. I wasted some time over this. Why is the installer looking for silverlight_sdk.msi in a location that does not exist? I’d guess because the Silverlight SDK installer is wrapped as an executable that unpacked the MSI there, ran it and then deleted it. Indeed, I discovered that both the Silverlight 4 SDK and the Silverlight 4 Tools for Visual Studio are .EXE files that wrap zip archives. You can rename them with a .zip or .7z extension and extract them with the open source 7 Zip, but not for some reason with the ZIP extractor built into Windows. Then you can get hold of silverlight_sdk.msi.

I did this, but then discovered that silverlight_sdk.msi is also on the Visual Studio SP1 ISO. All I needed to do was to point the installer there, though it is odd that it cannot find the file of its own accord.

It also seems to me that this scenario should not occur. If the MSI for installation A might be needed later by installation B, it should not be put into a temporary location and then deleted.

The SPI repair continued, and I got a reprise of the same issue but with the Visual C++ runtimes. The following dialog appeared twice for x86, and twice for x64:

image

These files are also on the SP1 .ISO, so I pointed the installer there once again and setup continued.

Unfortunately something else was wrong. After a lengthy install, the SP1 installer started rollback without so much as a warning dialog, and then exited declaring that a fatal error had occurred. I looked at the logs

I rebooted, tried again, same result.

I was about to trawl the forums, but thought I should try running Visual Studio 2010 again, just in case. Everything was fine.

image

Logic tells me that the SP1 “rollback” was not quite a rollback, since it fixed the problem. Then again, bear in mind that it was rolling back the reapplication of the service pack which is different from the usual rollback scenario.

Visual Studio, .NET, myriad SDKs that each get updated at different times, developers who download and install these in an unpredictable order … it is not surprising that it goes wrong sometimes; in fact it is surprising that it does not go wrong more often. So I guess I should not beat up Microsoft too much about this. Even so this was an unwelcome reminder of a problem I have not seen much in the last few years, other then with beta installs which play by different rules.