With the upcoming of the new Virtual Machines service on Microsoft Windows Azure, many server applications are going under testing and porting to cloud located machines. Today i tried to install a VisualSVN Server on Windows Server machines (both 2008 R2 and 2012) located in Windows Azure. The porting is quite simple and smooth and can be completed in less than half an hour. Since Azure VMs are persistent, all the installation and configuration can be performed directly on the remote machine simply using Remote Desktop Connection, without the need for any additional virtualization software. The only point that requires some attention is the correct setting of the Server URL inside VisualSVN Server, otherwise your SVN client will come to an abrupt halt immediately after setting up the connection due to a response containing misleading server information. The VisualSVN Server in fact sets by default its Server Name in the form https://[yourAzureVMName]:8443/svn/, missing part of the complete DNS name of the Azure VM. The correct URL that needs to be set is https://[yourAzureVMName].cloudapp.net:8443/svn/.
All the details can be found in this short QuickStartGuide. Hope it helps!
Yesterday I installed our desktop HealthVault (HV) application on a Tablet PC running Windows 7 (Acer Iconia W501).
When you start the application for the first time you have to provision it (authenticate). For this operation you are redirected to the HealthVault website by means of your default browser, where you have to enter your HV account in order to allow the application to access HV data (as shown in the images below).
Sometimes, after entering your username and your password you will be redirect to a blank page. If you refresh it (F5) and the page still remains blank, and if this behavior happens also if you are trying to access HV website directly from your browser, then probably there is a problem.
What is the problem?
Talking with Trey Troegel (from HV support) he told me to share the desktop to find the solution. So I installed Microsoft Lync on the tablet and when I tried to log on the Microsoft network I receive this error, that it was also the SOLUTION:
Yes. My computer clock wasn’t set correctly: 11th of November, instead of 10th of November 🙂
Maybe I made this mistake during the first boot installation of the tablet…. it happens!
I thought that this may affect the authentication process, so I changed the clock and I tried to log again to the HV website…. and finally the authentication worked.
In conclusion if you face this problem try to adjust your system clock… maybe this will solve your problem.
Thanks to Trey for his idea of installing Lync because he gave me the message error that was useful to solve this problem. Maybe it will be useful to receive this error message also from the website, instead of a blank page.
When developing a business application for Windows Azure, almost surely you end up creating custom build configurations to manage multiple deployment settings for the different stages of the development process. To do this VS2010 and Windows Azure SDK (from 1.4) offer some straightforward interfaces for the configurations management with an automatic update of the project files.
Unfortunately, in Windows Azure projects with web roles this process can cause some packaging and publishing problems on x86 machines. In fact after the set up of a new custom configuration, you may receive this build warning when creating the Azure deploy package:
“warning WAT160: The project ‘YourProject’ contains the following assembly: C:\Windows\assembly\GAC_32\msshrtmi\188.8.131.52__31bf3856ad364e35\msshrtmi.dll. This assembly is not compatible with the 64-bit processor architecture used by IIS on Windows Azure. To make sure that the role starts, you must replace this assembly with one that is compatible with this architecture.”
The reason for this warning is that the automatic project files updater creates the new configuration property group in the web project file (.csproj) from a template which includes a PlatformTarget element. The presence of this element forces the inclusion of the msshrtmi.dll, that on x86 machines is only 32-bit processors compatible.
Example configuration tag:
<PropertyGroup Condition=”‘$(Configuration)|$(Platform)’ == ‘Production|AnyCPU'”>
When deploying the packaged solution to Windows Azure the Web Roles containing the msshrtmi.dll library will not start properly.
Fortunately, the solution is quite simple: you should manually remove the PlatformTarget element from all the custom configurations properties in the web project file.
To solve this problem you have to:
- In Solution Explorer, right-click on your web project and select Unload Project
- Right click again and select Edit
- Delete all PlatformTarget elements
- Close the file and Reload Project by right clicking on the web project