.Net Ramblings

I have always been annoyed by implementing the INotifyPropertyChange interface, which is needed if I want to take advantage of data binding for my class entities. I get annoyed because of how much code is involved in the Setter methods. Here’s an example:

public class Employee : INotifyPropertyChanged
{
  private string _name;

  public string Name
  {
    get { return _name; }
    set
    {
       if (_name != value)
       {
      	  _name = value;
          OnPropertyChanged("Name");
       }
    }
  }

  public event PropertyChangedEventHandler PropertyChanged;

  private void OnPropertyChanged(string propertyName)
  {
  	if (PropertyChanged != null)
    	  PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
  }
}

I hate all the if (_name != value) conditions that have to be in every setter, not to mention the lack of automatic refactoring since the property name is hard set. Therefore, I was really excited to see this post from my friend Jonathan Fuller and his much cleaner way of implementing INotifyPropertyChanged.

Be sure to read his entire post, but in a nutshell, by using his implementation, I would be able to cleanup the code above to the following:

public class Employee : NotifyPropertyChanged
{
  private string _name;

  public string Name
  {
     get { return _name; }
     set { SetProperty(()=> Name, ()=> _name, value); }
  }
}

Now that’s the kind of cleaning I like to see!

This past week I took the plunge and starting playing with NHibernate. I’ve wanted to use it for quite a while now, but it has a steep learning curve and I could never get a simple app to work. My main problem was that I wanted to use SQL Compact Edition as the database instead of SQL Server, and there aren’t many tutorials on getting the Compact Edition to work.

After much trial and error, I finally got NHibernate to work with SQL Compact Edition. Other than following the basic NHibernate configuration here are the additional steps I had to take to make NHibernate work with SQL Compact Edition.

• Add a reference of the System.Data.SqlServerCe to your project
  • Make sure to update its Copy Local property to True. By default it is set to False
    • When set to false, you will receive one of the two following errors:
    • The IDbCommand and IDbConnection implementation in the assembly System.Data.SqlServerCe could not be found. Ensure that the assembly System.Data.SqlServerCe is located in the application directory or in the Global Assembly Cache. If the assembly is in the GAC, use <qualifyAssembly/> element in the application configuration file to specify the full name of the assembly.
    • Could not create the driver from NHibernate.Driver.SqlServerCeDriver
      
• For computers running 64 bit processors: Make sure the project’s platform target is x86, not x64 nor Any CPU
  • This is a result of the ADO.Net provider not working with 64 bit systems
  • The setting is found in project Properties window under the Build tab.
    • Express Editions of Visual Studio do not have this drop down option in the Build tab. You will have to set the platform target by manually updating the .csproject file.
    • See this post for more information on updating the .csproj file
• Add SQL Compact Edition DLL’s to the project
  • These DLL’s are located in C:\Program Files\Microsoft SQL Server Compact Edition\v3.5
    • SQL Compact Edition must be installed on the computer
  • Add all the DLL’s starting with ‘sqlce‘
  • Set the Copy To Output Directory to true for all these files
  • This only needs done if you don’t want people to install SQL Compact Edition on their computer
• Nhibernate Configuration Settings
  • Latest version of NHibernate does not need the hibernate prefix to every setting
  • Below are 2 different ways to configure NHibernate
  • Programmatic Configuration

    IDictionary properties = new Dictionary();
    properties.Add("connection.driver_class", "NHibernate.Driver.SqlServerCeDriver");
    properties.Add("dialect", "NHibernate.Dialect.MsSqlCeDialect");
    properties.Add("connection.provider", "NHibernate.Connection.DriverConnectionProvider");
    properties.Add("connection.connection_string", "Data Source=MyDatabase.sdf; Password='some password'");
    Configuration conf = new Configuration();
    conf.Properties = properties;

  • App.config Configuration

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <configSections>
        <section name="hibernate-configuration" type="NHibernate.Cfg.ConfigurationSectionHandler,NHibernate" />
      </configSections>
      <hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
        <session-factory>
          <property name="connection.provider">
            NHibernate.Connection.DriverConnectionProvider
          </property>
          <property name="dialect">
            NHibernate.Dialect.MsSqlCeDialect
          </property>
          <property name="connection.driver_class">
            NHibernate.Driver.SqlServerCeDriver
          </property>
          <property name="connection.connection_string">
            Data Source=MyDatabase.sdf; Password='some password'
          </property>
        </session-factory
      </hibernate-configuration>
    </configuration>

You can also download a small sample app that uses SQL Compact Edition.

From Slashdot:

After years of boasting about the Mac’s near invincibility, Apple is now advising its customers to install security software on their computers. Apple - which has continually played on Windows’ vulnerability to viruses in its advertising campaigns - issued the advice in a low-key message on its support forums. ‘Apple encourages the widespread use of multiple antivirus utilities so that virus programmers have more than one application to circumvent, thus making the whole virus writing process more difficult.’ It goes on to recommend a handful of products.

This makes me laugh :-)

I started a new project today where I need to read data from an Excel spreadsheet. I’ve done this many times before by using the Microsoft.Jet.OleDb provider which allows me to write SQL statements to retrieve the data. Except this time around I am working on a x64 machine, and it turns out that Microsoft.Jet.OleDb doesn’t like playing with x64 operating systems.

I received the following error on my Vista x64 system when trying to connect to an Excel file through Microsoft.Jet.OleDb:

The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine.

After searching the net for a while I found the solution. I needed to compile the application to use the x86 platform. By default the platform target is ‘AnyCPU’ which is the platform the current machine is on (in my case x64). So no problem, I just had to change the platform target, which is easy enough to do in Visual Studio Standard or Pro Editions. You go to Project -> Properties -> Build then choose the platform target from the combo box. Well, I have Visual C# Express, and the Express edition does not have this combo box. So I had to manually open the .csproj file for the application and add the <PlatformTarget> tags. Below is an example.

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <PlatformTarget>x86</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <PlatformTarget>x86</PlatformTarget>
  </PropertyGroup>

Make sure to set the <PlatformTarget> tag in both the Debug and Release areas.

And that is the fix to read Excel files from an x64 machine.

The invoke method does not accept anonymous delegates, which makes the code below not compile

Invoke(delegate() { HelloTextbox.Text = "Hello World!"; });

However, the invoke method does accept MethodInvoker delegates, so you can cast an anonymous delegate to MethodInvoker like the code below

Invoke((MethodInvoker)delegate() { HelloTextbox.Text = "Hello World!"; });