How to fix the ugly ass Ubuntu boot splash OR Damn, Ubuntu, you ugly

TL;WR: http://news.softpedia.com/news/How-to-Fix-the-Big-and-Ugly-Plymouth-Logo-in-Ubuntu-10-04-140810.shtml

If you've had Ubuntu for a while and you've got an nVidia video card, chances are you've got the ugly ass default boot screen. Fortunately, you can fix this. You just need to follow the instructions above. I hope you're comfortable with the command line.

Changing the password complexity requirements on Windows Server

To change the password complexity requirements on Windows Server (2008 at least) (for whatever reason), do the following :

Start -> Run -> gpedit.msc -> Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy

Then in the right-hand policy pane, set 'Password must meet complexity requirements' to 'Disabled' (right-click -> Properties)

Journey to robust windows services: Service could not be installed. Verify that you have sufficient privileges to install system services

This is an annoying and almost entirely useless error. It can be caused by any number of things. However, in my case today, it was caused by the fact that the EventLog Source hadn't been created when I tried to install my Windows Service using the WiX installer that I had developed (which it turned out wasn't quite complete). Fortunately, WiX (at least as of 3.5) has built-in support for creating Windows Event Log sources as part of the installation process. Fortunately, I was able to rely on this article on stackoverflow.com to guide me through the process. The gist of the article:

1. Add the "http://schemas.microsoft.com/wix/UtilExtension" namespace to your .wxs file root XML element
2. Add a util:EventSource Log="Application" Name="MyServiceLogSourceName" EventMessageFile="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll" element to each component which requires an Event Log source
3. Problem solved

Journey to robust windows services: debugging your WiX custom actions

I've recently had some trouble getting WiX custom actions to work, and after searching around for a while, I found this article. It gives the reader two options for how to debug WiX custom actions, but I had to use both in combination to get it to work. I'll repeat the steps here, just in case the link goes stale:

1. Follow all the necessary steps to create a WiX setup project, along with a separate Custom Action project (available as a project type in the New Project dialog in Visual Studio 2010+ with WiX 3.7)
2. After you've created your custom action method and gotten the project building, add System.Diagnostics.Debugger.Launch(); at the beginning of your custom action method. This will kick the custom action into the debugger so that you can debug it (assuming you've got the wixpdb in the same directory from which you launched the installer).
3. Go to Control Panel -> System -> Advanced System Settings -> Advanced (tab) -> Environment Settings (button) -> System Variables (group) -> New .... (button) 
4. In the dialog that comes up, create a new variable called 'MMsiBreak' (without the quotes) and give it the value of your custom action method (e.g. MyCustomActionMethod)
5. Now run the debug version of your installer and it should get kicked right into your method and allow you to debug your custom action.

Journey to robust windows services: creating custom actions for your WiX installers

I've lately been trying to update my WiX installers to perform custom actions so that I can do some security configuration of my applications after they're installed. I got started with this article on CodeProject, but it was missing some information. Apparently, in addition to creating the separate project for the CustomAction DLL, you need to include as part of that assembly a CustomAction.config file with the following contents:

xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v2.0" />
        <supportedRuntime version="v3.5" />
        <supportedRuntime version="v4.0" />
    </startup>
</configuration>

But what really got the thing working was targeting the CustomAction DLL to .NET framework v3.5, rather than 4.0 because I was getting some bad image format exceptions when trying to run it. Thankfully I found the MSDN article on enabling MSI logging. These two articles on stackoverflow.com also really helped out.

Journey to robust web services: installing a WCF 4.0 application on IIS 6.0

Due to budget and other constraints, I'm unable to get my hands on the latest and greatest software for running a WCF application I've been working on, so I'm forced to use what my company's got: Windows Server 2003 and IIS 6.0. Suffice it to say that working with these old bits of software are less than ideal. However, I'm stuck with it. So, moving forward, here's some of the things I found while working on the application:

1. There's no easy way to set certain items in the registry for the Network Service user. (Sorry, for various reasons, I can't elaborate on that statement.)
2. Due to (1), I've decided to run my application as a custom normal (non-Administrator) user that I've created. However in order to use this user with IIS and its applications, certain steps must be taken.

Using a custom user to run an IIS 6.0 application

The following are pre-requisites in order to be able to use a custom user to run an IIS 6.0 application:

• The user must have already been created and should have absolutely the least number of privileges possible.
• Thanks to this question on Stack Overflow, the following must also have the following:
• The "Log on as a service" right (Start -> Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment -> Log on as a service)
• "Access this computer from the network" (similar location as in the step above)
• "Deny logon locally"
• "Log on as a batch job"
•  "Read & Execute", "List Folder Contents" and "Read" access to the file system that underpins the web site/application
• Thanks to this troubleshooting article on MSDN, I also found out that the user must be part of the "IIS_WPG" group.

I now have other problems to worry about with this application, but at least now I know that they're not related to how I'm running the application in IIS.

Journey to robust web services: apparently we shouldn't use 'using'

I recently stumbled across an article stating why we shouldn't use the 'using' keyword with WCF services, and I found it rather interesting. I'd have to re-read it, and re-evaluate it, before I use it but you can read the blog post on the original site.

Journey to robust webservices: kickstarting use of certificates phase II: using certificates for client authentication

There are a number of means of authenticating users, and one of the most secure is via a certificate. This article on CodeProject provides a start. Unfortunately, the article doesn't really mention a few things:

1. Depending on how you ran the tools, you may have inadvertently run the commands it gives you as an administrator. I ran them in a console that I already had open that was running as administrator, so they were installed as administrator, and I also happened to have been running in Visual Studio as an administrator at the time, so everything happily worked. Then when I rebooted my machine this morning and was running as a normal user, nothing worked, and I wasted over an hour trying to figure out why. That was why. Regardless of how you generated and installed the keys, you should go and explicitly grant permissions on the key to the users you want to have access to them. On the Microsoft website, there is a bundle of WCF samples (which you can find here). Included in the samples is a tool called FindPrivateKey. Download the samples, compile the program, and use it to find the key that you just generated. You'll need a command similar to the following : "C:\Samples\WCFWFCardSpace\WCF\Tools\FindPrivateKey\CS\bin\FindPrivateKey.exe My LocalMachine -t "28 ce e3 2c 7e 05 3a 97 a0 b4 92 fd d5 b0 f9 de 0e 4c 2e 4b"" where the value in quotes is the thumbprint of the non-signing (client) key you generated in the instructions from the article. Once it spits out the location of the file, you'll need to go and alter its permissions to allow whatever user your server / client application is running under access to the file.
2. Depending on the binding you're using with WCF on the server side, you may need to have a certificate with full chain trust on the IIS server (or other?) in order to use the binding (*cough* basicHttpBinding and any other transport-only security bindings *cough*). With that in mind, after you've generated the certificates in the article, while you're in the certificate manager MMC snap-in, you'll also need to copy (not move) the IIS developer certificate used in IIS to the "Trusted Root Certification Authorities" store.

Journey to robust web services: kick starting use of credentials and certificates for message security, phase I

As any sensible developer of a large scale system knows, security is paramount. Therefore, encryption of sensitive data is an absolute must, encryption of all data is recommended, depending on the field in which you're working. Encryption with WCF is baked in, and is relatively straight forward to setup, though there are a number of important details to which attention must be paid. The steps are somewhat different depending on whether you're using IIS or a self-hosted service (e.g. in a Windows Service).

If you're using a Windows Service, you'll need to perform the following steps to get started:

1. Generate a self-signed certificate (which can be done in the Windows Control Panel)
2. Configure the port to which you're binding the service with the certificate you've just generated, according to this MSDN article. 
3. [to be continued]

If you're using IIS, getting started in a development environment is somewhat simpler.

1. Generate a self signed certificate with IIS. In most cases, IIS will have a developer certificate already installed that you can use.
2. Retrieve the thumbprint of the certificate. You'll need this in order for your application to be able to find it at runtime. WARNING: Don't just copy the thumbprint out of the certificate properties window in IIS, because there are non-printing characters in the text control that will cause you problems when you try to paste the thumbprint into your Web.config file. Write them out by hand.
3. There are two methods you can take for making the certificate available to your WCF service:
1. Follow the guide here if you want to make the certificate available to your application by code.
2. Use the information on this page to create a element underneath a configuration/system.serviceModel/behaviors/behavior/serviceCredentials element.

Journey to robust web services: debugging services and logging messages

One of the quickest and best ways to debug issues with the services you're developing is to log and trace all activity with WCF along with the messages being sent back and forth. This page on MSDN will provide you with the instructions required to setup logging and tracking for WCF.

Journey to robust web services: my clients are unable to connect!

I've been testing out some web services I've been working on extensively on my own machine, but the time has finally come where I want to start making clients that aren't running on the same machine. In one case, I have a WCF service running on Windows 7, but the client I want to connect to that service is running on Windows 8 on a separate machine. When I tried to connect, I would get a variety of errors, the most common of which being that the socket on the server was forcibly closed. I Googled around a bit, and the most common cause of this problem that I found was that the server's quota's were being reached and therefore the client was being rejected, however this shouldn't have been the case for me since there was no way my quota's could have been reached. After further research, I found that since I don't want security (yet), I had to apply some settings in order for clients that weren't on my localhost to connect. In order to allow external clients to connect, I had to change the following :

1. In my , I had to change my base address to use the network name of my computer (rather than localhost) in the base address URL.
2. In the net.tcp and ws2007HttpBindings for my services, I had to go to the the child element of the elements, and explicitly set mode="None" on those elements, otherwise they may assume some form of security by default depending on the type of the binding.

Now, I did mention above that I don't want to add security (*YET*) being the important qualifier of that statement. Security is of course always paramount, and should always be baked into a product as early as possible. As soon as I get to it, I'll add a post about all the steps required to add security to your WCF clients and services, along with links to the relevant MSDN articles (and any other useful ones that I may find.

Mono.Options installation, and getting StyleCop to ignore a file

I've recently discovered the Mono.Options library (available via NuGet) that lets you easily parse arguments passed into a program. Unfortunately, the ease with which a package is typically installed via NuGet does not apply to Mono.Options because it's a single .cs file that gets included in your project, rather than a signed assembly. This becomes an annoyance in projects where StyleCop is used to enforce coding standards. Fortunately, there is a way to get StyleCop to ignore specific files (rather than forcing me to tweak my StyleCop settings for the project) which I found out about here. The TL;DR for that article: edit your project file, and underneath the element for the offending file, insert a <ExcludeFromStyleCop>true</ExcludeFromStyleCop> element.

Creating a logging service using the Microsoft Enterprise Library Logging Application Block

As part of my recent foray into creating various Windows services, I've come across the need for logging (like all serious apps do) and decided to use the Microsoft Enterprise Library Logging Application Block. We used it at a previous company and it got very good reviews from the developers there who used it. Unfortunately, all of the tutorials out there are a bit useless when it comes to doing anything real with the Logging Application Block, like using custom configuration. Fortunately, it was easy enough to figure out how to get customized configuration of logging working just by looking in the assembly and writing some unit tests to experiment.

For my needs, I like to keep all of my configuration as compartmentalized as possible. To that end, I usually end up using .NET Configuration files on a per-assembly basis. Fortunately, this works very well with the Logging Application Block because you can configure logging with arbitrary Configuration files. To get custom logging working easily in Visual Studio, do the following:

1. Open Visual Studio (I'm using 2010)
2. Install NuGet from the Extension Manager, if you haven't already.
3. Install EnterpriseLibrary.Config from the Extension Manager if you haven't already.
4. Create your solution and project that requires logging.
5. If your project (web or application) comes with a .config file already (i.e. Web.config or App.config respectively) you can use that, otherwise, you can create an app.config file for the assembly in which you're creating your logging service.
6. Once you've figured out which app.config (or Web.config) file you're going to be using (i.e. the same assembly where you're placing your logging class, right click on the .config file. You should see an 'Edit configuration file' entry with an orange logo (provided by the add-in installed in Step 3 above).
7. Follow any other tutorial out there on the internet for configuring the Logging Application Block. (repeating such information here would be redundant and pointless). There's one such article here.
8. Now that you've got your configuration, create a class to be your logging service wrapper.
9. Figure out where your application config file is going to end up after your application is built.
10. In your logging service wrapper, create a Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, giving the configuration file path as the sole parameter to the constructor.
11. Create a new Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterFactory, providing the FileConfigurationSource you just created as the sole parameter. You'll probably want to store this as a static object, because we only need a single factory.
12. For each instance of your logging service, use this static factory that you've created to create a LogWriter.
13. Implement whatever methods you need to wrap the logging service.
14. You're done.

Your code should now look something like the following :

    using System;
    using System.Diagnostics;
    using System.Diagnostics.CodeAnalysis;
    using System.IO;
    using System.Text;
    using Interfaces;
    using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
    using Microsoft.Practices.EnterpriseLibrary.Logging;
    using Support.Extensions;

    /// 

    /// A logging services that uses the Microsoft Enterprise Patterns and 
    /// Practices library to provide logging support.
    /// 
    public class MicrosoftPracticesLoggingService : ILoggingService
    {
        /// 

        /// The log writer factory
        /// 
        private static readonly LogWriterFactory LogWriterFactory;

        /// 

        /// Initializes the  class.
        /// 
        static MicrosoftPracticesLoggingService()
        {
            string configFilePath = typeof(MicrosoftPracticesLoggingService).Assembly.GetCodeBaseFile().FullName + ".config";

            if (File.Exists(configFilePath) == false)
            {
                throw new InvalidOperationException(String.Format("Configuration file could not be found at '{0}'", configFilePath));
            }

            FileConfigurationSource configSource = new FileConfigurationSource(configFilePath);

            LogWriterFactory = new LogWriterFactory(configSource);
        }

        /// 

        /// The log writer used by this service to write to logs.
        /// 
        private readonly LogWriter logWriter;

        /// 

        /// Initializes a new instance of the  class.
        /// 
        public MicrosoftPracticesLoggingService()
        {
            this.logWriter = LogWriterFactory.Create();
        }

        #region Implementation of ILoggingService

        /// 
        [SuppressMessage("Microsoft.StyleCop.CSharp.DocumentationRules", "SA1604:ElementDocumentationMustHaveSummary", Justification = "InheritDoc")]
        [SuppressMessage("Microsoft.StyleCop.CSharp.DocumentationRules", "SA1611:ElementParametersMustBeDocumented", Justification = "InheritDoc")]
        public void LogException(Exception ex, string messageFormat, params object[] parameters)
        {
            if (ex == null)
            {
                throw new ArgumentNullException("ex");
            }

            if (messageFormat == null)
            {
                throw new ArgumentNullException("messageFormat");
            }

            StringBuilder messageBuilder = new StringBuilder();

            messageBuilder.AppendFormat(messageFormat, parameters).AppendLine();
            messageBuilder.AppendLine(ex.StackTrace);

            if (ex.InnerException != null)
            {
                Exception root = ex;

                while (root.InnerException != null)
                {
                    root = root.InnerException;
                }

                messageBuilder.AppendLine("Caused by:");
                messageBuilder.AppendLine(root.StackTrace); 
            }

            LogEntry logEntry = new LogEntry
                {
                    Message = messageBuilder.ToString(),
                    Severity = TraceEventType.Error
                };

            this.logWriter.Write(logEntry);
        }

        #endregion
    }

Journey to robust web services: debugging a net.tcp service

I'm creating a net.tcp-based WCF web service for use with my current project, and so far the learning curve hasn't been very shallow. I've just recently learned, thanks to this post on Stack Overflow, that the default ASP.NET application doesn't support the net.tcp protocol, so IIS must be used instead. With that in mind, I've decided to move on to just using the Web Service I'm creating through a Windows Service via a ServiceHost. However, I've now encountered some problems debugging the Windows Service startup. This page on MSDN contains links and instructions on how to debug the startup of a Windows Service. While attempting to install the Debugging tools, I encountered a failure trying to install them as part of the Windows 7 SDK. This page on Stack Overflow had a solution, but it wasn't quite complete. This page had the missing parts.

Journey to robust web services: configuring your WCF web service

WCF comes with a bunch of handy configuration tools.  You can find an introduction to them on the WCF configuration tools page on MSDN. Once you've created your WCF service project in Visual Studio, you'll need to use these tools to configure the service beyond a simple and basic test environment (which uses a Basic HTTP binding by default).

The specific tool mentioned on this page that you'll want to use is the Service Configuration Editor (svcconfigeditor.exe). This tool is used to edit Web.config files for WCF services. It comes with a handy wizard for adding a new service. When using this wizard, I ran into an error message similar to the following when trying to select the assembly I built containing my service: "Could not load assembly. This assembly is built by a newer runtime than the currently loaded runtime and cannot be loaded.". To solve this, I had to go and change the application configuration file for the program ("svcconfigeditor.exe.config" in the same directory as the program). I added the following under the root 'configuration' element:

 <startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v2.0" />
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
 </startup>

This will allow the program to run using your currently installed framework (mine happened to be 4.0).

Finally understand the purpose of event accessors in .NET

As most people who deal with .NET are aware, C# (and also VB.NET) have Properties and Events.  In the case of properties, there are property accessors (get and set) which you can leave to the compiler to define, or you can define your own custom accessors. Similarly, there are event accessors (e.g. add and remove) so that you can customize subscriptions to your event handlers. Until today, I never understood why, until I read the MSDN article on Advanced C#. The reason is explained near the end of the section called "Standard Event Pattern", and it's pretty simple and common sense: in classes where you have a significant number of events (e.g. WPF / Forms Controls) and only a few of them are likely to be subscribed to, you can achieve a smaller memory footprint by overriding the event accessors and placing the event subscribers in an internal IDictionary, rather than using compiler-generated event accessors. In the former case, you'll have to store only the subscribers + the dictionary, whereas in the latter case, you'll have to store the subscribers + n events, and the latter is likely to be far larger than the former.

Getting error message with XSD MSBuild task

Lately I've been getting the error message :

error MSB4018: Microsoft.Build.Shared.InternalErrorException: MSB0001: Internal MSBuild Error: xsd.exe unexpectedly not a rooted path

... while I've been building a project that uses that task in a pre-build step to generate code from XSDs. After googling around a little bit, I found the solution on this page. The gist of it was that xsd.exe wasn't in the PATH variable, and therefore Visual Studio couldn't find it. If anybody else has this problem, add this folder to your PATH:

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools

... or your system's equivalent, wherever the XSD.exe tool is stored on your system.

Debugging multiple processes and following the children in Eclipse Juno

I guess Eclipse has made it much easier in recent versions of Eclipse and CDT to debug multiple processes and have the debugger follow children. It was actually easier than I had thought it would be to get this functionality in Eclipse Juno. To do so, follow these steps:

1. Create your debug configuration, pointing to the project and program you require. 
2. Ensure that you setup your LD_LIBRARY_PATH in your environment variables as necessary.
3. (and here's the really important part) In the Debug Configuration, go to the 'Debugger' tab. You should see a groupbox called 'Debugger Options' containing (at least) two tabs: 'Main' and 'Shared Libraries'. On the 'Main' tab, ensure that you have 'Non-stop mode' and 'Automatically debug forked processes'. In order to get these abilities, you'll need to have both non-stop gdb and multi-process gdb
4. As a side note, you may need to also have your debug configuration pointed to a custom gdbinit command file with the following line:
• set follow-fork-mode child

This is admittedly a pretty high-level overview of how to get things going, but if I ever have any problems with this in the future, I'll post more details. Or if people ask me :P

Using key gestures with parameterized Commands in WPF is "broken"

Ok, it's not actually broken, it just doesn't work the way I wanted (or expected). Apparently, there's a very good article on why they don't work the way I expected. To be clear, the way I expected them to work was:

1. Define the command as a static RoutedUICommand and set the keyboard / mouse gestures I wanted on the command's InputGestures collection.
2. Use said command in MenuItems, Buttons etc.
3. Automatically have keyboard / mouse bindings setup everywhere (including the nice shortcut text on menu items in context menus / menu bar menus)

Turns out, no, and it's by design of the WPF team. See the article above for the explanation. At least now I know there's a good reason why it's not working, and I have a starting point for getting the key / mouse gesture functionality that I want.

Getting the proper Includes to show up in the project explorer in Eclipse with CDT with a cross-compiling project

I finally learned how, and it's thanks to an awesome question posted on stackoverflow.com .