Windows Azure SDK 1.3 Refresh

by Rok Bermež 2. February 2011 19:09
Due to numerous bugs, the 'hotfix' for SDK was released recently. I havent tried it yet but sure hope that some annoying things will go away. "The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state" really is a mood killer. Hope for the best and upgrade here. (32 bit version also available here)

Tags:

.Net | Azure

Dev Web Server for Azure Web Roles

by Rok Bermež 27. January 2011 13:17
Windows Azure uses 64 bit architecture so all dlls deployed to it must also be 64 bit. This poses significat development problem since 'Visual Studio Development Server'  and IIS Express run in 32 bit process. You can always use complete IIS, but it would be better if there was something more lightweight. It turns out there is. There is a nice project on codeplex called "CassiniDev - Cassini 3.5/4.0 Developers Edition" available here. Its binaries are also 32 bit so be sure to get the source and change Build platform target to either 'Any CPU' or 'x64'    and rebuild solution. After that just replace contents of 'C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0' folder with your new freshly build 64 bit capable dev server  

Tags:

Azure | IIS | Visual Studio | Web

MVC3 Windows Azure Deployment

by Rok Bermež 14. January 2011 12:12
For RTM version of MVC 3 make sure the deployment contains following dlls: Microsoft.Web.Infrastructure System.Web.Helpers System.Web.Mvc System.Web.Razor System.Web.WebPages System.Web.WebPages.Deployment System.Web.WebPages.Razor  

Tags:

ASP.NET | Azure | mvc

Windows Azure Full IIS

by Rok Bermež 10. January 2011 23:00
Some time ago I wrote how to deploy multitenant application to the Cloud. The process was tricky at best. With new Windows Azure SDK 1.3 things just got a lot simpler and I absolutely love it. The feature is called Full IIS and allows your web roles to access the full range of web server features that are available in on-premise IIS installations. However if you choose to use them, there are a few differences from the classic Azure Hosted Web Core (HWC) model. First you need to tell Windows Azure SDK to use Full IIS instead of HWC and you do this by adding a valid <Sites> section to your ServiceDefinition.csdef  file.  By default Visual Studio will create HWC model definition like this:     <Sites>       <Site name="Web">         <Bindings>           <Binding name="Endpoint1" endpointName="Endpoint1" />         </Bindings>       </Site>     </Sites> You can easily customize it to define multiple web sites, or virtual apps (virtual directories are also supported now): <Sites>   <Site name="MainSite">     <VirtualApplication name="WebApp1" physicalDirectory="D:\Delo\Projects\WebApp1\" />     <Bindings>       <Binding name="HttpIn" endpointName="HttpIn" />     </Bindings>   </Site>   <Site name="AnotherSiteOrSubDomain" physicalDirectory="D:\Delo\Projects\ AnotherSiteOrSubDomain ">     <Bindings>       <Binding hostHeader="anothersiteorsubdomain.myall.si" name="HttpIn" endpointName="HttpIn"/>     </Bindings>   </Site> </Sites> Things are much more similar to on-premises application then in HWC model. While RoleEntryPoint  runs under different process (WaIISHost.exe) than your web roles  (w3wp.exe), OnStart method still gets called but configuration settings work a bit differently. You cannot register or store some static values to be available to all websites. Remember its running in a different process... so you wont be able to access its data. What I mean by this is, probably everyone dealing with Azure Development has something similar to this in their role onstart method: CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>{     configSetter(RoleEnvironment.GetConfigurationSettingValue(configName)); }); While code is still perfectly sound, it wont do any good to our web roles, so the proper place to register it would by global.asax on ApplicationStart event. It all kind of makes sense, since different websites need different resources anyway.

Tags:

.Net | c# | Azure

... azure looks back at you

by Rok Bermež 8. January 2011 14:22
It’s been a month since Azure SKD 1.3 has been released with a lot of new features. Let’s take a look at the ability to user Remote Desktop Connection to your roles first.In order to enable this feature we must configure our deployments to support it. The easiest way to do so is to right click on cloud service project in visual studio and choose deploys. There you can click on 'Configure Remote Desktop connections'. Here you can enable RDP connections for all roles and you must set the required security credentials. So let’s create a security certificate first. Then we set user credentials for our RDP account and set its expiration date. After that, we export the security certificate so we can upload it to the cloud (you can click on view to open it directly). We also export private key And then we upload exported file through the Windows Azure Management portal to our chosen hosted service. If we take a closer look at what our Visual Studio Wizard did, we can open ServiceDefinition.csdef and ServiceConfiguration.cscfg and see xml additions. Now we can deploy our solution anyway we like. Once the deployment is complete and our role is in 'ready' state we can download or open .rdp file through Azure Management portal. Now we can finally connect to our instance ... and azure looks back at you NOTE: Changes made to instance will NOT be persisted. This was meant for easier debugging. If you want to take full advantage of IIS configuration you will need to use ‘Full IIS’ feature, which will be covered in my next post.

Tags:

.Net | Azure | IIS | Visual Studio

Calendar

<<  December 2017  >>
MonTueWedThuFriSatSun
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

View posts in large calendar

Page List

Month List