I start to gain a little insight on why it’s like this the other day. When we install our server components, which is solely SQL Server 2005 Express with a database including stored procedures and triggers, we have an installation package where you just have to click on setup.exe and let it do its thing. When I called the main contact at the IT department, I heard the hesitancy in his voice. I assured him he could do the installation if he preferred not giving me remote access to the server, but he insisted that I do it for him. No problem. Since we are customer focused, we always try to do the client and server installs of our software, anyway. I downloaded the files I needed and clicked on the setup program and just sat there while it went through the entire process. We chit-chatted about servers and Microsoft and had a few laughs over the new security requirements. He then described multiple instances where servers were down for a day or two because of patches that didn’t apply right and how he has had to call Microsoft dozens of times to get hotfixes or special patches because the combination of hardware and software they use is not normal. I usually do not get concerned when I hear this because we don’t usually care what they use, as long as Exchange Server is not on the same server as SQL Server.

After 15 minutes and clicking next a few times, our install was done. He said, “Ok, so what do we do now?” My response was simple, “Nothing. It’s all ready.” He was disbelieving and ran the client software and tried a few things to check. The next 10 minutes was eye opening. He described how this was the best install he has had to watch in a long time and was very pleased that we were so IT friendly. He described a situation that made me, as a software developer, cringe. They had purchased a brand new accounting system that cost their organization almost a hundred thousand dollars (US funds) and the installation took about 3 days. It took 3 days because they gave him the CDs and said to install it, but never gave him any instructions on how. Being used to installing software, he put in the CD marked #1 and ran the setup. It half way installed and then gave a half dozen error messages that consisted of things like “Error Occurs” and “Cannot Continue.” He tried called technical support and all he got was voice mails. He left messages but never received any phone calls in return.

He spent the next 3 days trying to solve the all problems himself, but with no documentation on requirements or procedures. When technical support finally called him back, the solution was to install the third CD first and then try the first CD. Why would you install a CD marked #3 before the CD marked #1? He told me that now he is highly concerned that they made the right choice because it’s their accounting system and how can they trust the vendor’s technical support department if he can’t get an answer in less than 3 days? What if they need to do payroll and “error occurs” and technical support doesn’t return phone calls?

This is why there is animosity between IT and software developers. Make it easy for them. Give descriptive error messages and most certainly answer your phone if it rings! Even if you know it’s a stupid problem they should be able to solve just by reading the screen, at least that phone call will keep their confidence that you will be there where there is a problem.

One of the concerns most developers had, especially when working with Linq to SQL data classes, was the relative speed at retrieving data from the SQL server. They were pretty right about that. It’s slow. Much slower than even using datasets with table adapters. However, using compiled queries can help.

One thing some people never took into consideration was the relative ease that Developer’s Express users can now use server mode without having to use the proprietary XPO classes. Their XtraGrid’s now support ServerMode which will page SQL queries in windows forms applications. One issue we had were slow VPN clients trying to use a windows form application installed locally and connecting to a remote SQL Server. Until recently we have had to tell users to use terminal services instead. Some forms have to show a relatively large amount of data in a single grid (finding customers, paging through certain data, etc). Over a VPN connection it was just painfully slow. Now combining XtraGrid’s and the Linq Server Mode, everything works as expected over a slow (1.5 MB DSL even) VPN connection.

Check it out. The link is at the top. It’s quite empty right now…

Did anyone at Microsoft actually use this scenario in a production environment? What were they thinking?

In order to run that in a production environment you have to set the connection string in the app.config file. While this may be fine for some people, what about the people like me that do not want my users to access that database? I don’t want them to have that username and password… While the chances of a normal user loading SQL Server Management Studio and logging in are slim, it’s still possible and it’s definitely possible if a user purposely wants to get out of having to do work that day.

What are the options? Well, one option is to use the encryption to encrypt the settings in app.config. For me, this option is not ideal. Reports of those settings getting corrupted are quite high, plus you have to deal with the loading and saving of those settings, which isn’t all that easy to do.

The other option is to take the route I was taking for a while… I had a function that would build me a connection string. Then I could: TableAdapter.Connection.ConnectionString = myLibrary.ConnectionStringFunction()

This was great, until that day came where I was in a hurry and added a few more tables to a form but forgot to set the ConnectionStrings. Whoops.

So I needed a solution that would stop me from having to set those ConnectionString properties, keep my connection string out of the app.config, and be easy to use (i.e. Just Works).

I started out by just giving all my datasets the same connection string. Then on application startup, I tried to change that one application setting. Hmm.. It seems those ConnectionString properties are set to friend and are read only.

Upon further investigation, it seems that there are some events that fire, such as SettingsLoaded. This event fires when the app.config is read and all the settings are loaded. When this event fires, it fires inside the MySettings class. This should allow that property to be changed.

    Private Sub MySettings_SettingsLoaded(ByVal sender As Object, ByVal e As System.Configuration.SettingsLoadedEventArgs) Handles Me.SettingsLoaded
      Me.Item("MyAppConnectionString") = MyLibrary.BuildConnectionString()
    End Sub

This will set the MyAppConnectionString setting to the proper connection string. Now, all table adapters will have an up to date connection string.

So what happens if you want to change the connection string later while the application is still running? Well, there is no way to do that. So it’s time to come up with a way to trick it into updating that property.

In looking at the MySettings class, there is another event called PropertyChanged. We can use this event if we create another setting that can be updated anywhere in the application. First, we create a new string setting that has a User scope (I called mine ConnectionString). This will allow the application to update the setting at any time.

Next, we need to create a function that will update that property with our connection string.

  Public Shared Sub ChangeConnectionString()
    My.Settings.ConnectionString = BuildConnectionString()
  End Sub

Now we can change the events in the MySettings class to look like this.

    Private Sub MySettings_PropertyChanged(ByVal sender As Object, ByVal e As System.ComponentModel.PropertyChangedEventArgs) Handles Me.PropertyChanged
      If e.PropertyName = "ConnectionString" Then
        Me.Item("MyAppConnectionString") = My.Settings.ConnectionString
      End If
    End Sub

    Private Sub MySettings_SettingsLoaded(ByVal sender As Object, ByVal e As System.Configuration.SettingsLoadedEventArgs) Handles Me.SettingsLoaded
      MyLibrary.ChangeConnectionString()
    End Sub
  End Class

Now, every time that ChangeConnectionString() is called, the MyAppConnectionString will be updated. The ChangeConnectionString procedure can be changed so that it can accept a string parameter that is the actual connection string. Then you can build a Connection String anywhere and just pass it to that procedure.

One thing I was looking for in a new template, was a fluid layout. It seems the wordpress themes for fluid layouts are pretty scarce. Especially ones that look good. I will stick with this one for the time being and see how it works. I think my code highlighter will fix the reason I wanted a fluid layout anyway.

This happens in VB a lot if you forget to call the Dispose method of the SQLConnection object or if you don’t use the Using keyword. While cleaning up code, the best way to get in the habit of doing it, seems to be changing everything into a Using statement so I get in the habit of using it…
Instead of:

    Dim myCommand As New SqlClient.SqlCommand("Select Count(*) from MyTable")
    Dim myConnection As New SqlClient.SqlConnection(ConnectionString)
    myCommand.Connection = myConnection
    myConnection.Open()
    Dim iCount As Integer = CInt(myCommand.ExecuteScalar())
    myConnection.Close()
    myConnection.Dispose()
    myCommand.Dispose()

Do this:

    Using myCommand As New SqlClient.SqlCommand("Select Count(*) from MyTable")
      Using myConnection As New SqlClient.SqlConnection(ConnectionString)
        myCommand.Connection = myConnection
        myConnection.Open()
        Dim iCount As Integer = CInt(myCommand.ExecuteScalar())
      End Using
    End Using

Since the IDisposable interface on the SQLConnection object will automatically close open connections, there is no need to close it… However, if you decide to do this:

    Using myCommand As New SqlClient.SqlCommand("Select Count(*) from MyTable" _
    , New SqlClient.SqlConnection(ConnectionString))
      myCommand.Connection.Open()
      Dim iCount As Integer = CInt(myCommand.ExecuteScalar())
      myCommand.Connection.Close()
    End Using

Make sure you close the connection first… Although, I don’t recommend doing it that way, because the IDisposable interface of the SQLCommand object does not call the IDisposable interface of the SqlConnection object that it holds. I’ve read that all the SqlConnection object’s IDisposable interface does is close an open connection, I wouldn’t trust that completely and dispose of it properly.

In my search of an answer of the question ‘Why?’ I already found 2 answers.
1. WPF uses DirectX to render the controls on screen. This pushes most of the UI processing onto the GPU (Video Card) instead of the CPU. This should speed up Windows applications a bit and also allow UI elements to be processing while business logic elements are running (think progress bars).
2. Using a WPF application in Remote Desktop will allow all visual elements to be processed using DirectX on the CLIENT PC. This means that if I connect to my machine at work from home, all WPF applications will be rendered using my video card instead of my work PC’s video card. How cool is that?! That will make using remote desktop faster as well. I have already experienced the Remote Desktop application slowdown because of screen redraws and control hang ups because of nasty UI elements. This would fix those problems.

I will continue to post new things as I find them. Little things like being able to write an XAML document and open it in IE without having to compile is a cool feature, but one I’m not interested in. So plan on only seeing REALLY cool features here.

The reason I ask why is because as I am looking at the available controls and what it looks like on screen once I run the test application, I am really presented with the same looking form as if I just used a regular Windows Forms control. This doesn’t mean that I think it’s useless already. Heck, I only spent about 20 minutes with it. I haven’t even read up on it as much as I should have before even posting this.

So, let it be known that my research into WPF has started with a resounding, “What is this supposed to accomplish?”

So what if you want to have a single installation program that will install all the prerequisites (.Net), then install SQL Server 2005 with your custom options (instance name for example), and then have it execute scripts and fill it with data? After working at it for hours, I came to the conclusion that you could be out of luck. Until I did some reconfiguring.

First things first, you need to get SQL Server Express to install properly. I struggled with this for a while, until I had the bright idea of using a bootstrapper… But can’t we use the one that comes with the Visual Studio Package and Deployment Wizard? Yes you can!

Go into your Visual Studio 8 folder and find the SDK/v2.0/Bootstrapper/Packages folder. Make a copy of the SqlExpress folder and name it something like, MyAppSqlExpress. Inside that folder, there is a product XML file. Edit that product.xml file and change the product code. Mine was Microsoft.Sql.Server.Express.1.0 and I changed it to MyAppName.Microsoft.Sql.Server.Express.1.0 … Just change the MyAppName to the app name of the product it goes with. You will also see a En folder for the English installation. The package.xml file is the one you want to edit in that folder. The first item to edit, is the arguments line. This passes arguments to the SqlExpr32.exe file (the setup for Sql Express). The arguments are the same as any other SQL Express install… So change it to be something like this:

Arguments='-q /norebootchk /qb reboot=ReallySuppress addlocal=all
  INSTANCENAME=MyApp SECURITYMODE=SQL SAPWD=MyStrongPassword
  DISABLENETWORKPROTOCOLS=0 SQLAUTOSTART=1'

This will do a silent installation of SQL Server Express using all protocols, a custom instance name (MyApp), turn on the SQL security mode and specify a strong SA password.

Next, there is the strings block at the bottom. Edit the StringName “DisplayName” to look like this:

MyApp SQL Server 2005 Express Edition

Save it, and go into your setup and deployment project you created, go to the project properties, then to the prerequisites, and in the list you should now see your custom install of SQL Server Express!

This does work, I just tested it out today.

So that solves problem #1. What about the problem of executing scripts? That seems to be the easy part… From my earlier post you can incorporate that code into a custom action.

Create a new project, and select Installer Class from the templates. This creates a new installer class for you to augment.

  Private Sub ExecuteSQL(ByVal SQL As String, _
    ByVal ConnectionString As String)

    Dim srv As New Server(New ServerConnection( _
    New SqlClient.SqlConnection(ConnectionString)))

    srv.ConnectionContext.ExecuteNonQuery(SQL)
    srv.ConnectionContext.Disconnect()
  End Sub

  Private Sub BulkLoad(ByVal ConnectionString As String, _
    ByVal TableName As String)

    Dim bulk As New SqlClient.SqlBulkCopy(ConnectionString, _
    SqlClient.SqlBulkCopyOptions.KeepIdentity)

    Dim ds As New DataSet
    Dim path As String = My.Application.Info.DirectoryPath
    ds.ReadXmlSchema(path & "\" & TableName & ".xsd")
    ds.ReadXml(path & "\" & TableName & ".xml")
    bulk.BulkCopyTimeout = 0
    bulk.DestinationTableName = TableName
    bulk.WriteToServer(ds.Tables(TableName))
    bulk.Close()
  End Sub

  Public Overrides Sub Install(ByVal stateSaver As _
    System.Collections.IDictionary)

    MyBase.Install(stateSaver)
    Dim ConnBuilder As New SqlClient.SqlConnectionStringBuilder()
    ConnBuilder.UserID = "sa"
    ConnBuilder.Password = "MyStrongPassword"
    ConnBuilder.DataSource = "localhost\MyApp"
    ConnBuilder.InitialCatalog = "master"
    ExecuteSQL(My.Resources.CreateDatabaseSQL, _
    ConnBuilder.ConnectionString())

    ConnBuilder.InitialCatalog = "MyDatabase"
    BulkLoad(ConnBuilder.ConnectionString(), "MyTable")
  End Sub

In this example, I just stored the data files (an XML data file and an XSD schema file) in the setup project, which gets installed along with the custom installer DLL. The create database SQL stuff was all saved as a store resource in the installer class project. I did this so that some of the structure was hidden, which may or may not be an issue for others.

Now, add the custom action to a setup project and you are finished!

COM is not dead, by any means. In fact, Microsoft said it themselves in the Windows Vista FAQ. It’s not dead, just done. By done, they mean that it will no longer be extended, or fixed if a problem is found. I am 100% sure that if a security flaw is found, they will fix it. However, I am also 100% sure that if an obscure bug is found, and it doesn’t affect any Microsoft Products, it will not be fixed.

So what does that mean for the Windows Developer? Not much. COM is still a major component in Windows, and probably will have to be for quite some time. Microsoft Office and Internet Explorer are still COM applications. Do you think they will be rewriting them in .Net any time soon? Probably not.

I don’t think the sky is falling, but I do think it’s time for existing developers to start migrating away from COM, though.