Office Automation Problem in Task Scheduler

This blog is created based on my colleague experience.

He created an application to automate Excel process to read and write an Excel file. The application was able to run the process successfully if it was run manually. But, the application was failed to run if it was run from Task Scheduler. Even though he forced the application to run from the Task Scheduler, the application was still unable to run.

He found the solution from a thread in Microsoft forum. The solution is:

In Windows 2008 Server x64

Please make this folder.

C:\Windows\SysWOW64\config\systemprofile\Desktop

In Windows 2008 Server x86

Please make this folder.

C:\Windows\System32\config\systemprofile\Desktop

This operation took away office automation problems in my system.

A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.

This solution is a bit ridiculous, but may be the purpose of this folder is for a dummy or temporary folder of the Excel automation process. Somehow this solution solve the automation problem.

Cheers.

References:

• Excel 2007 automation on top of a Windows Server 2008 x64
• Error ‘Microsoft Office Excel cannot access the file’ while accessing Microsoft Office 11.0 Object Library from SSIS

Preventing Multiple Instances of An Application

Have you experienced a user that run an EDI application two times in one computer, which cause the data that being transferred became haywire? I have.

One way to solve this problem is by preventing the second instance of the application to run.

In Visual Basic 6 we can use the code below:

    Dim rc As Long

    If App.PrevInstance Then
        rc = MsgBox("Application is already running", vbCritical, App.Title)
        Exit Sub
    Else
        frmMain.Show
    End If

In Visual Basic .NET (2005) we can use the code below:

    Dim oMutex As System.Threading.Mutex
    oMutex = New System.Threading.Mutex(False, "ca91daff-26a3-49cd-97e0-4d57b50c9d3b")
    If (oMutex.WaitOne(0, False) = False) Then
        MessageBox.Show("The Accpac Interface is already running")
        Exit Sub
    End If

The “ca91daff-26a3-49cd-97e0-4d57b50c9d3b” is the application GUID. You can find it in the Project Properties -> Assembly Information

Another way of doing it is by using “Make single instance application” option in the Project Properties, I have never used this method though.

One more way to prevent multiple instance is by checking all of active processes, see the code below:

    Dim instanceCount As Integer = Process.GetProcessesByName("explorer").Count()
    Console.WriteLine(String.Format("{0} Instances Running", instanceCount.ToString()))
    Console.ReadLine()

References:

• http://stackoverflow.com/questions/3468616/prevent-opening-multiple-instance-of-vb-application
• http://stackoverflow.com/questions/93989/prevent-multiple-instances-of-a-given-app-in-net

Instance Cloning

Sometimes I got confused myself how to copy an instance to another identical instance.  I found an interface called “ICloneable Interface”. When in use this interface will create a new method called “Clone”. In this method I need to write code to create a new instance and then copy the content of every property into the new instance. The process of cloning gave me another question mark, why should I use “ICloneable Interface” while I could copy the instance without using the interface. Could I remove the “ICloneable Interface”?

Luckily I found this thread in one of StackOverflow’s forum. Matt Hamilton, that referred Brad Adam’s article, suggested that we should not use “ICloneable Interface” anymore, because it only done a shallow-copy.  He recommended that we should create our own “Clone” method to do the cloning.

References:

• http://stackoverflow.com/questions/699210/why-should-i-implement-icloneable-in-c
• http://blogs.msdn.com/b/brada/archive/2003/04/09/49935.aspx