If you have been working with TFS database project, you may have generated data by using the data compare tool. Then in theory, if you put the script generated by data compare feature into Post-Deployment script. Usually this would work, but once awhile, when you include a data script, you get the following error: SQL01260:A fatal error occurred.

There are a few reason this would happen, for example you have violated db integrity with incorrect forgein keys. But these problems are easy to figure out and fix. However, if you get this error no matter what you do, and you could run the data script in SSMS without failture, then you encountered a TFS bug.

First let me describe the data script. I generated a data script with this in one of the columns -- :$(''''document'''').ready(function() -- I get this script becuase my database keeps some javascript. Now, I can run the script in SSMS, but if I include this script in Script.PostDeployment.sql, TFS database project would not even build.

To solve this problem, I logged a ticket with Microsot support, and looked around internet. There was no way to resolve this. So a Microsoft engineer and I came up with an workaround: replace all $( with "$"(, this will allow you to compile TFS database project and deploy it. After you deploy, you need to do a search and replace to put all "$"( back to $(.

TFS SQL parser is not the same as SQL parser, so it thinks $( as a varaiable replacement, that's why it can't parse this $(document) thing. Of course, you may not have $(, but have other unrecognizable format. One way to figure this out is to run SQLCMD mode, then you can see it fail on the exact line, then apply the fix I moved above.

Finally, if your goal is to use TFS to deploy data, and don't need to have a local deployment working, you could wire up a build process with this data folder, then do a sqlcmd -x deployment. sqlcmd -x will ignore all variable replacement, and hence ignore $(.

Now that you have done so, you will see the command promopt showing up with a title "Administrator: Command Prompt", and it will automatically land you in C:\Windows\System32. Then register the dll, the problem should be resolved.

As a TFS administrator, my first thought is that the system is offline. So I logged on to the TFS server and found that the system is still running, but when I go to IIS and try to run the Web, it doesn't work either.

After much digging, I found out that the application pool for TFS stopped working because I changed the password for the TFSSERVICE account through Server Manager, but didn't change it in the application pool.

Here's how to fix it:

Please note, I'm using IIS7.

1. Open IIS (type InetMgr).

2. Left click on the tfs site that stopped working (for me, the tfs site is called TFS1Server)

3. Select the "Adavnced Settings..." on the "Actions" panel. From this Advanced Settings panel, you can see which Application Pool your TFS website is using. For me, I used the default application pool called "Microsoft Team Foundation Server Application Pool"

4. Now select "Application Pools" in the "Connections" panel. You will see the "Microsoft Team Foundation Server Application Pool" showing up in the Application Pools panel.

5. Select "Microsoft Team Foundation Server Application Pool" and select "Advanced Settings..."

6. In the "Advanced Settings" popup window, locate the "Identity" line, then click on the "..."button.

7. When it pops up, choose Custom Account, select "Set..."

8. In the "Set Credentials" popup screen, set user name and password, such as "TFS1\TFSSERVICE", etc.

9. If you also configured the Web Access Application Pool, then you should set the password for this pool as well.

Restart IIS, you are done.

In the Launch Conditions, right click the .NET Framework, select Properties Window.

In the Properties Window, you can select the Framework version as you want.

The question is the WinForm need to run in .Net Framework2.0 because some of the customer machines only supported Framework2.0.
But as you know, the WPF is only supported in .Net Framework3.5. So I can't directly call the WPF code in the WinForm.

The best way to do that is to dynamically load the WPF dll.

The process is:

Build the WPF program to a WPF.dll

Dynamically Load the WPF.dll in WinFrom code

For example, if the button1 in Winform is clicked, we add the dllinvoke method in the button event method.

WinForm.cs

        private void button1_Click(object sender, EventArgs e)
        {
            object[] objParam = new object[1];
            objParam[0] = ordInfo;
            DllInvoke("WPF.dll", "WPF", "WPFProgram", "showWPF", objParam);

        }

       private static object DllInvoke(string DllFileName, string NameSpace, string ClassName, string MethodName, object[] ObjArrayParams)
        {
            try
            {

                Assembly DllAssembly = Assembly.LoadFrom(DllFileName);
                Type[] DllTypes = DllAssembly.GetTypes();
                foreach (Type DllType in DllTypes)
                {

                    if (DllType.Namespace == NameSpace && DllType.Name == ClassName)
                    {

                        MethodInfo MyMethod = DllType.GetMethod(MethodName);
                        if (MyMethod != null)
                        {
                            if (mObject == null)
                                mObject = Activator.CreateInstance(DllType);
                            return MyMethod.Invoke(mObject, ObjArrayParams);
                        }
                    }
                }
            }
            catch (Exception mEx)
            {

            }
            return (object)0;
        }

If you write the code like this, when you run the application and click the button1, you will get an error:

"System.InvalidOperationException: The calling thread must be STA, because many UI components require this"

So there are some remote ways to use:

TCP communication

Tcp communication is based on socket communication, but it takes care of all the handshaking and data process for the user. It takes in a stream as input and output a stream as well.

.Net remoting

.Net remoting is similar to web services but it does not have the over head of web service.

Both TCP and .Net remoting are used to pass information between computers accorss network.

Finally we choose to use TCP to handle the work.

The process is:

In the Interop.cs we add a new method named notifyTCPServer, in the method we create a TCPSender

and put the message to the TCPSender.

In the TCPSender.cs, it will create a socket to communicate with the remote WinForm machine.

In the remote WinForm machine, we create a TCPReceiver.cs to listen the connection and if the connection is created, it can receive message from the TCPServer. After receive the message, it

will send WinMsg to WinForm similar with privious section

The Interop.cs

        public void notifyTCPServer()
        {
            StringBuilder sbMsg = new StringBuilder();
            if (this.GenInfo != null)
            {
                for (int i = 0; i < GenInfo.Length; i++)
                {

                    if (i == (GenInfo.Length - 1))
                        sbMsg.Append(GenInfo[i]);
                    else
                        sbMsg.Append(GenInfo[i] + "|");
                }
                _logger.WriteEntry("GenInfo:" + sbMsg);
            }
            else
            {
                sbMsg.Append(Flag.ToString());
            }

            //send msg through TCP server

            TCPSender tcpSender = new TCPSender();
            tcpSender.sendMsg(sbMsg.ToString());
        }

The TCPSener.cs
    public class TCPSender
    {

       public int port = 9050;       
        public void sendMsg(String msg)
        {

            //the Remote machine IP

            string ip= "192.168.1.100";
            sendToClient(ip, msg);
         }

        private void sendToClient(string ip, string msg)
        {

            TcpClient client = null;
            NetworkStream strm = null;
            try
            {
                client = new TcpClient();
                IPAddress address = IPAddress.Parse(ip);
                IAsyncResult MyResult = client.BeginConnect(ip, port, null, null);
                MyResult.AsyncWaitHandle.WaitOne(5000, true);   //set time out   
                if (!MyResult.IsCompleted)
                {
                    client.Close();
                }
                else
                {

                    // the formatter that will serialize my object on my stream 
                    IFormatter formatter = new BinaryFormatter();                    

                    strm = client.GetStream(); // the stream 
                    formatter.Serialize(strm, msg); // the serialization process 
                }

            }
            catch (Exception e)
            {
            }
            finally
            {
                if (strm != null)
                {
                    strm.Close();
                }
                if (client != null)
                {
                    client.Close();
                }
            }
        }

    }

The Remothe TCPReceiver.cs

    public class TCPReceiver
    {

        public static string IP = "";
        public int listenPort = 9050;
        public void listen()
        {
            TcpListener listener = new TcpListener(listenPort);
            listener.Start();
            while (true)
            {
                TcpClient client = listener.AcceptTcpClient();
                IPEndPoint ip = (IPEndPoint)client.Client.RemoteEndPoint;

                IP = ip.Address.ToString();//get the IP from client
               

                NetworkStream strm = client.GetStream();
                IFormatter formatter = new BinaryFormatter();

                String msg = (String)formatter.Deserialize(strm);

                
                Interop interop = new Interop ();

               
                interop.notifyCSharpFormByTCP(msg);

                strm.Close();
                client.Close();
            }
        }

    }

Now we have a COM interop in VB6, VB6 can put the GenInfo and Flag to the C# class. But how can

I notify our WinForm application to get these values?

I decide to to use WinMsg to communicate between the Interop.cs and WinForm.cs, because they are all written in C#. It's an easily way to implement if the VB6 and WinForm located in one machine. But if they are not located in one machine, we must use another way I will mention in next section.

The process is:

Firstly, in the sender side, we use FindWindow to find the WinForm Handler, then send the WM_COPYDATA message to the receiver use the method SendMessage.

The methods FindWindow and SendMessage are Windows API in User32.dll.

Then the receiver side(WinFrom) will get the message in the method DefWndProc.

We can use the overriding method DefWndProc of WinForm to handle customer defined message.

In both sender and receiver we use the same struct COPYDATASTRUCT to deliver the message.

Sender: the Interop.cs

        const int WM_COPYDATA = 0x004A;

        private string CSHARP_WINDOWTITLE_SERVER = "C#-WinForm";

        public void notifyCSharpForm()
        {

            StringBuilder sbMsg = new StringBuilder();

            if (this.GenInfo != null)
            {
                for (int i = 0; i < GenInfo.Length; i++)
                {

                    if (i == (GenInfo.Length - 1))
                        sbMsg.Append(GenInfo[i]);
                    else
                        sbMsg.Append(GenInfo[i] + "|");
                }
            }
            else
            {
                sbMsg.Append(Flag.ToString());
            }

            //Notify the WinForm to get the GenInfo and Flag

            int WINDOW_HANDLER = FindWindow(null, CSHARP_WINDOWTITLE_SERVER);
            if (WINDOW_HANDLER != 0)
            {
                COPYDATASTRUCT cds = new COPYDATASTRUCT();

                cds.dwData = (IntPtr)100;
                cds.lpData = sbMsg.ToString();
                cds.cbData = sbMsg.Length + 1;
                SendMessage(WINDOW_HANDLER, WM_COPYDATA, 0, ref cds);
            }

        }

        public struct COPYDATASTRUCT
        {
            public IntPtr dwData;
            public int cbData;
            [MarshalAs(UnmanagedType.LPStr)]
            public string lpData;
        }

        [DllImport("User32.dll", EntryPoint = "SendMessage")]
        private static extern int SendMessage(
        int hWnd, // handle to destination window
        int Msg, // message
        int wParam, // first message parameter
        ref COPYDATASTRUCT lParam // second message parameter
        );

        [DllImport("User32.dll", EntryPoint = "FindWindow")]
        private static extern int FindWindow(string lpClassName, string
        lpWindowName);

Receiver: WinForm.cs

        private string CSHARP_WINDOWTITLE_SERVER = "C#-WinForm";

        public frmMain()
        {

            ......

            this.Text = CSHARP_WINDOWTITLE_SERVER;

        }

        protected override void DefWndProc(ref System.Windows.Forms.Message m)
        {
            switch (m.Msg)
            {
                case WM_COPYDATA:
                    COPYDATASTRUCT mystr = new COPYDATASTRUCT();
                    Type mytype = mystr.GetType();
                    mystr = (COPYDATASTRUCT)m.GetLParam(mytype);
                    String msg = mystr.lpData;
                    String[] msgArr = msg.Split('|');
                    GenInfo = msgArr;

                    //Do something to display the GenInfo
                break;
                default:
                    base.DefWndProc(ref m);
                    break;
            }
        }

        public struct COPYDATASTRUCT
        {
            public IntPtr dwData;
            public int cbData;
            [MarshalAs(UnmanagedType.LPStr)]
            public string lpData;
        }

Continue from the last blog. The five things we need to achieve are:

Due to the technical requirement and the business needs, we have decided to implement the following:

1.       Created an interop to facilitate communicate between VB6 and Bumble Bee

2.       Use WinMsg to communicate between interop and Winform for .net2.0 – this is to ensure that if Bumble Bee exists on the same machien as the VB6 program, the two programs will be the minimum lag.

3.       Interop call C# WinForm by TCP Server – if the Bumble Bee program does not co-locate on the VB6 program’s machine, we need to use TCP Server/Listener technology to do it.

4.       Winform dynamically load WPF – most of the funcationlity will be implemented on the Winform which runs on the required .net2.0. For the 3.5 funcationlity that requires WPF, we will simply call WPF through Winform when we can dynamically determine if .net 3.5 exists or not on the particular machine.

5.       To ensure step 4, we have to make sure tha the project can install dynamically on 2.0 or 3.5.

Today, let’s talk about 1:

As you know, we can expose the .NET Framework components to COM. Then the VB6 code could consume it as usual.

Perform the following steps:

Create a .Net class libray project just like normally.

Open the properties of the project and click the Build tab. Make sure the Register For COM Interop option selected.

Create a .Net Class：

using System;
using System.Collections.Generic;

using System.Text;
using System.Runtime.InteropServices;

namespace InteropLib
{
    public interface IInterop
    {
        string[] GenInfo { get; set; }
        int Flag { get; set; }

        void notifyCSharpForm();
    }

    [GuidAttribute("D5E4C17E-3C1C-4519-AC39-F7749CE81AAB")]
    public class Interop : IInterop
    {

        private string[] _GenInfo = null;
        private int _flag = 0;

        public string[] GenInfo
        {
            get
            { return _GenInfo;}
            set
            {_GenInfo = value;}
        }

        public int Flag
        {
            get
            {return _flag;}
            set
            {_flag = value;}
        }

        public void notifyCSharpForm()
        {

             //Notify the WinForm to get the GenInfo and Flag

             .....

        }

    }       

}

If you compile the application with the code just shown and there are no errors, the assembly will be visible to COM.

Consume it in VB6

Dim ocdInterop As InteropLib.Interop

Private Sub cmdFinish_Click()

    Set interop = New InteropLib.Interop 
    interop .Flag = -1

Some Tips:

Tip 1. After compiling your assembly to a DLL, you can register it for COM Interop from the command line:

       regasm c:\path\MyDll.dll /tlb:MyDll.tlb

Tip 2. Add GuidAtrribute for the assembly, then it will keep a unique reference for VB6.
If the application is recompiled, no need to recomiple the VB6 code again. Because the GUIDs is always same for VB6.
      

       [GuidAttribute("D5E4C17E-3C1C-4519-AC39-F7749CE81AAB")] 

In a recent project, we have encountered a very complex business needs that presented a number of obstacles to our developers. Through much trial and error through, we overcame the obstacles one by one, and finally triumphed the “evil” and in the process learnt a lot of nuances of vb6 + .net.

Before I start to go into the technical details, I’ll first talk briefly the business needs the project tried to answer. Although due to confidentiality, I have to greatly simply the details, I hope my explaination will capture the big picture.

A client has an old VB6 code that does roughly 3 things:

    1. Take a series of user input through a complex UI

     2. Call database, do some business logic processing

     3. Output the result in both text and video (windows media and flash) format to a number of screens, which may or may not be attached to the computer the VB6 program is running on.

Our job is to create a program - let’s called “Bumble Bee” because how busy it is - will run on all the screens connected to the VB6 code. “Bumble Bee” will read in the input the VB6 provides and display text and play the right videos. Sounds simple enough? So we thought. There are some requirements about this program.

A. It has to be light weight, very light. Because the screens that run this program has very little processing power.

B. It has to be very responsive. Think of first person shooter type of responsiveness. As soon as a user enters something on the VB6, “Bumble Bee” needs to act and display. If a user continuously hits the UI input on the VB6 code, Bumble Bee needs to get real busy and flash through tons of messages and decide what video to play.

C. Bumble Bee exists in both .net 2.0 and .net 3.5 world due to legacy reasons. On .net 2.0, the client wants a winform to display text and videos. On .net3.5, they want a WPF so that it can deal with screen rotation, but as we know, WPF cannot be run on .net2.0. So suddenly, Bumble Bee needs to have two different versions, is this acceptable?

Due to the technical requirement and the business needs, we have decided to implement the following:

     1. Created an interop to facilitate communicate between VB6 and Bumble Bee

     2. Use WinMsg to communicate between interop and Winform for .net2.0 – this is to ensure that if Bumble Bee exists on the same machien as the VB6 program, the two programs will be the minimum lag.

     3. Interop call C# WinForm by TCP Server – if the Bumble Bee program does not co-locate on the VB6 program’s machine, we need to use TCP Server/Listener technology to do it.

     4. Winform dynamically load WPF – most of the funcationlity will be implemented on the Winform which runs on the required .net2.0. For the 3.5 funcationlity that requires WPF, we will simply call WPF through Winform when we can dynamically determine if .net 3.5 exists or not on the particular machine.

     5. To ensure step 4, we have to make sure tha the project can install dynamically on 2.0 or 3.5.

This is the summary of what what we decided to do. In the following days, I’ll continue the blog and fill the details of the trial and error we had to walk through to get the project completed. Stay tuned…