K2 BlackPearl Gesturing on VS Design Canvas

In the K2 BlackPearl Designer for Visual Studio you can use mouse “gestures” to populate the design canvas, instead of dragging/dropping elements from the toolbox.  For example, you can draw an “S”, and have it get converted into a new Default Server Event on the process canvas.

 

A more useful application of the gesturing technique is adding a Line between activities by simply drawing the line from one activity to another.

 

To use this technique, you first right-click the canvas.  The mouse turns into a ink pen like pointer.  You then draw with the mouse (or pen on a Tablet PC) and release the right-click when done.  The drawn letter will convert into one of the elements from the toolbox, or execute a wizard corresponding to one of the elements.   I couldn’t find this gesturing approach documented anywhere, and after playing with it for a little while I discovered the following gestures and corresponding toolbox element:

A,H,W - Default Server Event (Workflow)
C - Default Client Event
D,F,P - InfoPath Integration Process
M - Mail Event
O - Default Activity
S - Default Server Event (Code)

I found this whole gesturing approach much easier to use on a Tablet PC with a pen vs. trying to draw with a mouse - especially anything with curves.  The gesturing is pretty picky about how you draw the letters.  In fact I’m not sure D, F, and P are all really letters intended for the InfoPath Integration Process.  I may have just happened to draw them all similar to a “P”.  It seemed to follow more of a Graffiti convention to scribing letters than a handwritten one.  There were times when I tried to draw an “M” in a handwriting style where it would run the InfoPath Integration Process wizard instead of creating a Mail Event.

I’m not sure how much I’ll remember the gestures and make use of this when authoring K2 processes, except for when drawing lines between activities.  I do think this is a fascinating UI approach, and can achieve some great efficiencies given the right scenario.  I’d love to see other Visual Studio designers make use of this (e.g., draw buttons on a Windows Form design canvas with a “b”).

SSRS Report Deployment Connection Error

A co-worker received the following error message when attempting to deploy a report from Visual Studio to a Sharepoint document library setup for Integrated Mode with SSRS.

“A connection could not be made to the report server…”

The message was followed by some additional information that indicated “Client found response content type of ‘text/html; charset=utf-8′, but expected ‘text/xml’.” as well as some additional HTML tags.  The error dialog was rather ugly.  Other developers working on the same solution with other reports were not having this problem.

The gist of the problem was that the developer’s PC did not have SQL Server 2005 Service Pack 2 installed.  Once the Service Pack was installed the error went away and the report could be deployed.

Format XML in Visual Studio

Here’s an easy tip for formatting XML in Visual Studio which apparently isn’t very well known.  There are times I find myself using Visual Studio to view/edit an XML file, and the source XML is tightened with no line breaks (for whatever reason) after the nodes.  Below is one example.

<?xml version=”1.0″?>
<BrowserInfo><Browser><Name>Microsoft Internet Explorer</Name><Path>“C:\Program Files\Internet Explorer\iexplore.exe”</Path><Resolution>0</Resolution><IsDefault>True</IsDefault><DDE><Service>IExplore</Service><TopicOpenURL>WWW_OpenURL</TopicOpenURL><ItemOpenURL>“%s”,,0xffffffff,3,,,,</ItemOpenURL><TopicActivate>WWW_Activate</TopicActivate><ItemActivate>0xffffffff,0</ItemActivate></DDE></Browser><InternalBrowser><Resolution>0</Resolution><IsDefault>False</IsDefault></InternalBrowser></BrowserInfo>
     

You can use the Format Document (Ctrl+E, D) command from the Edit->Advanced menu to nicely format your XML document:

This results in a much nicer formatting of the hierarchical information:

<?xml version=”1.0″?>
<BrowserInfo>
  <Browser>
    <Name>Microsoft Internet Explorer</Name>
    <Path>“C:\Program Files\Internet Explorer\iexplore.exe”</Path>
    <Resolution>0</Resolution>
    <IsDefault>True</IsDefault>
    <DDE>
      <Service>IExplore</Service>
      <TopicOpenURL>WWW_OpenURL</TopicOpenURL>
      <ItemOpenURL>“%s”,,0xffffffff,3,,,,</ItemOpenURL>
      <TopicActivate>WWW_Activate</TopicActivate>
      <ItemActivate>0xffffffff,0</ItemActivate>
    </DDE>
  </Browser>
  <InternalBrowser>
    <Resolution>0</Resolution>
    <IsDefault>False</IsDefault>
  </InternalBrowser>
</BrowserInfo>

Deploying Custom SSIS Connection Manager

When deploying a custom SSIS Connection Manager component you need to ensure the DLL assembly is deployed into the GAC (C:\Windows\Assembly) as well as the \DTS\Connections folder.  This is true even when deploying to a non-developer PC, such as a test server or production server.

The documentation found in the SQL Server Books Online seems to indicate you need to copy the DLL to the \DTS\Connections folder so that the BIDS designer can locate the custom components to use when authoring a package.  This is true, but a little misleading.  In my experience the assembly needs to be copied to the \DTS\Connections folder even on servers where the packages will just be executing.  The documentation does provide some help on how to find the specific path the assembly needs to be copied to, including the registry key which contains the full path to the \DTS folder.

Note, I did not find this to be the case for custom SSIS Data Flow components.  Placing the DLL in the \DTS\PipelineComponents folder was only necessary on the developer PC when designing the package.  Just copying it to the GAC was sufficient for servers which execute the packages using the custom data flow components.

Build SSIS Custom Components on TeamBuild

For our SSIS custom components (custom connection managers, custom data sources, custom data transformations, etc.) we have them deployed into the GAC and copied into the appropriate \DTS folder so that they become available in the design tools to be dropped on a design canvas.  This is accomplished via the Build Events in Visual Studio:

We also use TFS and TeamBuild for daily builds.  We run unit tests on our database stored procs and functions, and on our custom business assemblies.  No unit testing on SSIS components yet, but I am interested in what’s happening in this space.  The problem we ran into with TeamBuilds on the SSIS custom components is that we didn’t want/need the build events to occur.  In fact our TeamBuilds failed because the paths couldn’t be resolved.

To resolve this I opened up the project files and modified the PreBuildEvent and PostBuildEvent tags to include a condition checking if the build was occurring within Visual Studio or not.  The tags look like this now:

<PropertyGroup>
  <PreBuildEvent Condition=”‘$(BuildingInsideVisualStudio)’==’true’”>“$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe” /f /u “$(TargetPath)”
del “C:\Program Files\Microsoft SQL Server\90\DTS\PipelineComponents\$(TargetFileName)”</PreBuildEvent>
  <PostBuildEvent Condition=”‘$(BuildingInsideVisualStudio)’==’true’”>“$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe” /if “$(TargetPath)”
xcopy “$(TargetPath)” “C:\Program Files\Microsoft SQL Server\90\DTS\PipelineComponents”</PostBuildEvent>
</PropertyGroup>

Visual Studio Object Test Bench

The Object Test Bench is a pretty cool feature of Visual Studio that I always seem to forget about.  It allows you to test code in classes you develop within Visual Studio without having to actually run an executable.  It’s a quick way to run an informal test on some code.

So, if you have a class named Foo, you can create an instance of this class from the Class View by right-clicking the class name and selecting the Create Instance menu item and then selecting Foo() from the submenu.  If you had multiple constructors, you could have selected the one of interest from the submenu.

A dialog will display, allowing you to provide a name for the instance being created.  If your constructor had arguments then you would specify values here as well.

The Object Test Bench view then appears with a shape representing the instantiated Foo object.  You can right-click this shape and select the menu option for Invoke Method, and select a method from the list (such as Bar).

Again, a dialog will display, allowing you to provide the values you want to send to the method invocation.  The Bar method takes two integer arguments, and returns the summation as an integer.

After providing some values (e.g.,5 and 6), and clicking OK, another dialog appears with the result.  This dialog also provides an option to persist the returned value back into the Object Test Workbench.  This allows you to use this object/value for subsequent method invocation, or serve as input into another method.

The Object Test Workbench is certainly not perfect.  For one thing, it does not support generics.  You may notice in the Foo example above there is an overloaded Bar method with nullable int arguments.  This overloaded method doesn’t even appear in the method invocation submenu, due to the generics.  This is true even with Visual Studio 2008.

The Object Test Workbench certainly is not intended to replace a more rigorous unit testing approach, such as that provided with the Team System functionality.  However it is a nice lightweight way to quickly test some code.

Windows XP Search For Words In .cs Files

One thing that has always drove me nuts with Windows XP is the default behavior of the “search for a word or phrase inside a file” options with Windows Search.  Out-of-the-box it won’t search files like C# code files (*.cs).  Even if you explicitly specify them in the search dialog.

Apparently this is for “performance reasons.”  There is a finite list of file types that Windows XP Search will truly search.  A bit more work is involved to get the search to peer into cs, csproj, sln, etc. files.

A while back I discovered that you could manually get these additional file extensions added to the list of file types that Search would search, by making some modifications in the registry.  You could add a PersistentHandler key to the file extension entry in HKCR, and set the Default string value to a GUID that represented the plain text file filter.

Today I learned there is another way (much easier) to allow all file types to be searched.  It involves setting the “Index files with unknown extensions” option as part of the Windows Search Indexing Service.  You don’t actually need to turn on the indexing service, but you get to the property through the indexing service dialogs.  Complete step-by-step instructions can be found in Microsoft Knowledgebase Q309173.

Delete InfoPath Form from Script Code

A pattern I’ve seen appear multiple times with InfoPath solutions is around having two document libraries store the forms.  One typically serves as a drafting area, and the other serves as an approved or archived area.  This is typically done when security requirements dictate having two separate access lists for each library.  At some point during the life of the form it needs to move from one library to another.  The key here is move.  You don’t want to find it in both places.  It’s pretty simple to set up two data connections for submitting an InfoPath form, and have rules or code dictate which connection to use for submittal.  However, there’s no out-of-the-box functions for removing the InfoPath form from a library it was previously saved to.

One solution to this problem is to use the Scripting.FileSystemObject.  This class has a DeleteFile method and can use a UNC path to the file in a Sharepoint library/folder to delete the file.  However, the FileSystemObject class comes from an ActiveX component which is not marked as ’safe for scripting’.  Best practices for InfoPath development indicate you should avoid referencing these types of components.  InfoPath relies on Internet Explorer security settings as part of its security model.  By default all zones (Internet, Intranet, local) except for Trusted Sites do not allow execution of unsafe ActiveX components.

An alternate solution is to use the XMLHTTP class.  This class comes from a component which is marked as safe, and uses HTTP to perform the delete operation (which is typically faster than the file system approach with FileSystemObject).  Below is a snippet of JScript code which demonstrates how to use this within InfoPath:

try
{
    // Get full URL of the current form
    var docUrl = XDocument.URI;
   
    // Create an xmlhttp object.
    var xmlHttp = new ActiveXObject(”MSXML2.XMLHTTP”);

    // Delete the Working area document.
    xmlHttp.Open(”DELETE”, docUrl, false);
    xmlHttp.Send();
}
catch (ex)
{}

Another approach a co-worker recommended was around using Sharepoint Designer to construct a workflow.  I like this idea because typically these solutions are based on a consistent workflow.  However, there are some downsides to this approach - including having to learn Designer, having “code” and logic in multiple places, and security around execution of the workflow.  I’m going to try and explore this option some more and will post some results.

Merge Documents View Missing

I’m not sure what I was doing with an InfoPath 2003 solution I was working on today, but somehow the “Merge Documents” view in the form library I published it to on a Sharepoint 2007 server disappeared. 

 

I double-checked the “Enable form merging” option within the Form Options of InfoPath, and it was checked. 

In fact, when opening a new instance of the form, the Merge Forms option was available.  The view was just missing from Sharepoint.

To resolve the issue I simply unchecked the option, published the form, then rechecked the option and published the form again.  The view then magically appeared.

Dundas for WPF (Not)

Yesterday I talked about finding a link to a Dundas page that talks about their exploration of implementing their chart components in WPF.  After viewing their Flash based demo, I fired off an email to inquire more about their progress in the WPF/Silverlight space.  I received the following email response.

Thank you for your question regarding Dundas’ plans for WPF. 

At the moment, we are focusing our development efforts on the best technology available for helping our clients build robust Digital Dashboard solutions.  With this in mind, our primary development efforts remain in .NET, SQL Reporting Services and SharePoint 2007.  Although we have been investigating, testing and developing with WPF extensively, we don’t feel it is the best suited technology at the moment. 

We do not currently have a public roadmap for any WPF releases, however when this becomes available, we will ensure that you get immediate access to it.

It doesn’t look like we’ll be seeing a WPF/Silverlight marriage with Dundas in the short term.  This is unfortunate because I really like the Dundas suite of tools and I think there are scenarios where charting can benefit from the richness that WPF provides.