Orchard 1.3 fixes bugs, improves performance and introduces the following features:

•  Content item preview
• Markdown support
• Delete content types and parts
• Title part enables non-routable types to have a title
• Common added by default to content types
• Rules: trigger custom actions triggered by events
• Forms API: create forms from code
• Tokens: system-wide variables
• New content manager methods: part eager loading, get multiple items by ids in one query
• Task Lease API: creates server affinities for background tasks on web farms and cloud platforms
• Localization: data annotations, widgets, alternates
• Lists have RSS feeds

The full list of fixed bugs for this release can be found here: 

Orchard Items

 

 

 

When creating websites and applications it is one thing to make your application work in your development environment but it is another thing to make it work in the many integration environments that it will live in. An example, of this is a website that is developed locally, integration tested on a development box, tested in a QA environment, reviewed by a client in a staging environment, and pushed live to a production environment. 

All of these configurations require different database connection strings, email server addresses, and local file system locations for uploaded files. On top of these dynamic environment settings includes a Version Control system that most all of us use in our everyday life. I am sure everyone has accidentally checked in a web.config file that has a development connection string and it has caused problems in production. Secondly, it is a pain to manage these files in multiple environments by having to edit them on each server. Newer version of .NET have released the concept of the web.config.debug and web.config.release versions to mitigate this problem a bit but it really does not solve the problem for more than two environments.

Lastly, with the ability to write applications for the Windows Azure platform we want our applications to be easily tested locally and deployed to the cloud seamlessly. I want to be able to test my application locally on perhaps a local SQL database, but then when in the Cloud it should be connecting to a SQL Azure datasource and utilizing blob storage instead of file storage.

Cloud Construct has been using the concept of a dynamic configuration file for applications since we started writing web applications and standalone apps as well. The general concept is an XML driven file that contains settings that can be set for multiple environments that use an "endpoint" to resolve at application start the environment the application is running in. For example, in a web application project we will add some code to initialize our static Configuration class. The Configuration class will resolve the environment based on server endpoint and apply its settings to the object's properties. We can then access these properties from any place in our code.

Endpoints are resolved by server name and settings are pulled in the following order: 1. Global Settings 2. Environment Settings 3. Endpoint Settings. This allows global items to be applied to all environments when needed. Then environment specific settings will be applied. Lastly, any machine settings. Here is an example of this file:

config.xml (3.47 kb)

As you can see we have 3 specific environments:

1. Production, a single "Cloud" endpoint which resolves for the wildcard hostnames given in the cloud.

2. Staging, a single server endpoint.

3. Development, my local development machine endpoint and also my machine when it is in the local "Cloud" debugging mode. (It resolves Cloud endpoints over normal endpoints by checking to see if: RoleEnvironment.IsAvailable ? "cloud_endpoint" : "endpoint"

Each of these environments can have multiple endpoints as you can see so that if you have multiple servers in production they can all be resolved to that environment and possibly have their own settings on that machine. This file can be checked in easily to version control without causing problems in other environments accidentally and also limits all settings to a single file. Also I can take my applications and develop them in a way that in the future if clients want to expand to the cloud they can easily do so by just adding a cloud endpoint with its settings. For example, the EmailServer that uses SendGrid in the cloud or a local one when in staging:

if (CloudConstructConfig.Environment.IsInCloud)
{
   System.Net.NetworkCredential credentials = 

    new System.Net.NetworkCredential(CloudConstructConfig.EmailUsername, 

   CloudConstructConfig.EmailPassword);

   smtpClient.Credentials = credentials;
}

 

Above we are simply adding an extra credential when we are in the cloud to send emails. Otherwise the code is the same!

Sooo I am sure you want to know how do I get this code and integrate it right? Well here is the library: 

CloudConstructWebConfigurator_V1.0.zip (305.98 kb)

In order to integrate it into your application you can do the following:

1. Add a reference to CloudConstructWebConfigurator.dll in your project. (You can also add a reference to log4net dll as well for logging integration if you already are using it.)

2. Add a static class to your project that holds all of the settings configured in your XML file. This is the object you reference in code for your settings. (See the ClassLibrary1 project in the example integration zip below.)

3. Wire up your code in your global.asax.cs file to run on application startup and instantiate your static class.

4. Copy the Config directory into the App_Data directory.

Here is the link to the zip file of the example project utilizing the dynamic configuration library:

WebApplication1.zip (157.22 kb)

Important files to look at are the global.asax.cs, ClassLibrary1.CloudConstructConfig, and config.xml which drives the settings.

NOTE: It may be necessary to also add a reference to Microsoft.WindowsAzure.ServiceRuntime.dll if it does not exist on your system. It is provided with the zip file.

LOGGING INFORMATION:

If you utilize log4net you will get some great startup logging information:

 

2011-10-01 09:55:08,995 INFO  - *********************************

2011-10-01 09:55:09,005 INFO  -  Starting My WebApp

2011-10-01 09:55:09,005 INFO  - *********************************

2011-10-01 09:55:09,163 INFO  - Found host name to be: ARRA-CLOUD-PC.

2011-10-01 09:55:09,164 INFO  - Found 5 required items in the configuration file.

2011-10-01 09:55:09,164 INFO  - Found a global item list in the configuration file.

2011-10-01 09:55:09,167 INFO  - Processed Global file item: ContactEmailTemplate

2011-10-01 09:55:09,167 INFO  - Processed Global configuration item: EmailClientFooter

2011-10-01 09:55:09,168 INFO  - Processed Global flag item: DoCacheProfiles

2011-10-01 09:55:09,349 INFO  - Recognized environment as development, executing in normal context

2011-10-01 09:55:09,349 INFO  - Processed Environment database item: PrimaryDB

2011-10-01 09:55:09,349 INFO  - Processed Environment configuration item: EmailServer

2011-10-01 09:55:09,349 INFO  - Updated to Environment flag item: DoCacheProfiles

2011-10-01 09:55:09,349 INFO  - Matched host as ARRA-CLOUD-PC

2011-10-01 09:55:09,350 INFO  - Loaded 5 out of 5 required items.

2011-10-01 09:55:09,350 INFO  - No errors found when validating all configuration items.

2011-10-01 09:55:09,351 INFO  - Completed loading configuration file.

For some legacy ASP.NET sites you may notice your old HTTP Handlers and Modules being configured in the web.config <system.web> section do not work anymore in the Windows Azure. This is because Windows Azure is configured to run on IIS in "Integrated Pipeline" mode. This means web requests are integrated into IIS as opposed to classic pipeline mode where requests go only through the isapi.dll. In Integrated Pipeline mode your <httModules> and <httpHandlers> nodes will throw an invalid configuration exception.

I struggled to find out why this was happening and then I realized Azure was host in IIS 7 with Integrated Pipeline setup. You now define your modules and handlers in your <system.webserver> section of the web.config. This is helpful because now my "Browser Support Module" can be reused in the cloud. I have a specific module to redirect requests from browsers that are not supported by my website.

 

So Apple launched their iCloud platform recently and I have been kind of soaking it all in before I wrote a post on it. I also got a little shove from Lauren Carlson. I read her article entitled Can the Apple iCloud Make it Rain in the Enterprise? I thought it was a great read and expressed some similar thoughts I had on the whole iCloud platform.

When I see Apple products come out I get excited because I own an iPhone and a Macbook. I buy my music through iTunes and use my iPhone for my calendar, photos, and music playing. But as a developer it doesn't mean much to me. I feel like unless your building iPhone apps then I am really unsure of what your building on the Apple platform. Maybe it is because I am so immersed in the Microsoft world I don't know of anything outside of it, but I really can't think of any other development being done in that space. Apple's iCloud is targeted towards the everyday consumer but does nothing for me as a developer. It just allows app developers to utilize the online storage and syncing capabilities.

Apple will win the consumer facing cloud battle because so many people use their products. As Lauren Carlson pointed out in her blog, most people who own one Apple product own multiple Apple products. So to them the iCloud is a logical infrastructure for them. Although I thought this already existed with MobileMe anyways right?? But what about building cloud scalable applications and utilizing the cloud platform as a new tool to build enterprise ready applications? Apple is not up to par with Microsoft's Azure Cloud platform or Google's platform. Apple is offering a solution for Apple consumers to sync their information across multiple devices and 5GB of free storage. This is something that has been in existence in Google's solution and Microsoft's for some time now. Microsoft has had SkyDrive which syncs all of your documents, contacts, photos, and videos. And they give you 25GB free!

I think the iCloud is exciting news for consumers who utilize Apple products but doesn't mean much as far as advancing the cloud computing space. In fact there are rumors that Apple is utilizing Microsoft's solution for some of the logic and infrastructure of their new iCloud. I find this very interesting and perhaps it means Apple really doesn't care about the enterprise/developer route. They seem to be crushing it in the consumer space anyways. Even last week my dad bought an iPod.

The other day I read an article on Mashable about a new JS library called Now.js. This article called Will Node Power the Next Twitter? NowJS Is Betting On It discussed how many believe the next phase of the web, Web 3.0, will be powered by servers running on libraries such as Node.js. I watched the video included in the article that depicted a user setting up a node server and then setting up a now.js chat room. It was a cool video that showed a new concept of having server and client both running the same code and managing the users connected to the chat.

NowJS Introduction: Simple Chat Server in 12 Lines of Code from NowJS on Vimeo.

After watching the video I was did some reading around the web at various sites trying to find the pros and cons of a JavaScript based web server. To me it seemed like the argument for node.js was that it is event based where traditional web servers are synchronous in nature. Node.js can handle many requests because they delegate the work and wait for a callback rather than waiting for the request to finish. This sounds like an optimal way to handle requests, but isn't it still only a good way to handle requests? Won't the server eventually be just handling requests so fast and pushing off the work that the system will slow down? Sure the initial request will get through quickly but the time of response will be longer as request amounts increase.

A couple other things I find it hard to believe is that all of the benchmarks done out there are indicating node.js blows away all of the traditional web server technologies. For starters, a compiled program should run quicker than an interpreted language. I know Google's V8 is lightning fast for a JS interpreter but it is just a basic concept I figure has to be brought up. Secondly, while node.js is putting out these great benchmark times it is important to remember it does not contain the modules that a Microsoft IIS has. Security, request filtering, error handling, and much more and not included. Writing out the headers of the document being returned is a manual step as shown here. I am still searching for some of the benchmarks and will post them as I find them.

Anyone who can comment on my questions here would be great. I would like to hear peoples thoughts. In the meantime I am going to try and download some of the pre-compiled libraries of node.js and get it going on Windows. Also I saw another cool walk through of implementing node.js in Windows Azure Cloud. Check them out with me and lets see what Web 3.0 is all about.

After moving our website to Windows Azure we had one problem. Well we had a couple, but all of them were resolved pretty simply. The one that lingered was that our Contact Form stopped working. This is because there is no email server used for relay in Azure. Microsoft does this so people cannot send out millions of spam emails from Azure. Needless to say this made it hard to get a simple contact form working. We did not want to expose our hosting server email server to the outside ourselves because we could not verify our Azure server IP would be the same all the time. After searching for some solutions out there the best option seemed to be to use a third party email service like Amazon, SendGrid, or Postmark. Being a small business we knew we didn't want to pay anything to just have our contact form send one or two emails a month. The lowest plan I could find was $9.95/month from SendGrid. This was still too much. I then scrolled to the bottom of the pricing page and found a FREE option! Just scroll to the bottom of the page:


Once I signed up for the free plan it took a few hours for my account to be provisioned. Once that was done I was able to integrate my existing C# code which looked very much like this, C# SMTP example. You can also use the REST protocol but this is much cleaner in my mind. I tried testing the code from my dev environment but I kept getting an error saying the server could not be reached. I then thought maybe I can only access the email server from behind the URL I registered. So I pushed the code to Azure and gave it a whirl. It worked! Voila an email solution that lets you send 200 emails a day for free, and it works from Azure. Hopefully our contact form gets some activity in the coming months!

Tonight I will be giving a brief talk at the Boston Azure Group meeting about the benefits of Microsoft BizSpark for start-up companies. Cloud Construct used BizSpark to host our website in Windows Azure with a SQL Azure backend. All of the software and resources came free with our entrance into BizSpark.

 

 

Here is a link to the presentation if you want to take a look: BizSpark Azure Benefits Presentation

 

Here is a link to the Azure Benefits page.

After you have completed your first Windows Azure website or migrated an existing site to a webrole/website architecture you are probably wondering  "How Can I Get This Too The Real Cloud?". Well Microsoft does offer some Free Trial hosting but it is only for a month. If you have an MSDN license already you can gain access to some hosting resources for free which is great, but most of us don't have this because it is expensive. If you are a BizSpark member you get an MSDN license for free and thus can gain access to the Azure resources.

I took the road of signing up for BizSpark and it was very easy. BizSpark is free except that if you ever leave the BizSpark network you have to pay $100.00. If your company is privately held and less than three years old you are good to go.

Once you secure the BizSpark affiliation you can easily gain access to the MSDN license and thus the Azure hosting tools. Once all that is done you can deploy your new website to Windows Azure.

See the BizSpark benefits here.

 

With the emergence of Windows Azure, Cloud Construct has decided to migrate its existing site to a web role to run in the Azure cloud. We will be utilizing a hosted service, App Storage, and SQL Azure. Our existing site runs as a .NET 4.0 just-in-time compiled website, hosted on IIS, and with a SQL backend. This post will deal with migrating the existing .NET 4.0 site to run in the Azure service host environment, following posts will deal with connecting to SQL Azure.

• Step 1 : Create a new cloud service project.

• Step 2 : Assign a web role project to the Cloud Service solution.
  

  

You will notice that a new Windows Azure Cloud Service project will be added to your new solution. Secondly. a Web Role project will be added which is similar to a web application project but includes a WebRole.cs file which defines the web role entry point. This WebRole application will be assigned to your cloud service project and will be started up when your service starts up. The WebRole project will be included with some default files such as a Scripts directory and some basic .NET web pages. I deleted all of these boilerplate resources so  could begin porting my site into this project.

• Step 3 : Port over your existing site content.

Right now the easiest way to migrate your site into the project is to simply copy all the files over. Do not overwrite the web.config file! Any settings you had in there prior you can then cut-n-paste them into the WebRole project web.config. After you have copied all your files over, there are a few steps you will have to perform. If you are coming from a web application project then you will not have to perform these next step two steps.

• Step 3a : Convert all website files to web application files.

Because the WebRole project is technically a web application project you must convert your just-in-time compiled web pages to web application pages. This basically means adding a *designer.cs file to every page. The easiest way to do this is right click on the project in solution explorer and choose "Convert to Web Application". This will add designer files to all web page files.

• Step 3b : Migrate your App_Code directory to a class library

Because a web application project does not include an App_Code directory you must move all class files to a separate class library project. You will end up with multiple assembly conflicts if you do not which will cause a whole bunch of other problems.

• Step 4 : Rebuild and start your new cloud service.

Now that you have all your content ported over you can rebuild your new solution and make sure everything is all good. Lastly, start debugging the project and make sure your website runs in the local dev environment. If it all comes up the first time then your in luck. You might have to tweak some other portions of your site to make sure it all works but for the most part this should get you there. One snag I hit was documents being served out of the site like PDF's will require you to set their build action to "Content" instead of "None". This will make sure the file gets packaged and deployed with your cloud service.

10/21/2010 - Boston Azure is hosting an event at the NERD in Cambridge. The event starts at 6:30pm and will detail using Silverlight with Windows Azure.

10/21/2010 - Boston WebSiteSpark Group is hosting an event at the NERD in Cambridge. The event starts at 6:00pm and will detail developing iPhone applications using ASP.NET.