Archive for January, 2010

New Release Date of Visual Studio 2010

Tuesday, January 26th, 2010

Microsoft has rescheduled the launch date for Visual Studio 2010 and .Net Framework. The original launch date was scheduled for March 22nd.

The new release date is April 12th.

Until then, learn more about Visual Studio 2010 Beta 1.

Dynamics AX 2009 Workflow Setup

Wednesday, January 20th, 2010

Microsoft Dynamics AX 2009 WorkFlow can cause an error when setting up a workflow on Win2008R2.

If you receive this error when you run Workflow infrastructure configuration wizard:

The request failed with HTTP status 405: Method Not Allowed.

Then you should change the Application pool for your workflow (which is by default MicrosoftDynamicsAXWorkflow50) to enable 32 bit applications:

ContextSwitchDeadlock Exception in the Coded UI Tests

Thursday, January 14th, 2010

Coded UI test, a new type of test in Visual Studio 2010, can be created to navigate through an application’s User Interface (UI), which can be useful to verify that the functionalities users might perform through an application are working properly. As such, coded UI tests can bring the improvement of regression testing capabilities to the UI layer, especially for time consuming scenarios.

I have tried to create a coded UI test on such an application scenario, which performs an upload of a significant number of documents and because of that it takes a couple of minutes to be finished. In order to find a moment when the upload is completed, I created a loop in the code which verifies Enabled property of one of the UI objects every 2 seconds. The problem was that Visual Studio occasionally fired MDA ContextSwitchDeadlock exception:

ContextSwitchDeadlock was detected

Message: The CLR has been unable to transition from COM context 0x2e33a0 to COM context 0x2e35c8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

A Managed Debugging Assistant (MDA), ContextSwitchDeadlock, was created to monitor for deadlocks induced by cross-Apartment transitions. If a transition takes longer than 60 seconds to complete, the CLR assumes the receiving STA is deadlocked and fires this MDA. Processing messages during long operations can be paused or even failed due to many different factors such as CPU, available RAM, context switching, as well as other factors…

What is really positive with MDA is that the message isn’t a test stopper; there is no real loss in ignoring it. The MDA is fired because my loop runs for longer than 60 seconds. Essentially, it is a warning that a code is completely blocking the application.

The resolution can be:

  1. If you want to ignore the MDA, simply uncheck the ContextSwitchDeadlock exception (Debug> Exceptuions> Managed Debugging Assistants > ContextSwitchDeadlock, uncheck column Thrown). This can be considered as “I know that test/application is going to be busy for a significant amount of time and it will appear as not responding“. Unfortunately, this will open the possibility that a test or application is really hung.
  2. If a ContextSwitchDeadlock message is important for you for any reason, the problem can be resolved by pumping messages at the end of each pass through the loop:

while (PeekMessage(…))
{
    TranslateMessage(…);
    DispatchMessage(…);

}

This will clear the box of any unprocessed messages that arrive while a loop is running.

Dynamically Created Controls Identification in VS 2010

Monday, January 11th, 2010

While creating UI Coded test Visual Studio 2010 Beta 2, I have experienced an interesting situation on identifying dynamically created controls.

An application contains a form with three WPF combo boxes created dynamically with a blank Name property. In this case, UI Spy (and I assume Visual Studio 2010 Coded UI Test Recorder) should identify control with empty Name and AutomationID property, but recorder should generate NextTo or Instance properties.

  Identification

 

    ClassName:

ComboBox

    ControlType:

ControlType.ComboBox

    Culture:

(null)

    AutomationId:

 

    LocalizedControlType:

combo box

    Name:

 

Unfortunately, recorder didn’t record the instance property, so the result was only one combo box control in the UIMap.Designer.cs file.

public WpfComboBox ItemComboBox

        {

            get

            {

                if ((this.mItemComboBox == null))

                {

                    this.mItemComboBox = new WpfComboBox(this);

                    #region Search Criteria

                    this.mItemComboBox.SearchConfigurations.Add(SearchConfiguration.NextSibling);

                    #endregion

                }

                return this.mItemComboBox;

            }

        }

 

The resolution is to create two new instances of the controls with different search criteria:

public WpfComboBox ItemComboBox2

        {

            get

            {

                if ((this.mItemComboBox2 == null))

                {

                    this.mItemComboBox2 = new WpfComboBox(this);

 

                    #region Search Criteria

                    this.mItemComboBox2.SearchProperties["Instance"] = “2″;

                    this.mItemComboBox2.SearchConfigurations.Add(SearchConfiguration.NextSibling);

                    #endregion

                }

                return this.mItemComboBox2;

            }

        }

However, a suggestion is to assign a name to these controls because in that case, they have a much better search condition and will be resilient to position changes.

Dynamics AX 2009 EP Installation Problem

Tuesday, January 5th, 2010

I recently had a problem with the CEO role center, specifically the KPIs on that role center which were always loading. I have set up IE security as it was described in this MSDN article.

KPIs and Business Overview keep loading all the time and never end.

If the whole Role Center content in enterprise portal comes up except the Business Overview webpart and it keeps displaying the loading progress image for a long time with no error message in the event log, it may be because IE security setting prevents the webpart from asynchronously getting the data. To resolve this issue add the EP site to the intranet site zone in IE or disable IE Enhanced Security Configuration from Add / Remove programs -> Add / Remove Widnows Components. It still did not show the KPI web parts, but just kept loading it. I have used win2008R2.

The other problem I had with this Installation was that I was not able to modify any role center page. Whenever I would try to modify it I would receive an error message from SharePoint: Error occurred contact your administrator.

A strange thing was that when I tried to view the Role Center through Google’s Chrome browser, I could see the KPIs and modify the role center web parts. That was really frustrating.

In the event viewer I had a message:

An unexpected error has occurred.
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

Then I saw this other article on MSDN.

EP Site creation is successful and able to view most of the pages. But when trying to access lookup or sorting on grid (any postback to the page) it gives an unexpected error and in eventlog it has:

An unexpected error has occurred.
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

Check and make sure the Machine name or the host header does not contain any non alphanumeric characters such as “_”or “-“ etc. The machine name should just contain only alphanumeric characters.
For example mey1 is a valid machine name. mey_1 is not. If you have any other character in the machine name, then validation of viewstact MAC fails. So to resolve this issue, check and make sure the machine name contains only alphanumeric characters and EnableViewStateMac is set to true in the web.config and in case of load balancing, the same machine key is used in the web.config of all participating web server machines.

And see that I have the character _ in my computer name.

When I changed the name of my computer so I have only alphanumeric characters, I was able to see the KPIs from IE and I was also able to modify my role center pages with IE.

My opinion is that this step should be included on the AX Installation guide and put it on first place there, because it is very hard to change the name of computer when you install all of EP in AX 2009.