Dot Net Tips and Tricks

After installing the V1.2 upgrade, I’ve found that any solution with Windows Workflow used will not open and will crash Visual Studio 2005. I’ve submitted a request to their site and will post back more when I have it.

05/09/2007 –>A bug fix release has been release: V1.2.1 that now works with Windows Workflow projects.

When adding ExternalDataExchange services to the runtime it needs to be noted that theses methods are all NOT threadsafe. The runtime will allow you to add multiple instances of the same exchange service to the runtime, but when you call the GetService<T>() method on the runtime, an exception will be thrown. The following will protect you against these problems.

private static object _lockObject = new object();

T service;
lock (_lockObject)
{
service = (T) defaultService.GetService(typeof (T));
if (service == null)
{
service = (T) TypeLoader.Load(typeof (T).AssemblyQualifiedName);
if (service == null)
{
throw new ArgumentException(EXCHANGE_MANAGER_NOT_LOADED);
}
defaultService.AddService(service);
}
}

Here’s a little gotcha that Microsoft put in Windows Workflow Foundation.

The CallExternalMethod activity is defined as

Defines a workflow communication activity that is used to call a method on a local service. This activity is used to send data from the workflow to the host through the local service.

You select the interface of the service where the method exists and then select the method name. The designer automatically creates properties that correspond to the parameters of the method to call. You can then double-click the little blue “Bind Property” tag in the property window. This allows you to bind the property to any member in the workflow of the same type. This all seems great, until you use it at runtime. What Microsoft fails to state is if the object you bind to impliments IClonable, at execution time, the object will be Cloned then passed to the service’s method. Noware else can I find where an object is Cloned prior to being passed.

I’m still struggling to find the reason for this one, but it’s a gotcha for sure since the documentation states nothing about it.

After fighting with the windows workflow (WWF) runtime for a few hours, I finally found and article in the WIKI that showed the tracing switches changed in the released version.

The following will log everything to a file on the computer where the runtime is located:

<system.diagnostics>
<switches>
<add name=”System.Workflow LogToTraceListeners” value=”1″ />
<add name=”System.Workflow.Runtime.Hosting” value=”Verbose” />
<add name=”System.Workflow.Runtime” value=”Verbose” />
<add name=”System.Workflow.Runtime.Tracking” value=”Verbose” />
<add name=”System.Workflow.Activities” value=”Verbose” />
<add name=”System.Workflow.Activities.Rules” value=”Verbose” />
</switches>
<trace autoflush=”true” indentsize=”4″>
<listeners>
<add name=”myListener”
type=”System.Diagnostics.TextWriterTraceListener”
initializeData=”D:\Remoting\TextWriterOutput.log” />
</listeners>
</trace>
</system.diagnostics>

And contrary to most of the postings on the internet, this is current for the RTM release of Windows Workflow Foundation.

Having recently spent several hours trying to configure DTC to communicate between my Windows XP workstation and a Windows 2003 Server, I recommend the following article for success. There are some security changes that occur in SP2 for Windows XP that require configuration before the two boxes will sucessfully talk.

My earlier article on the use of DTCPing for testing in the trackback will get you up to speed with this utility.
Set the appropriate values for the EnableAuthEpResolution and RestrictRemoteClients options on Windows XP SP2

Windows XP SP2 enhances security by requiring authenticated calls to the RPC interface. This functionality is configurable through the EnableAuthEpResolution and RestrictRemoteClients registry keys. To ensure that remote computers are able to access the RPC interface on a Windows XP SP2 computer, follow these steps:

Warning
Incorrect use of Registry Editor may cause problems requiring you to reinstall your operating system. Use Registry Editor at your own risk. For more information about how to back up, restore, and modify the registry, see the Microsoft Knowledge Base article “Description of the Microsoft Windows registry” at Description of the Microsoft Windows registry.

1. Click Start, click Run, type regedit.exe, and then click OK to start Registry Editor.
   Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT
2. Under the RPC key, create the following DWORD entries with the indicated values. If the RPC key does not exist then it must be created.
   

   DWORD entry	Default value	Recommended value
   EnableAuthEpResolution	0 (disabled)	1
   RestrictRemoteClients	1 (enabled)	0

3. Close Registry Editor.

For more information about the RPC Interface Restriction functionality in Windows XP SP2, see the RPC Interface Restriction section of Changes to Functionality in Microsoft Windows XP Service Pack 2.

Link to the article: DTC Troubleshooting

Yeah!!!! it’s finally RTM.. I’ve worked with Windows Workflow Foundation throughout the beta program and I find it to a real accet to the several projects I’ve used the foundation in. The tracking store and monitor support for runtime applications is wonderful for showing the progress of business transactions to end users.

Do yourself a favor and try the new .Net Framework out. HERE

Having spent some time working with WF ’s SqlTrackingService and SqlWorkflowPersistenceService to work with Sql Server 2005 on a seperate machine, I’ve put together a few links to help others.

NOTE: Certain transactions in Windows Workflow Foundation are promoted to DTC transaction when the stores are located on different machines.

• I found that the most helpful tool was DTCPing.
• A very easy program that can be used to test firewall issues and the simple connection between 2 computers over DTC.
• The second and more comprehensive was DTCTester.
• This will simulate a full sql transaction between computers.