Marcus Rosen.NET

I developed a Digital Signing component (see previous post) tested it and put it under source control. A week later I tried the component again and this time it wouldn't work. I tried everything, but still couldn't figure out what went wrong, considering nothing had actually changed on the code level.

After some searching I came across the solution on the newsgroups. It turns out that InfoPath (and maybe other Office Product) defaults to .NET 2.0 if installed. And as it turned out, although I hadn't yet installed the 2nd version of the framework, it some how was installed on my computer. I blame WINDOWS UPDATE, which is constantly running.. ;-)

To get the InfoPath to default back to .NET 1.1, you need to update or create a file named INFOPATH.EXE.CONFIG, add it to the same directory as your infopath.exe and add the following:

<?xml version ="1.0"?>
<configuration>
    <startup>
        <requiredRuntime version="v1.1.4322"/>
    </startup>
</configuration>

Apparently this goes for any old .NET applications.

To read more about this:
Visual Studio 2003 Mixed Mode Debugging Crash

Digital Signature are useful for detecting that information has tampered with and is easily added to an InfoPath form through a wizard interface. But what if you wanted to add a one without using the wizard? With InfoPath 2003 now being able to run managed code(SP1), this is now relatively easy.

Microsoft has published the follwing comprehensive articles on the subject:

Digitally Signing Data in InfoPath 2003

Verify and Add Digital Signatures to Form Data in InfoPath 2003 Using MSXML 5.0 or .NET Framework Managed Code

If you need a certificate for development purposes, I recommend using OpenSSL

This site explains how to create a self-signed certificate:
OpenSSL Command-Line HOWTO

Need to interact with Active Directory (or other LDAP source) through your BizTalk implementation?

One option to be able to do this is to use Directory Service Markup Language (DSML).
DSML is a XML-based langaguge which allows you to interact with a LDAP source, such as Active Directory. You can (among other things) add, delete, update and query your directory source just as within the System.DirectoryServices namespace.

The advantage of using DSML over the System.DirectoryServices namespace is that you can go directly from an XML structure to another XML structure (through a transformation map) within your BizTalk orchestration, while if going through the the System.DirectoryServices namespace you are required you to go from
XML Message -> .NET object -> XML Message by calling an external assembly from the orchestration.


An example DSML Add message looks like this:

<addRequest dn="CN=Alice,OU=HR,DC=Example,DC=COM">
   <attr name="objectclass"><value>top</value></attr>
   <attr name="objectclass"><value>person</value></attr>
   <attr name="objectclass"><value>organizationalPerson</value></attr>
   <attr name="sn"><value>Johnson</value></attr>
   <attr name="givenName"><value>Alice</value></attr>
   <attr name="title"><value>Software Design Engineer</value></attr> 
</addRequest>


Microsoft has released a DSML Service (DSML Standard v2.0) for Windows which runs as a Windows Service and exposes a web service interface. It comes with some good coding examples and a Web based console to directly execute DSML against the service.
The service can further be secured through certificates to prevent unauthorised access.


Links:

DSML Services for Windows

DSML v2.0 Documentation

XML Schema for DSML

Hi there!
My name is Marcus Rosen and I'm a Solution Developer with Data#3 in Brisbane, Australia.

My main technology focus is BizTalk Server and .NET development but this blog will hopefully contain posts regarding a range of MS products such as Windows Share Point Service (WSS), SharePoint Portal Server (SPS) Office InfoPath 2003, etc.