ASP.NET Weblogs

Keep Calm And PowerShell On

SB Chatterjee — Wed, 16 May 2012 10:08:00 GMT

Another variation of the historic poster from WW2.

SharePoint variations here…

Getting Started with ASP.NET MVC 3, Logging, and Depency Injection

Bil Simser — Wed, 16 May 2012 01:35:43 GMT

I started a new ASP.NET MVC project recently and wanted to give you a little insight on kicking off new projects. There’s some setup time you want to spend setting up your solution and getting the plumbing in order before you dive into writing unit tests and building out your site.

For a full on, blow my mind, ultimate guide you *have* to go watch Rob Conery and his 90 minute walkthrough of setting up his MVC projects. I’ve watched this video a few times and Rob is awesome and knows his stuff. The tips he gives are gold. You can also check out the MVC 3 Starter Kit on CodePlex which is based on his MVC 2 Starter code but I found it was lacking a few features. In any case, go watch his video for the full meal deal either here on YouTube or here on TekPub. This post is just a mere shadow of his work but updates the use of Ninject with MVC 3.

Okay, so we’re going to be doing some simple plumbing to get this going. We’ll put together the Hello World MVC 3 app, add in a logging system, and plumb in dependency injection in just a few minutes.

You’ll need Visual Studio 2010 with MVC 3 and NuGet installed. You can get MVC 3 from the main site here. Next install NuGet from here. The MVC 3 framework is obviously needed (Visual Studio 2010 only comes with MVC 2 out of the box) and NuGet is used to install our additional libraries (trust me, if you haven’t used NuGet before it will blow your mind).

First steps is to build a new MVC 3 app. File > New Project. Then select Visual C# > Web > ASP.NET MVC 3 Application and give it a name.

Click OK and you’ll see the options dialog for a new MVC 3 Application.

Pick Internet application as it will work for most everyone (Windows authentication works fine too but for this post it’s just easier to go with Internet). Let’s choose Razor for the view engine (ASPX is so 2011) and use HTML 5 markup (hey, it’s just a demo). We won’t create a unit test project but in a real project you’ll create one (or create a class library separately so you can use other unit testing frameworks).

We’re creating a project based on the template to give us a controller as we’ll inject our dependency into it later, otherwise we would have to create those. In a real project we might start with an empty template and create our own controllers from scratch (again, demo land, remember?).

Once you do that you’ll be at the Hello World project of the MVC world.

Okay, now we’re going to install two NuGet packages, Ninject and NLog. Ninject is an open source dependency injection framework and makes working with external dependencies (like infrastructure and services) a breeze. NLog is a free logging solution for .NET and allows you to write anything to almost any target including files, event logs, web services, mail, forms. You name it, it can write to it. I was using log4net for all my projects but lately I’ve switched over to NLog. It’s super-simple to use and highly flexible. Did I mention it’s available as a NuGet package?

Right click on the References in your project and choose Manage NuGet Packages…

Make sure you’re looking at the Online packages (sometimes the dialog will open up to installed packages or updatable ones). Type in “nlog” into the search box and you’ll see the filtered search results. Choose NLog Configuration from the options. If you already had a log configuration file you can just choose NLog to install the logger but since we’re starting from scratch we need a config file to start with. Selecting NLog Configuration and you’ll see it has a dependency on NLog so you can just install the one package which installs a starter config file and then drags along the library with it. Easy.

Once you’ve installed NLog you can enter “ninject” in the search box. This will bring up a list of packages for the dependency injection library Ninject by Nate Kohari. You’ll want to install the Ninject.MVC3 package by Remo Gloor and Ian Davis. This package will install Ninject itself and the extensions for MVC 3 (along with the bootstrapper for web projects. Ninject requires you to review and accept the license agreement before it will install so go ahead and do that.

Two packages and all of their dependencies but you’re now only a few minutes (yes, minutes) away from dependency injection heaven and MVC 3.

The first thing we’re going to do is create an interface that will be our logging system. We have a logger (NLog) but that’s an implementation and while we could scatter NLog statements all over the place, we would be tied directly to that library. If we decided to phase out NLog and replace it with another library (such as how I’ve shifted from log4net to NLog) we would have to go through everywhere in our code and replace the NLog calls with the next best thing.

This the one of the principles of dependency injection, abstraction, and SOLID. Creating an abstraction of an implementation to code against without tying ourselves to any one system (so to speak). At the end of the day we’ll still be calling into NLog functions but we’ll be doing it through an implementation class via our interface.

The other key thing about this approach is that we we can mock or stub out the actual implementation of our logger for unit testing. You can really do that (very well) with concrete implementations. Imagine having to start up a database, file system logger, and the Windows Event log service just to unit test some business code.

In addition to being able to test our code, we can also code to interfaces meaning that we don’t need the actual implementation until it comes time to actually perform the work. For example the project I’m currently working on is going to require to call out to web services and databases. These components are not built yet and won’t be for another month or so. I don’t want to halt the development of my app so I create service interfaces and repositories that will abstract these away from my system, allowing me to build a fully working (and tested) system (which just happens to use hard coded values for now). Later when those services appear I just build an implementation to talk to them and voila, my system is still working exactly the way it does today.

Okay, enough talk. Here’s the interface for our logging system. I’m borrowing from Rob’s approach by creating a folder called Infrastructure with a subfolder called Logging. In it I’ll create an ILogger interface that will let me write an information message (most logging systems have various levels of logging like Information, Warning, Errors, etc.)

And here’s my ILogger interface:

        1: namespace MvcStarter.Infrastructure.Logging

       2: {

       3:     interface ILogger

       4:     {

       5:         void Info(string message);

       6:     }

       7: }

Next we need an implementation. We’ll create one for NLog. This is a simple class that implements ILogger and provides the Info method (along with the setup needed for NLog to work). Here’s the NLogLogger class:

       1: using NLog;

       2:  

       3: namespace MvcStarter.Infrastructure.Logging

       4: {

       5:     public class NLogLogger : ILogger

       6:     {

       7:         private Logger _logger;

       8:  

       9:         public NLogLogger()

      10:         {

      11:             _logger = LogManager.GetCurrentClassLogger();

      12:         }

      13:  

      14:         public void Info(string message)

      15:         {

      16:             _logger.Info(message);

      17:         }

      18:     }

      19: }

We create a private variable of type NLog.Logger and create it in our constructor using the LogManager from NLog. Then to write using NLog we just call the Info method on the class, passing it our message.

There are a lot of other methods we can call and add to our interface so later maybe we’ll extend that but this is enough to get you started.

One more thing is that the default config file that was installed with the package is just that, blank. You need to tell it at least what target to use and what rules to apply to each target. The entire config file is documented online but you can just uncomment the sample implementation. Make sure to match up the logger rule (Trace in the config file) with your method you’re calling in the implementation. I just changed the minLevel of the NLog config file from Trace to Info to match our code.

That’s all you need to have logging working but how do we call it? And how does Ninject fit in?

Back when we installed Ninject it created a file for us. Go back to your project and check out the App_Start folder. Expand it and you’ll see a new file there called NinjectWebCommon.cs

This sucker is responsible for kickstarting Ninject for you. If you watched Rob’s video or saw some tutorials on the net they talk about changing the base HttpApplication to a Ninject one. That’s one approach but with MVC 3 and the NuGet package this way is much simpler. There’s nothing for you to do except tell Ninject what dependencies you want to deal with and how to resolve them.

Open up NinjectWebCommon.cs and scroll down to the RegisterServices method. This is where you’ll specify you own interfaces and concrete classes so Ninject can do it’s magic.

With a single line we’re going to tell Ninject this:

       1: /// <summary>

       2: /// Load your modules or register your services here!

       3: /// </summary>

       4: /// <param name="kernel">The kernel.</param>

       5: private static void RegisterServices(IKernel kernel)

       6: {

       7:     kernel.Bind<ILogger>().To<NLogLogger>().InSingletonScope();

       8: }

What are we saying here? Simple. We’re telling Ninject to:

Whenever you see the ILogger interface needed (e.g. passed into a constructor of a class)
Resolve to the NLogLogger class
Make it a singleton (i.e. only do it once and reuse it over and over again)

We’re making our logger a singleton because we don’t need to start NLog every time we want to log a message. You can also specify other scopes (like by thread or on demand) but for logging a singleton works.

Oh yeah, that’s it to hook up your dependency injection engine. And logging is ready to go.

Let’s give it a whirl. Crack open the HomeController class and add a constructor that takes in an ILogger interface then using that interface, write out a message when the Index method is called (i.e. our home page is visited). Here’s the modified HomeController class:

       1: using System.Web.Mvc;

       2: using MvcStarter.Infrastructure.Logging;

       3:  

       4: namespace MvcStarter.Controllers

       5: {

       6:     public class HomeController : Controller

       7:     {

       8:         private readonly ILogger _logger;

       9:  

      10:         public HomeController(ILogger logger)

      11:         {

      12:             _logger = logger;

      13:         }

      14:  

      15:         public ActionResult Index()

      16:         {

      17:             ViewBag.Message = "Welcome to ASP.NET MVC!";

      18:             _logger.Info("Home page visited");

      19:             return View();

      20:         }

      21:  

      22:         public ActionResult About()

      23:         {

      24:             return View();

      25:         }

      26:     }

      27: }

We add an ILogger interface to the constructor. This trigger Ninject to figure out what implementation to grab (our NLogLogger one) and create it for us (or reuse it since we told it we wanted a singleton). Then we use that implementation in our Index() method to log a message.

Compile and run the app to visit the home page of your app and you’ll see this in your log:

       1: 2012-05-15 19:18:38.8471 INFO Home page visited

That’s it. You have a logging system you can call anytime (just inject the interface into the class, Ninject will take care of the rest) and your project is setup with dependency injection and you’re ready to go. Now you can just add additional interfaces as you need them.

The awesome thing here is that a) you can now mock or stub out your logging implementation and test it and b) replace that implementation with some other logger any time and your code will still just work.

That’s the power of dependency injection.

As a bonus piece of information, now that you have the dependency injection setup you can use it any time in case you’re in a pinch and don’t need/want to inject the implementation into your class.

Here’s how you can call the logger from your Application_Start method (found in Global.asax.cs) before any controllers are fired up:

       1: protected void Application_Start()

       2: {

       3:     AreaRegistration.RegisterAllAreas();

       4:  

       5:     RegisterGlobalFilters(GlobalFilters.Filters);

       6:     RegisterRoutes(RouteTable.Routes);

       7:  

       8:     DependencyResolver.Current.GetService<ILogger>().Info("Application Started");

       9: }

See that last line? DependencyResolver.Current.GetService will use whatever IoC you have configured and return the implementation of that interface.

Okay, that’s enough to get started. Again, I encourage you to watch Rob’s *entire* video of setting up a new MVC project. Even though the video is for MVC 2, there are still a lot of idea that hold water in MVC 3 and it’s a great learning too (and free too).

Enjoy!

Configure Email notifications on SharePoint 2010 list

sreejukg — Tue, 15 May 2012 19:58:00 GMT

In this article I am going to demonstrate how you can configure email notification feature on SharePoint List. For the purpose of demonstration I chose the default tasks list that is coming with almost all default SharePoint sites. Tasks list have one column “Assigned To”. When an item is created in the task list, I would like to send an email to the user to whom the task is assigned. The scenario is very simple and straight forward.

In order to perform certain action when an Item is created in a list, you can make use of Workflow. To understand more about workflows in SharePoint 2010, refer the link http://technet.microsoft.com/en-us/sharepoint/ff819861 .

So What I need to do is to create a list workflow that is associated with my Tasks list. The workflow should be initiated automatically whenever an item is added to the tasks list. I am going to use SharePoint Designer as the workflow authoring tool.

Open SharePoint designer and open the site where your tasks list resides. Click on File menu, then select Add Item from the Menu. Under the workflow section, select List Workflow

Now SharePoint designer will ask you to enter a name for your workflow. Also select a list to which the workflow will be applied. Since I am going to create a workflow on task list, I have selected it and for the purpose of this demonstration I have named the workflow as “MyTaskFlow”. Click on create button once you are done.

SharePoint Designer will open the Workflow in the workflow editor. The default workflow screen will look similar to the following.

In our case the workflow is simple; we just need to add a step that will send email. In real life you may need to check certain condition, for e.g. if the task priority is high, then send email etc. When sending email, the workflow should access the data from the created item such as who created it and to whom it is assigned etc. You can add conditions and actions to workflow. In our case, it is just one action. Click on the Action Icon in the top and select send email.

When you click on Action icon, it will pop up all the available actions that you can choose from. There are many actions available and we need send an Email Action.

When you choose the Action, it will be inserted in the Step. Also you can simply type in the Step where underline is there to pick the right action/condition. This is another way of authoring if you don’t want to use mouse and menu to pick the actions/conditions. The default Send Email action will look similar to following.

Click on users link, it will bring Define email dialog. Here you need to select address, subject and a body for the email.

First you need to enter the To address. Click on the browser button next to To: text box. Here you can add a static email address or you can pick it from SharePoint objects. As our requirement is to send to the user in the Assigned To field, you have an option to pick this data from the current Item property. First select Workflow lookup for a user, click on the Add button.

This will bring the lookup dialog to select the item and field. Also make sure you select return field as Email Address.

Click OK twice so the select users dialog will be closed. Now in the subject box, enter some text. You can even pick the data from current item such as showing the task title in the subject. In the body part, you need to tell the user “the task is created for you at <time of the task> by <created user>. So you need to access the item properties in the body too. You can see Add/change lookup button in the bottom of the dialog to pick the necessary fields. You can write custom message and include the fields in between the message as necessary. Below is the screenshot of the email body I have configured.

Click OK once you are done. Now you can see the start options for the workflow as follows.

Since I want the workflow to start automatically when an Item is created I selected the second option. Now I need to publish it. To publish the workflow, press on the publish button in the top.

Now when you go to your list, you will see the workflow is available under the list you configured the workflow, in our case under the Tasks list. From the browser, go to the tasks list, then open list tab.

On the right corner, you can see workflow settings link

Click on the Workflow Settings link, this will open the workflow settings for the tasks list and you can find our workflow is available in the list.

Now go and add a new list item and you will see the workflow will be executed automatically and will send email. Designing such business processes is simple and straight forward with SharePoint 2010 and SharePoint Designer. Without writing single line of code you can achieve your day to day business requirements.

Video Training - Android Advanced Development Using Mono for Android 4

Wallym — Tue, 15 May 2012 14:15:00 GMT

This course is about how to use Mono for Android with Tablets and the new Android 4.0 Ice Cream Sandwich release. The course introduces Android Tablets and Fragments, new controls that are available through Android 4.0, new application programming interfaces in Android 4.0, and new features available in the Google Android SDK Release 17 that can improve their development experience. This course also contains a module on the Android Design Experience, what developers can use to improve the user experiences, design suggestions from Google’s Android team, and some thoughts on how to improve the design experience via software code.

"An error occurred when verifying security for the message." when executing .SaveChanges()

pablop — Mon, 14 May 2012 22:58:03 GMT

Hi,

I have just came across this exception when trying to execute the SaveChanges() method of my ServiceContext object in CRM 2011 (on-premise).

Exception:

"An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail."

Inner Exception:

"An error occurred when verifying security for the message."

Unfortunately I couldn’t find so much useful information around about the InnerException, which I guess should be the first thing to search for. But, I did could find related info about the main Exception and realized that I was also having troubles to connect from my CRM Outlook client too. So, I suspected that it was something wrong with my machine but not the code, the code was right.

And that was true. The problem was my clock. As I have changed my time zone, time was not in synch with my CRM 2011 server.

Solution:

In my case, I just set up same time zone in my machine as the server is set up, adjusted the clock, F5 again and voila! SaveChanges() worked like a charm

Hope it helps to save somebody else’s time,

PP [twitter: @pabloperalta]

UruIT Dynamix | Excellence in Dynamics CRM Nearshoring Services.

CI Deployments To IIS VIA MS Web Deploy 2.0

srkirkland — Mon, 14 May 2012 18:15:00 GMT

Now that I have my source code being checked into GitHub and have TeamCity doing automatic builds (and running tests), I thought it was about time to take the last big step and automatically deploy the latest version of an application to a live site (either for testing or just straight to production, it’s up to you) whenever a successful build has taken place.

The best resource I’ve found for deploying directly from TeamCity (note: the steps would be the same for any CI server) can be found in Troy Hunt’s excellent 5 part blog series here: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html. It is very comprehensive and well worth a read, but I had some issues configuring deployment permissions and wanted to detail them here in case it helps someone else down the road.

An Overview Of the CI Deployment Process

Here’s a basic idea of how to get started—if you’ve ever used the Visual Studio 2010 “Publish” wizard then you are 1/2 way there. If you have any questions on these steps, refer to the blog series mentioned above or Google with Bing for help.

Install Microsoft Web Deploy 2.0 from http://www.iis.net/download/webdeploy on the server you wish to publish to.
Setup Web.Config transformations for your desired build configurations (see http://msdn.microsoft.com/en-us/library/dd465318.aspx)
Inside Visual Studio, right click –> properties on your Web project, and under Package/Publish Web setup the IIS Web Application name to match your IIS server
- This is the virtual directory inside IIS that your deployment will be pushed to. Set it up for each desired build configuration.
Setup Permissions on your IIS Server to allow web deployment from your CI agent or service account (detailed below).
Craft an MSBuild command that will build AND deploy your web application, and run it during your CI Server build process (also detailed below).

Deploying Via MSBuild

That last point requires a bit of explanation as it’s the crux of the problem (other than permissions, which I’ll get to later). What we want MSBuild to do here is to build your project/solution using the desired build configuration (like Debug/Release) and then to use the MS Web Deploy service to push your auto-created deployment package to IIS. Here’s an example of MSBuild parameters from Troy’s blog that will accomplish this:

     /P:Configuration=%env.Configuration%

    /P:DeployOnBuild=True

    /P:DeployTarget=MSDeployPublish

    /P:MsDeployServiceUrl=https://%env.TargetServer%/MsDeploy.axd

    /P:AllowUntrustedCertificate=True

    /P:MSDeployPublishMethod=WMSvc

    /P:CreatePackageOnPublish=True

    /P:UserName=AutoDeploy\Administrator

    /P:Password=Passw0rd

Basically the above parameters use the provided env.Configuration (Debug/Release) to set the build configuration and then tell MSBulid to deploy using WMSvc (web management service) to the service url located at env.TargetServer (you can set the defaults on your CI server).

This is pretty handy, but I unfortunately for me (and maybe for you) there are two problems here:

#1: The user (AutoDeploy\Administrator) needs to be an admin on your IIS, and you need to have allowed Administrators to bypass rules in the “Management Service Delegation” area of IIS (see ScottGu’s post here: http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx). For me, this is too much by itself.

#2: The username and password as passed in plain text through your configuration, as shown above. Not good.

The rest of this post will detail how to solve these issues, and in the end we will setup an service account that has non-admin access and which doesn’t require passing credentials manually.

Setting Up the Service Account

The first step is to create a non-admin service account that will be used on both your build server and IIS boxes. I’ll be using a no-login domain account called “mydomain\builderservice”, but any account would work.

On your CI server (in my case, TeamCity), you’ll want to run your build agent as your new service account, as shown here:

Note you might also have to give this service access to certain files. For example, in TeamCity the build agent needs access to C:\TeamCity\buildAgent to do its work.

Changing the MSBuild Script to Run As “Current User”

This part was fairly tricky since simply removing the UserName/Password parameters from the msbuild command will not work as expected. Instead you must specify the AuthType to be NTLM (or it will default to Basic) and the UserName=[blank] so it will impersonate the current user. The relevant parameters are /P:UserName= /P:AuthType=NTLM. This makes the final MSBuild parameters:

    /P:Configuration=%env.Configuration%

    /P:DeployOnBuild=True 

    /P:DeployTarget=MSDeployPublish 

    /P:MsDeployServiceUrl=https://%env.TargetServer%/MsDeploy.axd

    /P:AllowUntrustedCertificate=True 

    /P:MsDeployPublishMethod=WMSvc 

    /P:CreatePackageOnPublish=True 

    /P:UserName= 

    /P:AuthType=NTLM

Now that we have TeamCity running MSBuild with these parameters while running under a service account, we need to grant permission on the IIS server that has MS Deploy installed (%env.TargetServer%).

IIS Server Permission For Deployment

Your mileage may vary, but in order to get a successful web deployment from a non-administrator account, I had to perform the following steps, each of which I will explain in detail.

Enable Windows Authentication for the Web Management Server (WMSvc)
Grant Management Service Delegation rights at the Site level to the necessary providers
Grant IIS Manager Permissions to your virtual application
Grant file/folder permissions to the web directory

#1: Enable Windows Authentication for the Web Management Server (WMSvc)

In order to get the WMSvc to accept my build agent credentials, I had to enable Windows Authentication inside the IIS Management Service. You can do this either from the UI or Windows Registry as described in this stackoverflow post. For convenience, here is the regex key (make sure to restart the WMSvc after making the change): ‘reg add HKLM\Software\Microsoft\WebManagement\Server /v WindowsAuthenticationEnabled /t REG_DWORD /d 1’

#2: Grant Management Service Delegation rights at the Site level to the necessary providers

Next you must Delegate to your service account the rights to perform certain actions through the management service providers. If you forget any of these you will get a helpful error message saying that you don’t have rights to run a certain provider (ex: “createApp”) so you’d then need to come back in and add those. I needed the following providers: “contentPath, iisApp, createApp, setAcl.”

To set a delegation rule go to your site root in IIS and under Management choose “Management Service Delegation.” Now choose “Add Rule” in the upper-right and choose the “Deploy Applications with Content” template (this has the best defaults) and then add in your desired providers. Mine looked like this:

Click ok, and now that the rule is defined you just have to select the newly created rule and choose “Add User To Role.” In the ensuing dialog enter the name of your service account and press OK.

#3: Grant IIS Manager Permissions to your virtual application

Now that you granted site-level provider access within the {userScope} path, you must give the account IIS permission on the site/application that you will be deploying to. Choose your site and then under Management choose “IIS Manager Permissions.” Now click “Allow User” and enter the account name again to grant access.

#4: Grant file/folder permissions to the web directory

This one is pretty obvious, but you still have to remember to give full control to your service account at the OS-folder level (ex: C:\inetpub\SiteName). Right-click –> Properties –> Security –> Edit, and then choose Add. Now type in your service account one more time, grant it full control, and you are finished.

Celebrate!

That was certainly a lot of info, and I hope it makes someone’s deployment configuration easier. Integrating your build, test, and deployments with a CI Server like TeamCity has many advantages, including the ability to handle “deploy automatically only when all tests pass” and “oops, deploy the version from last week” scenarios.

May all your Deployments be green.

Enjoy!

Introducing Testing Domain - localtest.me

OWScott — Mon, 14 May 2012 15:59:54 GMT

Save this URL, memorize it, write it on a sticky note, tweet it, tell your colleagues about it!

localtest.me (http://localtest.me)

and

*.localtest.me (http://something.localtest.me)

If you do any testing on your local system you’ve probably created hosts file entries (c:\windows\system32\drivers\etc\hosts) for different testing domains and had them point back to 127.0.0.1. This works great but it requires just a bit of extra effort.

This localtest.me trick is so obvious, so simple, and yet so powerful. I wouldn’t be surprised if there are other domain names like this out there, but I haven’t run across them yet so I just ordered the domain name localtest.me which I’ll keep available for the internet community to use.

Here’s how it works. The entire domain name localtest.me—and all wildcard entries—point to 127.0.0.1. So without any changes to your host file you can immediate start testing with a local URL.

Examples:

http://localtest.me
http://newyork.localtest.me
http://mysite.localtest.me
http://redirecttest.localtest.me
http://sub1.sub2.sub3.localtest.me

You name it, just use any *.localtest.me URL that you dream up and it will work for testing on your local system.

This was inspired by a trick that Imar Spaanjaars introduced me to. He created a loopback wildcard URL with his company domain name. I took this one step further and ordered a domain name just for this purpose.

I would have liked to order localhost.com or localhost.me but those domain names were taken. So to help you remember, just remember that it’s ‘localtest’ and not ‘localhost’, and it’s ‘.me’ rather than ‘.com’.

I can’t track usage since the domain name resolves to 127.0.0.1 and never passes through my servers, so this is just a public tool which I’ll give to the community. I hope it gets used. And, since I can’t really use the domain name to explain itself, please spread the word and tell others about it.

Some examples on how to use it would include:

Creating websites on your dev machine. site1.localtest.me, site2.localtest.me, site3.localtest.me.
Great for URL Rewrite (IIS) or mod_rewrite (Apache) testing: redirect.localtest.me, failuretest.localtest.me, subdomain.localtest.me, city1.localtest.me.
Any testing on your local system where a friendly URL would be useful.

I hope you enjoy!

Introducing Testing Domain - localtest.me

The Official Microsoft IIS Site — Mon, 14 May 2012 15:59:54 GMT

Save this URL, memorize it, write it on a sticky note, tweet it, tell your colleagues about it! localtest.me ( http://localtest.me ) and *.localtest.me ( http://something.localtest.me ) If you do any testing on your local system you’ve probably Read More......( read more ) Read More......(read more)

eLearning event on HTML5 for Mobile with jQuery Mobile - May 17

Wallym — Mon, 14 May 2012 10:00:00 GMT

I'll be doing an eLearning event on HTML5 for Mobile with jQuery Mobile. There will also be a few items sprinkled in on ASP.NET Razor.

Mobile development is a hot item. Customers are buying iPhones, iPads, Android devices, and many other mobile computing devices at an ever increasing record pace. Devices based on iOS and Android are nearly 80 percent of the marketplace. RIM continues to be dominant in the business area across the world. Nokia's growth with Windows Phone will grow on a worldwide basis. At the same time, clearly web development is a tremendous driver of applications, both on the public Internet and on private networks. How can developers target these various mobile platforms with web technologies? Developers can write web applications that take advantage of each mobile platform, but that is a lot of work. Into this space, the jQuery Mobile framework was developed. This eLearning series will provide an overview of mobile web development with jQuery Mobile, a detailed look at what the jQuery Mobile framework provides for us, how we can customize jQuery Mobile, and how we can use jQuery Mobile inside of ASP.NET.

Link: http://elearning.left-brain.com/event/mobile-web-development

Windows Azure SDK for Node.js 0.5.4 Released

shiju — Mon, 14 May 2012 06:14:58 GMT

The Microsoft Windows Azure team has released the Windows Azure SDK for Node.js 0.5.4 which will be using the Node.js 0.6.17 and iisnode 0.1.19. The Node.js 0.6.17 contains a security fix against the HTTP Server Security Vulnerability detected by recently. It would be recommended to upgrade to the new version of Azure SDK for Node.js if you have already deployed any Node.js app to Windows Azure which will provide better security. The iisnode 0.1.19 provides iisnode.yml file instead of XML based configurations which can be use for setting up all iisnode settings. You can download the Windows Azure SDK for Node.js 0.5.4 from here.