As the size of hard drives increase, more people are using partitions to separate and store groups of files.
XP uses the C:\Program Files directory as the default base directory into which new programs are installed. However, you can change the default installation drive and/ or directory by using a Registry hack.
Go to :
- Start > Run
- Type “regedit” (without “”)
- Go to this directory…HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
- Look for the value named ProgramFilesDir. by default,this value will be C:\Program Files. Edit the value to any valid drive or folder and XP will use that new location as the default installation directory for new programs.

Disclaimer: Modifying the registry can cause serious problems that may require you to reinstall your operating system. We cannot guarantee that problems resulting from modifications to the registry can be solved. Use the information provided at your own risk.

This reg file automatically ends tasks and timeouts that prevent programs from shutting down and clears the Paging File on Exit.
1. Copy the following (everything in the box) into notepad.

QUOTEWindows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]“ClearPageFileAtShutdown”=dword:00000001
[HKEY_USERS\.DEFAULT\Control Panel\Desktop]“AutoEndTasks”=”1″
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control]“WaitToKillServiceTimeout”=”1000″
2. Save the file as shutdown.reg
3. Double click the file to import into your registry.

NOTE: If your anti-virus software warns you of a “malicious” script, this is normal if you have “Script Safe” or similar technology enabled.

Disclaimer: Modifying the registry can cause serious problems that may require you to reinstall your operating system. We cannot guarantee that problems resulting from modifications to the registry can be solved. Use the information provided at your own risk.

Follow the following steps
1. Open notepad.exe, type “del c:\windows\prefetch\ntosboot-*.* /q” (without the quotes) & save as “ntosboot.bat” in c:\
2. From the Start menu, select “Run…” & type “gpedit.msc”.
3. Double click “Windows Settings” under “Computer Configuration” and double click again on “Shutdown” in the right window.
4. In the new window, click “add”, “Browse”, locate your “ntosboot.bat” file & click “Open”.
5. Click “OK”, “Apply” & “OK” once again to exit.
6. From the Start menu, select “Run…” & type “devmgmt.msc”.
7. Double click on “IDE ATA/ATAPI controllers”
8. Right click on “Primary IDE Channel” and select “Properties”.
9. Select the “Advanced Settings” tab then on the device or 1 that doesn’t have ‘device type’ greyed out select ‘none’ instead of ‘autodetect’ & click “OK”.
10. Right click on “Secondary IDE channel”, select “Properties” and repeat step 9.
11. Reboot your computer.

This is not exactly a registry tweak but it essentialy changes the registry entries that control these settings.

Disclaimer: Modifying these settings can cause serious problems that may require you to reinstall your operating system. We cannot guarantee that problems resulting from these modifications to the settings listed above can be solved. Use the information provided at your own risk.

So I was talking to an old friend yesterday about building software, and we both came to the conclusion that there are some things you need to learn:

• From books
• From others
• From doing

We then got onto the topic of cloud computing, he works in the same space, so it was a great context to place on our conversation.

Taking the thinking further, we both realized that when we decomposed our jobs into buckets, we arrived at:

• Working with customers – This is the most important element, and the only way to sharpen your skills are to engage real customers, books are pretty much useless in this area, and while you can learn some tricks from others, nothing beats logging hours in the field.
• Core engineering – This is bread and butter stuff, and doesn’t really change depending on what your working on. And it definitely get’s ticks in all three categories from above.
• Working in a team – Again, this doesn’t change all that much, working with your own team and other teams is not necessarily specific to cloud, but when you think of it in terms of the list above, you could learn a little about it in books, but nothing compares to learning from others and from doing.

We then got to the unique parts when working in the cloud, and this ended up being more about trading lessons learned, and while it definitely leverages the core concepts above, there are some aspects which I’ve never encountered in any other type of project.

1. Think big! Very few projects work at the scale of cloud computing projects. When you take into account the sheer size of the data center deployments, the hardware, facilities, connectivity, nothing can prepare you for the types of problems you will need to solve in terms of core engineering and software development. How do you deploy, manage, test, recover, fail-over, charge, audit, a massive, geographically dispersed, mega-distributed system? You don’t only have to build new software, you need to build new ways to test, deploy, manage and support it.
2. Shipping! The cloud world is not like the packaged product world, it’s not even like the online services world. Not only do you need to think in small bite sized chunks, to reduce the integration and dependency workload and risk, but you also need to plan for how you get that chunk out to thousands of live servers running live customer apps, in a completely passive and non-intrusive/non-disruptive way. You also have the incumbent hardware that comes with cloud, so not only are you shipping software, your rolling out hardware, and lots of it, to places you never knew about before, I liken it to landing jumbo jets on small islands.
3. Simplicity! If you can’t describe how you plan to define, develop, test, deploy, test, deploy, test, deploy again, and finally test once more, troubleshoot, maintain, update, and finally decommission the feature you want to build, to a layperson, then think harder or don’t do it. When you’re working in an environment where every bug is a potential go-home bug (the kind of bug that wipes every users data out or something else so catastrophic that you can never recover, you just go home and find a new job), you need to raise the bar on all aspects, and complexity is usually the root of all evil
4. Test! I have a saying that I only started using when I started working in the cloud, “Give me a tester before you give me a dev”. The reality of the cloud is you cannot and will not ever test enough, the best you can do is test lots. And the types of tests are so diverse, starting from a one box environment for the developer, to check-in tests for unit completeness, integration tests for fit and flow, perf/scale/load tests, environment tests for datacenter compatibility, regression testing, pen testing both at the edge and at the platform boundaries. Key take away is that quality matters so much more in the cloud because the potential impact of a bug is much larger and unpredictable that most other environments. You also want to build self-testing into your code, you want your code/feature to be cognizant of where it is, so it can ask questions of itself, and react accordingly. Think of it like the safety switch on a power point, make sure your code doesn’t need to touch the iron to know it’s hot!

Anyhoo, just some thoughts from my time as an apprentice of the cloud.

Enjoy :)

Syndicated via RSS From: http://blogs.msdn.com/b/davidlem/

OK, so MattT (thanks for the feedback on my blog too Matt :)) pinged me and asked if something had changed in the way Live ID auth worked in Windows Azure.

He was looking around Bing for some samples, and came across this post but couldn’t get it working. You’re right Matt, there was a change.

In late May, 2009, we made a change to the way developers access Live ID, see this post:

• Windows Azure - Changes to Alerts, Analytics, and Windows Live ID

So how do you code it up?

Step 1. Download the appropriate SDK (I downloaded the CS one)

Step 2. Go to http://windows.azure.com and create a new Live Services project, make sure you select Live Services: Existing APIs as your project type

Step 3. Enter the details of your Web Role project (you should have created this already, it’s your http://xxxx.cloudapp.net url). The domain should be the straight “xxxx.cloudapp.net” part, in the returnUrl field, enter http://xxxx.cloudapp.net:81/webauth-handler.aspx just while you do local machine testing.

Step 4. Now, while I tested it locally, I had to do a quick update to my hosts file to point my url (crmintegration.cloudapp.net) to 127.0.0.1 so I could test it locally. Just create a pointer to your url in your hosts file to point to 127.0.0.1 just while you test locally. This will enable the above http://xxxx.cloudapp.net:81/webauth-handler.aspx returnUrl to work.

Step 5. Create a Web Role project, and import the WindowsLiveLogin.cs, webauth-handler.aspx and webauth-handler.aspx.cs files from the Windows Live SDK sample directory. You’ll need these to process the return details from Live ID.

Step 6. Run and test, and make sure it’s connecting to Live ID and returning a Id.

Step 7. Deploy to the cloud, remove the local pointer from your hosts file, and update your Live Services returnUrl to not include the port 81 reference. (it should look like http://xxxx.cloudapp.net/webauth-handler.aspx)

To get everyone started, here is a quick sample project that has all the bits in there. You just need to update the web.config with your Application ID and secret from the Live Services page for your project in the Windows Azure portal.

Ping me with questions/issues.

Enjoy :)

Syndicated via RSS From: http://blogs.msdn.com/b/davidlem/

PHP comes with an in-built function to display time in your required format, but what if you want to display date and time according to user’s timezone, that’s where PEAR package Date comes in. Let’s see how we can convert a date in GMT to IST.

setTZByID("GMT");

// print server time
echo "Local time is " . $d->format("%A, %d %B %Y %T") . "\n";

// convert to IST
$d->convertTZByID("PST");

// output converted date/time
echo "Destination time is " . $d->format("%A, %d %B %Y %T");
?>

Put this code in some HTML page.

When the user opens that page, the command echo will write its IP address to the page.

So one of the things I like to do, all of the time, is trace. It started when I was a little child, and the rest of the kids could draw really good and stuff, and I couldn’t, so I would get pictures of horses and trace around them…

Now that I’m older, I still can’t draw, let alone code, very well, so I still trace.

In my Windows Azure apps, I like to trace to my own log files, it’s not the RoleManager.WriteToLog isn’t good, but I have code from other apps that already uses the trace infrastructure and pragma concepts, so having calls to Trace.WriteLine simply work as normal is a big attraction.

So how do you do this?

First, simply create your own custom trace listener and have it write to Windows Azure Storage.

Then load it into your role.

And now when you call the Trace.WriteLine for example, it will call your custom trace handler too.

Also, the sample below also has a little UI web role so you can see what’s being logged!

You can find the zip archive of the project here. I’ve scrubbed the .cscfg file so you can add your own links into it for your storage account and test URL for the pic it downloads.

Enjoy :)

Syndicated via RSS From: http://blogs.msdn.com/b/davidlem/

Create new C# project (Ctrl+Shift+N), and choose Console Application from the Templates menu on the right.
The editor will create the main code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace WriteToFile
{
  class Program
  {
    static void Main(string[] args)
    {

    }
  }
}

Below the using System.Text; add this code:

using System.IO;

Now, in the Main function add the folowing code:

StreamWriter sw = new StreamWriter("file.txt");
sw.WriteLine("Hello!");
sw.Write("CodingThis");
sw.Close();

As you see, in the above code we are creating an object from the StreamWriter class, and we tell the object to write in the file “file.txt” (if the file doesn’t exist, it will be created). So we are writing some text in the file using the WriteLine() and Write() functions. It’s used and the DateTime class, so in the text file will be written the time where the file was changed.
Very important is, when we finish with writing, we must close the file with sw.Close(). If the file isn’t closed, we are leaving an opened handle, so other programms can’t access that file.

This will be written to file:

Hello!
CodingThis