What I was doing was to use it to write event entries in windows event log as part of the exception handling in an ASP.NET web application.  Nothing fancy.  It worked fine on my PC, but it didn’t write anything to the event log when Logger.Write is executed. No exception was thrown from that line of code either.  The program just went through as if that line of code was skipped.

It turned out to be a permission issue. When I debug the application in Visual Studio, it was running under my windows account credential which had permission to create Event Source in the system.  However, when the application was deployed to the server, it was running under the default account which was “NT Authority\Network Service” in my case.  By default, that account doesn’t have permission to create new Event Source in the system.  It does have permission to write event entries though.  So, when Logger.Write was executed, it couldn’t proceed because the Event Source wasn’t there, and the program didn’t have permission to create one.  Actually, it makes sense to not throw any exception on this line, because people like me usually use this to log exceptions, and if the logging process itself throws exceptions, there is probably nowhere else we can handle and/or log them.

Now, how this can be resolve?  The solution is quite simple.  As long as the Event Source is created ahead of time, it will be no problem.  What I did was to create required Event Source(s) on server through CMD.exe.  Here is a sample command:

eventcreate /ID 1 /L Application /T information /SO "My Event Source" /D "My Event Source is created."

This command will create an event entry in the Application log.  If the Event Source doesn’t exist, it will be created during the process.  This is only required when the application is deployed to the server first time.  So, I usually do it manually on server.  However, if that’s not the case, you can build it into the installation package, and when the application is installed, the Event Source is created as well.  Of course, you can use .NET to create Event Source in your installer too.

This pattern works, but sometimes it is tricky to generate a meaningful message.  The problem is that the exception can be thrown anywhere in your application, and the exception message may not always be appropriate or meaningful to end-users.  If you blindly display all exception messages you finally get, users may see something like “Object reference not set to an instance of an object” which doesn’t mean much to them.  So, in the final step of exception handling (where the program displays error messages or redirect users to an error page), you will see all kinds of exceptions which include .NET originated exceptions, exceptions raised by the program on purpose, and custom exceptions.  Some of them are appropriate to show to users, while others aren’t.  So, the question is how you can distinguish among them.

A lot of people suggest that if the original .NET exception message isn’t meaningful to users, and you can’t provide more specific message either, then a generic message such as “An error has occurred…  Please contact the technical support team for help” can be used.  I agree too.  You may do this where you know an exception can be thrown, and re-throw the exception with customized message (whether specific or generic) and with the original exception embedded as the inner exception of the new exception.  However, you don’t want to just put try/catch blocks in every piece of your code, and catch and re-throw every exception the program may possibly encounter.  It’s labor intensive and inefficient.  Also, there will always be something you can’t think of or look over, so there are still chances you can get unexpected exceptions in the end.

So, my solution is to let the program only catch and re-throw .NET originated exceptions when they are predictable and additional meaningful information can be provided, and let all other exceptions bubble up to the top tier.  Then in the final step of exception handling, identify the exceptions that are re-thrown, and retrieve the error message directly from these exceptions; use a generic error message for all other exceptions.  The question is how to identify these exceptions that are re-thrown.  For this purpose, I usually create a custom exception class which is inherited from System.Exception.  Use this class whenever I need to throw new exceptions or re-throw .NET originated exceptions.  So, in the final step, I check the type of the exception, and decide whether to use it as the error message or use a generic one instead.

Here is the custom exception class:

The ExceptionBase class has two constructors which give you the options to create an instance of exception with customized error message and with/without inner exception.

Here is how to use it in code:

Or

The central location I handle all exceptions is in global.asax, and here is what it looks like:

One note for this is that ASP.NET may put a wrapper exception (HttpUnhandledException) around the original exception.  In the code above, it is simply removed because it doesn’t contain any useful information.

You can also create more custom exception classes based on the ExceptionBase class to improve consistency in your application, and the code above will still work.  One example is:

This way the error messages for one type of exception are consistent across the application.

Here are a few things you will need to have on your computer to continue.

1. Windows Virtual PC 2007.  This is required, if you would like to connect the Device Emulator to your local network.  The software can be downloaded from Microsoft website.
2. Microsoft Visual Studio 2008.
3. Microsoft Device Emulator (which comes with VS2008).

With all the above requirements available on your computer, you can follow the steps below to configure your Device Emulator.

1. Start VS 2008 IDE.
2. On the menu, go to Tools >> Device Emulator Manager
   

   Start Device Emulator Manager

3. Right-click on a device you would like to use, and choose Connect option.
   

   Connect to A Mobile Device

4. After the device is connected, right-click on the connected device again, and choose Cradle.
   

   Cradle the Connected Device

5. Go to the device window.  On the menu, choose File >> Configure
   

   Configure Device

6. Go to the Network tab, and select the options as shown in the screen shot below.  And then click OK to close the window.
   

   Choose Network Card

7. In the device window, on the menu, choose File >> Reset >> Soft.  And wait until the device is restarted.
8. Now you need to configure the internet connection in the mobile device.  (The process could be different depending on what device you have picked.)  Normally, you would find the Settings option in the main menu, and then go to the Connections section to choose/define an internet connection.  Here below I use the device I chose as an example.
9. Choose Settings >> Connections >> Advanced >> Select Networks, and then choose My ISP for both Internet and Private Network connections.
   

   Choose Settings

   

   Choose Connections

   

   Choose Advanced Settings

   

   Choose My ISP

10. After confirming all these changes, you can now visit your mobile web application or internet using this Device Emulator.  Task accomplished!
    

    Your Mobile Website

After you’ve downloaded the developer tools installer, you will go through a download process…

After downloading the remaining components, you will install all component resources.

Once the developer tools have been installed, you can startup Visual Studio 2010 Express for Windows Phone which is the IDE used for the mobile development.

We will use the Silverlight for Windows Phone – Windows Phone Application project template and add some custom XAML and image resource to the base project.

In this simple application we’ve titled Mobile Portal just going to add some textblocks, buttons, and use a standard Silverlight grid layout. We first modify MainPage.xaml to create our custom view for the mobile application. Here is a view of our coding changes.

Next, we go to our Solution Explorer add our image resource using the context menu on the project and selecting Add -> Existing Item.

Finally, we add our custom styles to App.xaml. After building the solution and running the emulator, we see the following results.

If we rotate the device orientation, we can see how the view shifts to fit the space available.

We are glad to see that Microsoft is embracing the WPF and Silverlight-based development engine for the mobile platform. This decision allows developers and designers skilled in XAML to leverage their existing knowledge and prowess to create useful mobile applications for both business and pleasure. The small footprint of Silverlight makes it ideal for usage with embedded or mobile systems with limited power and memory.

You can download our complete solution here.

Following the Microsoft KB you can see that you need to edit the docicon.xml file located at the path C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\XML

The Docicon.xml configuration file is a listing of all document types that are supported by SharePoint. To support the PDF icon, you need to add the following Mapping XML element to the XPath //DocIcons/ByExtension. The Mappings are listed in alphabetical order, so you should insert the PDF mapping accordingly.

<Mapping Key="pdf" Value="pdficon.gif"/>

Here is the Docicon.xml file after the edit.

The next step is retrieving the small PDF icon from Adobe. When you have download the icon image, you need to save the image as “pdficon.gif” to match the mappings entry we created earlier. The last step is to copy the PDF icon image to the SharePoint template images path: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\IMAGES\pdficon.gif. This is the location where SharePoint will search for document type icons for rendering in document library views – according to the configured file extension mappings in docicon.xml.

After these steps have been completed, you can now visually distinguish the document type for PDF extensions with a quick icon type indicator.

Visual Studio has built in support for snippets, but some of the functionality is limited.  For a while, I have kept simple methods and queries stored in files on my computer for quick access.  I have found a simple solution for Visual Studio, as well as online for quickly accessing, storing and sharing routinely used snippets of code that will replace my old ways of storing snippets.

<code:keep> (www.CodeKeep.net) allows users to store and easily retrieve code snippets in many common programming languages.  At the time of this posting, there are currently 28 languages that you can store, share, and search.  There are two easy ways of adding and viewing your snippets.  First, is on their website.  The website allows you to not only view and manager your snippets, but it also lets you look through snippets other have chosen to share – when adding snippets, you have the ability to make your snippets private or public.  The other way to access snippets is through a Visual Studio add-in (available in for both Visual Studio 2005 and 2008).  Both options will let you store, browse, and search for code snippets.

Installation instructions

When installing, I recommend setting up an online account first.  This will make the installation flow a little more smoothly.  Make sure to have Visual Studio closed for the installation. Once you have an account setup, download and run the MSI to install CodeKeep.  Make sure the read the ReadMe file.  After installing the application, you will also need to copy three files into the Addins directory in you default project folder.

Once installed, the add-in is available through the Tools Menu

Because this is an online service, the snippets are not stored on your computer by default.   However, the website does allow users to export their snippets.  Whether you want to take them on the go, or simply back them up, browse to “My Snippets” and click Export Snippets.  All of your snippets can be saved to an XML file.


Note:  While using the add-in, I have hit a few bugs that will crash Visual Studio.   Upon restarting VS, I get an error “Object reference not set to an instance of an object”.  To get rid of this, I had run the MSI again and  repair the installation.

This also required me to log into my account again.

When you receive your access token, you can begin creating projects on the Azure platform with the Azure Developer Portal. You can only create one project with the CTP, but you can have multiple services inside each project (web/worker roles).

After you’ve created your project in the developer portal, you can add services which will be the endpoints you deploy to for Windows Azure. We will add a Windows Azure Service in this example.

To create our Windows Azure application, we need to create a package (cspkg) that contains our application contents and a configuration definition (cscfg) that defines our roles. Microsoft has created Azure tools to assist in generating the package and configuration file. You can download the Azure SDK to create Azure applications using Visual Studio. The Azure SDK allows you to run your own local development fabric before pushing your application into the cloud. Eclipse also has its own Azure Tools if you prefer to develop in the Eclipse environment.

After installation of the Azure Tools, you now have a new project template “Cloud Service” which we’ll use to create our web role.

After clicking “Ok”, you will now have a Cloud Service project and a Web Role project in your solution. We will now remove the Web Role for this exercise, and replace it with an existing ASP.NET application called ASP.NET Chart Controls which Scott Guthrie announced last year. This application did not work on the PDC release of Azure, but Azure now allows web applications to run in Full Trust with some minor tweaking.

We now have our solution complete and have one web role we would like to deploy to the cloud. We must now publish the solution to Azure. We right-click on the Cloud Service project and click “Publish” which opens up the Azure Developer Portal.

After logging in with Windows Live, you want to deploy your application to the Staging Environment before pushing it live. To deploy, you simply select the application package (cspkg) and configuration definition (cscfg) from your “/publish” folder in the cloud service “/bin/Debug” directory.

Clicking on “Deploy” will load the Azure package and service definition to the cloud and create a VM necessary to run the application. The environment takes some time to setup and will show its state as “Initialization” until the VM is entirely ready. You are given a URI based upon a randomly generated GUID to view your application and test it before moving it into production. Having two environments is nice if you also have database changes that need to coincide with your deployment.

Once the application has been verified, you can click the center arrows icon to swap the Staging site into Production. You can see the two environments have now been switched.

Azure does make the deployment process a bit more involved, but there is an managed Azure Deployment API in the works to automate the build and deploy steps you may need in your organization. You can view our sample ASP.NET Chart Controls application running on Azure Services (cloudapp.net). Kudos to Microsoft for allowing full trust applications! We will be watching for more exciting features from the Azure Team.

You can download EWS from Microsoft (currently an RC) and begin interacting immediately with any server running Exchange 2010 or Exchange 2007 running SP1 or higher. The web service interaction requires SSL and a valid Network Credential for access. The base service is hosted on exchange via the EWS URL below, where <exchange_server_name> is the host name of your Exchange server.

https://<exchange_server_name>/ews/exchange.asmx

To try out EWS in a test environment, you can download the Exchange 2007 virtual machine. Once the Exchange VM (VHD) is running and you are logged in, you need to configure the network settings to utilize automatic IP and DNS settings instead of the default static ones provided. This will assist in routing network traffic to the new machine. To verify the setup, you can browse the following URL below and see the WSDL for the EWS. You will need to ignore the certificate warning and enter a login with access to the service (login as litwareinc\Administrator)

https://ex07sp1/ews/exchange.asmx

The next step is installing EWS. After installation, you can begin creating Visual Studio projects using the new API. MSDN provides a nice introduction and valuable references for working with the managed API. After creating a new Visual Studio project, you need to add a reference to the new assembly Microsoft.Exchange.Webservices.dll (located at the path Program Files\Microsoft\Exchange\Web Services\1.0\ ). Next, we add using statements for the new library reference and also for X509 certificates.

using Microsoft.Exchange.WebServices.Data;
using System.Security.Cryptography.X509Certificates;

Now here’s some simple code to create a connection to the EWS endpoint. The certificate callback is necessary since we’re using a user-generated X509 certificate.

// Hook up the cert callback.
            ServicePointManager.ServerCertificateValidationCallback =
                delegate(Object obj, X509Certificate certificate, X509Chain chain, SslPolicyErrors errors)
                {
                    // Validate the certificate and return true or false as appropriate.
                    // Note that it not a good practice to always return true because not
                    // all certificates should be trusted.
                    return true;
                };

            // assign exchange version
            ExchangeVersion version = ExchangeVersion.Exchange2007_SP1;

            // create service endpoint connection
            ExchangeService service = new ExchangeService(version);

            // Assign NetworkCredential directly
            service.Credentials = new NetworkCredential("username", "password", "domain");

            // EWS network location
            service.Url = new Uri("https://ex07sp1/ews/exchange.asmx");

Now we’ll create an appointment using this service endpoint. Note: When you add attendees, you actual create a meeting instead of an appointment.

            Appointment appt = new Appointment(service);
            appt.Subject = "Read EWS Documentation";
            appt.Body = "You can download the Exchange 2007 SP2 here: <a href='http://www.microsoft.com/downloads/thankyou.aspx?familyId=ee7829a3-0ae8-44de-822c-908cd1034523&displayLang=en'>SP2 Download</a>";
            appt.StartTimeZone = TimeZoneInfo.Local;
            appt.Start = DateTime.Now.AddDays(1);
            appt.ReminderMinutesBeforeStart = 15;
            appt.End = appt.Start.AddHours(2);
            appt.RequiredAttendees.Add("Administrator@litwareinc.com");
            appt.Save(); // persisted to exchange

To probe deeper, you can follow the exchange developer blog on MSDN. We look forward to the RTM of this powerful managed Exchange API.

The resolution to the BizTalk memory problem relied in the source structure (MemoryStream) we were using for storing our stream for the IBaseMessage.

MemoryStream revisedStream = new MemoryStream();

The discussion helpfully points out that we should be using the VirtualStream with a few caveats. The trick to get the VirtualStream object is to include the source from the BizTalk server samples (<BizTalk Install Path>\SDK\Samples\Pipelines\SchemaResolverComponent\SchemaResolverFlatFileDasm) or use the Microsoft.BizTalk.Streaming.dll as it exists in the GAC (<Windows Path>\assembly\GAC_MSIL\Microsoft.BizTalk.Streaming\3.0.1.0__31bf3856ad364e35\). I chose the later approach, which required adding a reference to Microsoft.BizTalk.Streaming.dll to my custom pipeline solution. I first copied the assembly from the GAC to the <biztalk install path> for future solutions where I may need to reuse the same assembly source. After adding the reference via Visual Studio, it was simply a matter of changing the MemoryStream reference to VirtualStream.

VirtualStream revisedStream = new VirtualStream();

Be sure you rewind the stream before assigning the bodyparts data.

// Rewind the stream so it is ready for use by the messaging engine
revisedStream.Seek(0, SeekOrigin.Begin);

So why does this solution work? Behind the scenes, VirtualStream is wrapping excessive data (user defined, but defaults to >4MB) to temporary disk using a BufferedStream. This is why we can avoid the “System.OutOfMemoryException” – since the VirtualStream will offload the large data stream to disk I/O instead of purely storing our IBaseMessage in RAM (via MemoryStream). Yes, there’s certainly overhead depending on where your temporary directory resides, but in most cases this will be the solution you’re looking for. MSDN docs has other BizTalk specific streams if you want to dive deeper.

The new foundations Board of Directors has some influential players in the OSS realm. One of the directors is Miguel de Icaza, creator of GNOME and currently the project leader in both Mono and Moonlight. Miguel has his own enlightening comments on the new foundation. Another member of the board is Shaun Walker, the original creator of the DotNetNuke project, an incredibly popular OSS web platform.

The goal of the foundation is to bring commercial and OSS communities closer together (e.g. get commercial developers working in OSS projects). The Advisory Panel has some interesting members including Phil Haack, Scott Hanselman, and Larry Augustin. Larry is now CEO of SugarCRM, a popular non-microsoft based OSS web platform. Hanselman also shares some insights into the new foundation.

It’s great to see Microsoft attempting to bridge the gap that exists between developers of OSS and commercial software, but only time will tell if this investment pays off. Software will continue to get better, especially with the OSS community involvement that Microsoft is slowly embracing.