Norman Headlam

Heading to PDC

2008-10-25T08:46:00.002-05:00

Well I'm off to PDC 2008 in LA today. Hope to learn lots of new stuff. I plan to update my blog (more regularly ).

Get Silverlight 2.0 Beta 1

2008-03-07T05:54:00.003-06:00

Silverlight 2.0 Beta 1 ships finally! Get the SDK and tools here and the Silverlight runtime install from the Silverlight site here

Web Service Software Factory

2006-07-29T23:35:00.000-05:00

The latest Software Factory dealing with the creation of ASMX based service was just posted on the MSDN web site. Tom Hollander from the Patterns & Practices team has a great write up here.

Smart Client Software Factory - June 2006 Release

2006-07-01T07:51:00.000-05:00

Finally the Smart Client Software Factory is released on MSDN. This version of the Smart Client Software Factory has a dependency on the Composite Application UI Block and Enterprise Library 2.0. As such the product must be preinstalled and the install package with ask for the location. The Software Factory is fully documented and comes with two (2) reference implementation. In addition the Software Factory Guidance Package Solution is included and can be modified to fit into your corporate standards. Before installing make sure you close any instance of Visual Studio you have running. You can read more about it here.

GAT/GAX June 2006

2006-06-24T23:15:00.000-05:00

The June 2006 version of the Guidance Automation Toolkit (GAT) and the Guidance Automation Extension (GAX) has been posted on the MSDN site.

Web Service Software Factory

2006-04-12T11:13:00.000-05:00

In the same vain as Smart Client Baseline Architecture Toolkit (SC-BAT), we now have a GAT package for service development. Referred to as the Service Baseline Architecture Toolkit (ServiceBAT) or its new name Web Service Software Factory, this tool will provide actionable guidance that can assist you in developing services for WCF (and hopefully soon for ASMX 2.0). The guidance assists architects and developers with structuring a solution that meets their business requirements/practice while still enforcing some key design patterns and concepts when developing web services following SO principles. I would encourage folks to take and look and give

Smart Client BAT

2006-04-11T10:43:00.000-05:00

The CTP for Smart Client Baseline Architecture Toolkit (SC-BAT) is finally available on the Microsoft web site. SC-BAT is a GAT package that comes with a number of recipes to aid in the development of Composite WinForm applications based on CAB (Composite Application Block) and WinForm 2.0. Do take a look and give it a try..

Object Builder

2006-01-14T23:38:00.000-06:00

Brian Burton from the Patterns and Practice team posted a very good article on Object Build usage in EntLib 2.0.

ObjectBuilder

2005-12-14T15:15:00.000-06:00

Updated 1/14/2006 to include definition of MyBuilderContext class

I've started to play with ObjectBuilder (OB) that comes with CAB and EntLib to learn how it works. I’m no expert so take what I’m about to say in that context. What I’m doing is looking at the unit test to figure out how it works. You could also take a look at the CAB and EntLib 2.0 code to get an idea as well. I create a simple sample to get my feet wet. Again I did this as a first try at understanding OB and the code presented here has been stripped down to present the idea. The important things to note is that OB is a framework for building a DI system, so you have to write some code to the DI system in place. In this example the DI sub-system (the poor mans version) is implemented in the MyContextFactory. Also note that my sample does not dispose of the object by running through the build strategy at the end… this is my laziness.

This is the main program file. I want to create an instance of MyForm as a singleton without using new and also inject the necessary object needed by MyForm. In this example I also wanted to test constructor injection, method injection and property injection. Method injection is a very interesting idea fro doing initialization after construction… neat.

Program.cs


using System;
using System.Collections.Generic;
using System.Windows.Forms;


namespace ObjectBuilderApp
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);

            MyForm form = MyBuilderFactory<MyForm>.BuildSingletonObject( "Main Form" );
            Application.Run(form);
        }
    }
}

This is the MyForm class that represents the form. Note I did not show the designer code here. It requires a number of object that are injected.

MyForm.cs


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using Microsoft.Practices.ObjectBuilder;

namespace ObjectBuilderApp
{
    public partial class MyForm : Form
    {
        private Customer _customer;
        private Foo _foo;

        // Constructor Injection
        [InjectionConstructor()]
        public MyForm(Customer customer) : this()
        {
            this._customer = customer;
        }


        // Setter Injection
        [Dependency( SearchMode = SearchMode.Local, CreateType = typeof(Foo), NotPresentBehavior = NotPresentBehavior.CreateNew)]
        public Foo Foo
        {
            set
            {
                this._foo = value;
            }
        }

        // Method Injection
        [InjectionMethod()]
        public void Display([Dependency(CreateType = typeof(Foo), NotPresentBehavior = NotPresentBehavior.CreateNew)] Foo foo)
        {
           System.Diagnostics.Trace.WriteLine(foo.Name);
        }

        [InjectionMethod()]
        public void Display2([Dependency(CreateType = typeof(Foo), NotPresentBehavior = NotPresentBehavior.CreateNew)] Foo foo)
        {
            System.Diagnostics.Trace.WriteLine(foo.Name);
        }

        [InjectionMethod()]
        public void Display3([Dependency(CreateType = typeof(Foo), NotPresentBehavior = NotPresentBehavior.CreateNew)] Foo foo)
        {
            System.Diagnostics.Trace.WriteLine(foo.Name);
        }

        public MyForm()
        {
            InitializeComponent();        
        }

        private void button1_Click(object sender, EventArgs e)
        {
            MessageBox.Show(this._customer._foo.Name);
        }
    }
}

This is the MyContextFactory class. This is a static class that allows for the creation of an object based on the Object Builder (OB) framework. In some ways this class is my DI subsystem (yes not a very good version).

MyContextFactory.cs


using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.ObjectBuilder;

namespace ObjectBuilderApp
{
    public class MyBuilderFactory<T> where T : class
    {
        public static T BuildSingletonObject( string name )
        {
            MyBuilderContext ctx = new MyBuilderContext();

            //ctx.InnerChain.Add(new SingletonStrategy());
            ctx.InnerChain.Add(new CreationStrategy());

            // enables method injection
            ctx.InnerChain.Add(new MethodReflectionStrategy());
            ctx.InnerChain.Add(new MethodExecutionStrategy());

            // enables property njection
            ctx.InnerChain.Add(new PropertyReflectionStrategy());
            ctx.InnerChain.Add(new PropertySetterStrategy());
         
            ctx.Policies.SetDefault<ICreationPolicy>(new DefaultCreationPolicy());

            ctx.Policies.Set<ISingletonPolicy>(new SingletonPolicy(true), typeof(MyForm), null);

            return ctx.HeadOfChain.BuildUp(ctx, typeof(T), null, name) as T;
        }
    }
}

This Customer class is the Customer class that gets injected into the MyForm class, but itself also needs another object Foo to be injected.

Customer.cs


using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.ObjectBuilder;
using System.Windows.Forms;

namespace ObjectBuilderApp
{
    public class Customer
    {
        public Foo _foo;

        // Constructor Injection
        [InjectionConstructor]
        public Customer([CreateNew] Foo foo)
        {
            this._foo = foo;
        }

        // Method Injection
        [InjectionMethod]
        public void Display([Dependency(Name="MyFoo", CreateType = typeof(Foo), NotPresentBehavior = NotPresentBehavior.CreateNew)] Foo foo)
        {
            System.Diagnostics.Trace.WriteLine(foo.Name);
        }
    }
}

The Foo class is just a nother class that gets used by the Customer class. This class does not use any kind of injection.

Foo.cs

using System;

using System.Collections.Generic;
using System.Text;

namespace ObjectBuilderApp
{
    public class Foo
    {
        string _name;

        public string Name
        {
            get
            {
                if (this._name == null)
                    return "Norm";
                else
                    return this._name;
            }
            set
            {
                this._name = value;
            }
        }
    }
}



MyBuilderContext.cs

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.ObjectBuilder;

namespace ObjectBuilderApp
{
    public class MyBuilderContext : BuilderContext
    {
        public IReadWriteLocator InnerLocator;
        public BuilderStrategyChain InnerChain = new BuilderStrategyChain();
        public PolicyList InnerPolicies = new PolicyList();
        public LifetimeContainer lifetimeContainer = new LifetimeContainer();

        public MyBuilderContext()
            : this(new Locator())
        {
        }

        public MyBuilderContext(IReadWriteLocator locator)
        {
            InnerLocator = locator;
            SetLocator(InnerLocator);
            StrategyChain = InnerChain;         
            SetPolicies(InnerPolicies);

            if (!Locator.Contains(typeof(ILifetimeContainer)))
                Locator.Add(typeof(ILifetimeContainer), lifetimeContainer);
        }
    }
}

Composite UI Application Block (CAB)

2005-11-15T07:02:00.000-06:00

The November 2005 Release 1.0 (C# only) version of the Composite UI Application Block (CAB) is now available on the P&P site. I'm looking forward to the improvements made since the last CTP. Will blog on interesting finds.

Composite Application UI Block (CAB) CPT2

2005-10-07T20:23:00.000-05:00

The October 2005 CTP 2 version of the Composite UI Application Block (CAB) is now available on the P&P site. I'm looking forward to the improvements made since the last CTP. Will blog on interesting finds.

.NET Application Configuration File Management

2005-08-15T22:12:00.000-05:00

1. .NET Application Configuration

One of the nice features .NET is the interoperability story that goes with using a .NET component form a non-.NET client such as an unmanaged C++ Windows® application, a VB application, or even scripting. While the interoperability story is well know and understood, much is not said about using the native .NET configuration files in there mixed mode operation.

It is common for a .NET component or application developer to include a configuration file (i.e., <application name>.exe.config or web.config) file with there application. In most cases the component developer chooses to use the native .NET support for configuration file (i.e., System.Configuration et-al). In a .Net to .NET scenario this works great out-of-the-box, but in a non-.NET to .NET scenario it is not clear to some how this process works. This paper will attempt to shed some light on the process. In this paper I will consider several scenarios dealing with COM Interop. I will not consider C++ interop and I will also discuss the option of not using the native .NET configuration support, but rather opting to read your own configuration data yourself. The options I will consider are as follows:

1) Unmanaged C++ Client using .NET
2) ASP JavaScript Client using .NET
3) HTML JavaScript Client using .NET
4) Any Client using .NET Enterprise Services
5) Use Application Specific Configuration Reading

For the purpose of the scenarios listed above we will use the following .NET component code as a base:

// ManagedComponent.CS

using System;

using System.Configuration;

using System.Runtime.InteropServices;

namespace Norman.Headlam.Sample

{

/// <summary>

/// Summary description for Data class.

/// </summary>

[ComVisible(true)]

[ClassInterface(ClassInterfaceType.AutoDual)]

public class Data

{

public Data()

{

}

public string GetData()

{

string data = ConfigurationSettings.AppSettings["data"] as string;

string configFile = AppDomain.CurrentDomain.GetData( "APP_CONFIG_FILE" ) as string;

return data + configFile;

}

// AssemblyInfo.CS

using System.Reflection;

using System.Runtime.CompilerServices;

[assembly: AssemblyTitle("Managed Component")]

[assembly: AssemblyDescription("Managed Component")]

[assembly: AssemblyConfiguration("")]

[assembly: AssemblyCompany("Norman Headlam")]

[assembly: AssemblyProduct("Managed Component Sample")]

[assembly: AssemblyTrademark("Norman Headlam")]

[assembly: AssemblyCulture("")]

[assembly: ComVisible(false)]

[assembly: AssemblyVersion("1.0.0.0")]

[assembly: AssemblyDelaySign(false)]

[assembly: AssemblyKeyFile("")]

[assembly: AssemblyKeyName("")]

In this simple component, the .NET component exposes a GetData method the simply returns a string that is read from the configuration file that the client can then display.

Note that for this managed component I did not strongly name the assembly with a strong name using a public/private key pair and the sn.exe tool (see the content of the AssemblyInfo.CS file). This is because I’m not going to deploy the component to the global assembly cache (GAC) in one of the scenario and I wanted to make this point. Instead, for this scenario, I’m going to co-locate the .NET DLL assembly along side the client exe to demonstrate that .NET will still find the component. This is possible since the .NET runtime will simply look for the assembly in the AppPath (i.e., the directory of the EXE process) for all referenced assemblies. Also note that I attributed the Data class with the ComVisible and ClassInterface attributes. The ComVisible attribute is needed since I made all component COM invisible (i.e., not accessible via COM … without some work) by default (see the AssemblyInfo.CS file). The ClassInterface attribute is used to expose the public methods of the Data class as a dual interface (i.e., support early and late binding). I wanted early binding to use it easily from the C++ client. This approach is usually not recommended due to versioning issues you might have.

One last point; when we compile and generate the TLB for this managed type (i.e., RegAsm /TLB ManagedComponent.DLL). We get the following information in the TLB file (i.e., the IDL information):

// Generated .IDL file (by the OLE/COM Object Viewer)

// typelib filename: ManagedComponent.tlb

[

uuid(F045BFBB-1349-33B1-A41F-306BA6AA68AE),

version(1.0),

custom(90883F05-3D28-11D2-8F17-00A0C9A6186D, ManagedComponent, Version=1.0.2048.16331, Culture=neutral, PublicKeyToken=null)

]

library ManagedComponent

{

// TLib : // TLib : Common Language Runtime Library : {BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}

importlib("mscorlib.tlb");

// TLib : OLE Automation : {00020430-0000-0000-C000-000000000046}

importlib("STDOLE2.TLB");

// Forward declare all types defined in this typelib

interface _Data;

[

uuid(352B66A6-77AE-33CB-B18C-4ABDE732D984),

version(1.0),

custom(0F21F359-AB84-41E8-9A78-36D110E6D2F9, Norman.Headlam.Sample.Data)

]

coclass Data {

[default] interface _Data;

interface _Object;

};

[

odl,

uuid(30387035-82EA-3D39-96D0-8BA58475F170),

hidden,

dual,

nonextensible,

oleautomation,

custom(0F21F359-AB84-41E8-9A78-36D110E6D2F9, Norman.Headlam.Sample.Data)

]

interface _Data : IDispatch {

[id(00000000), propget,

custom(54FC8F55-38DE-4703-9C4E-250351302B1C, 1)]

HRESULT ToString([out, retval] BSTR* pRetVal);

[id(0x60020001)]

HRESULT Equals(

[in] VARIANT obj,

[out, retval] VARIANT_BOOL* pRetVal);

[id(0x60020002)]

HRESULT GetHashCode([out, retval] long* pRetVal);

[id(0x60020003)]

HRESULT GetType([out, retval] _Type** pRetVal);

[id(0x60020004)]

HRESULT GetData([out, retval] BSTR* pRetVal);

};

Note that the methods from System.Object are also exported.

1.1. Unmanaged C++ Client using .NET Component Scenario

In this scenario we will consider the case of an unmanaged C++ console client (UnmanagedClient.EXE) using a .NET DLL assembly. For this process to work using the native .NET configuration mechanism, the .NET DLL assembly should have the following attributes:

1) The .NET component that is being exposed must have a public default constructor (i.e., take no arguments).
2) At a minimum the .NET component should be COM visible. You can also make all components in the assembly COM visible, but that is not recommended.

3) The .NET DLL assembly must be registered in the system registry (i.e., regasm /tlb assmeblyname.dll).
4) If .NET DLL assembly use other .NET Framework assemblies, make sure there are co-located with the .NET DLL assembly or are deployed into the GAC.

1.1.1. Client Application Code (UnmanagedClient.EXE)

In this scenario we will use the following unmanaged client code console application as the client.

stdafx.h

#pragma once

#include <iostream>

#include <tchar.h>

#import "..//ManagedComponent.tlb" no_implementation \

raw_interfaces_only \

raw_native_types

UnmanagedClient.cpp

#include "stdafx.h"

#include <atlbase.h>

#include <atlcom.h>

#include <comdef.h>

int _tmain(int argc, _TCHAR* argv[])

{

USES_CONVERSION;

HRESULT hr = CoInitialize( NULL);

CComPtr< ManagedComponent::_Math > spManaged;

hr = spManaged.CoCreateInstance( __uuidof( ManagedComponent::Math ) );

long z;

hr = spManaged->Add( 2, 2, &z );

printf( "2 + 2 = %d", z );

CComPtr< ManagedComponent::_Data > spData;

hr = spData.CoCreateInstance( __uuidof( ManagedComponent::Data ) );

CComBSTR data;

hr = spData->GetData( &data );

printf( "\n\n%s", OLE2A( data ) );

data.Empty( );

CoUninitialize( );

return 0;

}

1.1.2. Client Application Configuration File (UnmanagedClient.EXE.Config)

The unmanaged console application is called UnmanagedCleint.EXE. As such we will need an associated configuration file called UnmanagedClient.EXE.Config. The configuration file is as follows and is in the same directory as the UnmanagedClient.EXE program.

UnmanagedClient.EXE.Config

<?xml version="1.0" encoding="utf-8" ?>

</appSettings>

</configuration>

1.1.3. Special Notes

To get the program to compile we imported the ManagedComponent.TLB, generated using the RegAsm /TLB ManagedComponent.DLL command, into the unmanaged client. This allowed us to access the managed class public methods from the COM client.

1.1.4. Opportunity for improvements

We could have improved this code some.

1) First we could have used an interface to convey the public interface to the client. We still have to make the class COM visible, but client could access the managed component via an interface instead.

2) Secondly, we could have strongly named the assembly. This would allow us to deploy the assembly into the GAC and thus share the same assembly between all clients. This feature would also support versioning using the native .NET support for versioning.

1.2. ASP JavaScript Client using .NET Component Scenario

In this scenario we will consider the case of an unmanaged ASP client using JavaScript to access the function of the .NET DLL assembly. For this process to work using the native .NET configuration mechanism, the .NET DLL assembly should have the following attributes:

3) The .NET component that is being exposed must have a public default constructor (i.e., take no arguments).
4) At a minimum the .NET component should be COM visible. You can also make all components in the assembly COM visible, but that is not recommended.

5) The .NET DLL assembly must be strongly signed with a private/public key pair that was generated with the sn.exe tool (i.e., sn.exe –k sample.snk)

6) The .NET DLL assembly must be registered in the system registry (i.e., regasm /tlb assmeblyname.dll).
7) The .NET DLL assembly must be deployed to the GAC (i.e., gacutil.exe /i ManagedComponent.DLL)
8) If the .NET DLL assembly use other .NET Framework assemblies, make sure there are deployed into the GAC as well.

1.1.5. Client Application Code (ASPClient.ASP)

In this scenario we will use the following JavaScript in an ASP file (i.e.) as the client.

ASPClient.asp

<% @Language=JScript %>

data = GetData( );

Response.Write( "<div>" );

Response.Write( data );

Response.Write( "</div>" );

// Define Server Side Script Function

function GetData( )

{

var objData = new ActiveXObject( "Norman.Headlam.Sample.Data" );

return objData.GetData( );

}

</Script>

1.1.6. Client Application Configuration File (Dllhost.EXE.Config)

The ASP client application is called ASPClient.ASP. Since ASP applications will get executed in a surrogate process, dllhost.exe in this case. We need to associate a configuration file with the dllhost.exe process. This process is located in the %SystemRoot%\System32 directory. As such we need to copy a version of the dllhost.exe.config file to that directory. The content of the file (for this example) is the same as before.

dllhost.exe.config

<?xml version="1.0" encoding="utf-8" ?>

</appSettings>

</configuration>

1.1.7. Special Notes

The dllhost.exe.config file is a shared asset among all applications that uses it a surrogate. This does not bode well in all scenarios. We will discuss alternatives later. Also note that since the ASP application, running in the dllhost.exe process is running under a credential. If the .NET component needed access to a restricted resource (i.e., a resource that requires certain security access to use such as the certificate store, a special file folder, etc.), the credential that the dllhost.exe process runs under (i.e., IWAM_<machine name>) would need access as well with this default configuration.

1.1.8. Opportunity for improvements

The following are opportunities for improvements:

1) We could have deployed the .NET Component as an Enterprise Services Component. This would allow use to have per-application configuration file and allowed for using a specific id to execute under that would give us a little more control with the least amount of work (i.e., no impersonation, etc.)

1.3. HTML JavaScript Client using .NET Component Scenario

In this scenario we will consider the case of an unmanaged client using JavaScript to access the function of the .NET DLL assembly (i.e., an html file executing code locally, etc.). For this process to work using the native .NET configuration mechanism, the .NET DLL assembly should have the following attributes:

3) The .NET DLL assembly must be strongly signed with a private/public key pair that was generated with the sn.exe tool (i.e., sn.exe –k sample.snk)

4) The .NET DLL assembly must be registered in the system registry (i.e., regasm /tlb assmeblyname.dll).
5) The .NET DLL assembly must be deployed to the GAC (i.e., gacutil.exe /i ManagedComponent.DLL)
6) If the .NET DLL assembly use other .NET Framework assemblies, make sure there are deployed into the GAC as well.

1.1.9. Client Application Code (HtmlClient.htm)

In this scenario we will use the following JavaScript in an htm file (i.e., HTMLClient.htm) as the client.

HTMLClient.htm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>

<head>

<title>HTML Client Calling .NET Assembly</title>

function GetData( )

{

var objData = new ActiveXObject( "Norman.Headlam.Sample.Data" );

return objData.GetData( );

}

</Script>

</head>

<body>

</body>

</html>

1.1.10. Client Application Configuration File (Iexplore.Exe.Config)

The client application is a file called HTMLClient.HTM. Since the client code is executing in the context of the internet explorer browser applications (i.e., iexplore.exe) we need to configure the configuration file for iexplore.exe.config. The iexplore.exe process is located in the %SystemRoot%\System32 directory. As such we need to copy a version of the iexplore.exe.config file to that directory. The content of the file (for this example) is the same as before.

iexplore.exe.config

<?xml version="1.0" encoding="utf-8" ?>

</appSettings>

</configuration>

This scenario is the same as it was for the ASP application with the exception of the name of the process. Had we execute this application in a custom browser, we would simply use its config file in stead (i.e., <custom application>.exe.config).

1.1.11. Special Notes

The iexplore.exe.config file is a shared asset among all applications that uses it as a surrogate. This does not bode well in all scenarios. We will discuss alternatives later. Also note that since the iexplore.exe application runs with the user’s credential (unless otherwise instructed to), if the .NET component needed access to a restricted resource (i.e., a resource that requires certain security access to use such as the certificate store, a special file folder, etc.), the credential that the iexplore.exe process runs under would need access as well.

1.1.12. Opportunity for improvements

I don’t find much room for improvement here. That said here is one improvement:

1) Don’t use this approach.

1.4. .NET Component Configured as a .NET Enterprise Services Application Scenario

In this scenario we will use an ASP client application that calls a component in a .NET Enterprise Services Application (a.k.a. COM+ Application). While this scenario uses an ASP client application, we could have used any other type of client (i.e., an unmanaged C++ console application, a .NET application, etc.).

For this scenario, the .NET component must have the following attributes:

1) The .NET component that is being exposed must have a public default constructor (i.e., take no arguments).
2) The .NET component ~~must~~ should be based on an interface.
3) The .NET component must extend the System.EnterpriseServices.ServiceComponent class.
4) The .NET DLL assembly must reference the System.EnterpriseServices.DLL
5) At a minimum the .NET component should be COM visible. You can also make all components in the assembly COM visible, but that is not recommended.

6) The .NET DLL assembly must be strongly signed with a private/public key pair that was generated with the sn.exe tool (i.e., sn.exe –k sample.snk)

7) The .NET DLL assembly must be registered in the system registry (i.e., regasm /tlb assmeblyname.dll).
8) The .NET DLL assembly must be deployed to the GAC (i.e., gacutil.exe /i ManagedComponent.DLL)
9) If the .NET DLL assembly used other .NET Framework assemblies, make sure there are deployed into the GAC as well.

10) The .NET DLL assembly must be registered with .NET Enterprise Services (i.e., COM+). There are several ways to do this (see the MSDN docs for more info or consult “COM and .NET Component Services” by Juval Lowy published by O’Reilly. To register the assembly, use the following command:

regsvcs.exe /appname:ManagedComponent ManagedComponentES.DLL

This registration process will also create a type library that can be used by a C++ unmanaged client (i.e., ManagedComponentES.TLB). To make sure the application gets registered as a “Server Application” add the following to the assemblyinfo.cs file

assembly: using System.EnterpriseServices;

ApplicationActivation(ActivationOption.Server)]

1.1.13. .NET Enterprise Services Component (ManagedComponentES.DLL)

The following code is what our test .NET Component looks like after it is converted to be a .NET Enterprise Services component.

Data.cs

using System;

using System.Configuration;

using System.Runtime.InteropServices;

using System.EnterpriseServices;

namespace Norman.Headlam.Sample.EX

{

/// <summary>

/// Summary description for Data class.

/// </summary>

[ComVisible(true)]

[ClassInterface(ClassInterfaceType.AutoDual)]

public class Data : ServicedComponent, IGetData

{

public Data()

{

}

public string GetData()

{

return ConfigurationSettings.AppSettings["data"] as string;

}

IGetData.cs

using System;

namespace Norman.Headlam.Sample.ES

{

/// <summary>

/// Summary description for IGetData.

/// </summary>

public interface IGetData

{

string GetData();

}

AssemblyInfo.CS

using System.EnterpriseServices;

using System.Reflection;

using System.Runtime.CompilerServices;

using System.Runtime.InteropServices;

[assembly: AssemblyTitle("Managed Component")]

[assembly: AssemblyDescription("Managed Component")]

[assembly: AssemblyConfiguration("")]

[assembly: AssemblyCompany("Norman Headlam")]

[assembly: AssemblyProduct("Managed Component Sample")]

[assembly: AssemblyTrademark("Norman Headlam")]

[assembly: AssemblyCulture("")]

[assembly: ComVisible(false)]

[assembly: ApplicationActivation(ActivationOption.Server)]

[assembly: AssemblyVersion("1.0.0.0")]

[assembly: AssemblyDelaySign(false)]

[assembly: AssemblyKeyFile(@"..\..\..\sample.snk")]

[assembly: AssemblyKeyName("")]

After the registration of the component, the Component Manager Explorer will look something like this:

Figure 1 - Managed Component in Component Services Manager

1.1.14. Configuring the .NET Enterprise Services Application

We next need to configure the .NET Enterprise Services Application to run under a specific credential and setup the application to use a “per application configuration file” (i.e., we will no longer use the dllhost.exe.config file across all applications). Instead we will configure each .NET Enterprise Services Application (i.e., COM+ Application). This process works for Windows XP SP2 with .NET Framework 1.1 and Windows 2003 with the .NET 1.1 Framework.

1) Create an “Application Root Directory” and config the setting in the “Activation” properties for the .NET Enterprise Services Application. You can use the Component Services Explorer as shown here.

Figure 2 - Configure Application Root Directory for Managed Component

2) Add a file called application.manifest to the “Application Root Directory” folder (i.e., C:\TEMP\Unmanaged to Managed). This file should have the following content

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

</assembly>

3) Add a file called application.config to the “Application Root Directory” folder (i.e., C:\TEMP\Unmanaged to Managed). This represents the per application configuration. For this example the content of the file should be as follows.

<?xml version="1.0" encoding="utf-8" ?>

</appSettings>

</configuration>

1.1.15. Client Application Code (ASPClientUsingES.ASP)

The ASP client application we will use in this scenario is called ASPClientUsingES.ASP. In this scenario the .NET component will get executed in the dllhost.exe process, but instead of using the dllhost.exe.config file, it will use application.config located in the “Application Root Directory”

ASPClientUsingES.ASP

<% @Language=JScript %>

data = GetData( );

Response.Write( "<div>" );

Response.Write( data );

Response.Write( "</div>" );

// Define Server Side Script Function

function GetData( )

{

var objData = new ActiveXObject( "Norman.Headlam.Sample.ES.Data" );

return objData.GetData( );

}

</Script>

data = GetData( );

Response.Write( "<div>" );

Response.Write( data );

Response.Write( "</div>" );

// Define Server Side Script Function

function GetData( )

{

var objData = new ActiveXObject( "Norman.Headlam.Sample.ES.Data" );

return objData.GetData( );

}

</Script>

1.1.16. Special Notes

You might experience a problem like so when you execute the application. As usually check to make sure the .NET Enterprise Services Application is configured with the correct credentials to do its job and interact with the client (ASPClientUsngES.ASP in this case).

Figure 3 - Error Message with Improper Security Credentials

You can configure the credentials for the .NET Enterprise Services Application using the Component Services Explorer as shown here. In this example I’m configuring it to use my personal domain ID (this is not the recommended approach). It is best to create a special account to execute you application under.

1.5. Changing the Default Config File Name

At this time you might be wondering how was it possible to have a configuration file with a name other that <application name>.exe.config; such as web.config or application.config. As it turns out the application configuration file a .NET component uses is determined independently for each AppDomain within a process and more importantly you can change it. To change the location and name of the configuration file you must follow the rules below:

1) In your .NET component (or exe process) you should change the configuration file locations as shown below. Notice that you can give the file any name and place it in any folder that the process has access to.

AppDomain.CurrentDomain.SetData( “APP_CONFIG_FILE”, “C:\TEMP\Unmanaged to Managed\Foo.MyConfig” );

2) You must make the call above before making any other calls to the .NET configuration API. You only have one chance to change the location of the configuration file for each unique AppDomain.

You should know that this technique will work in all the scenarios we discussed so far, but you should only use it in rare cases. If you are using a .NET EXE assembly, it is safe to use this approach. In this case you would change the configuration location in the process startup. However, in the COM interop or a .NET Enterprise Services case, you really don’t have control over which component will be called first and thus not have a chance to set the configuration file location in all cases. In the case of the .NET Enterprise Services configuration I would always opt to using the “Application Root Directory” approach as it is more safe and configurable out-of-band.

Here is an example of such an approach where we change the config file in the component constructor. This assume of course we are only using this single component or this component is always called before calling another method, property, etc. that uses the native .NET configuration API.

Data.cs

using System;

using System.Configuration;

using System.Runtime.InteropServices;

using System.EnterpriseServices;

namespace Norman.Headlam.Sample.CustomConfig

{

/// <summary>

/// Summary description for Data class.

/// </summary>

[ComVisible(true)]

[ClassInterface(ClassInterfaceType.AutoDual)]

public class Data : ServicedComponent, IGetData

{

public Data()

{

// set the location of the configuration file

AppDomain.CurrentDomain.SetData( "APP_CONFIG_FILE", @"C:\TEMP\Unmanaged to Managed\Foo.MyConfig" );

}

public string GetData()

{

string data = ConfigurationSettings.AppSettings["data"] as string;

string configFile = AppDomain.CurrentDomain.GetData( "APP_CONFIG_FILE" ) as string;

return data + configFile;

}

1.6. Custom Config File API

Another option that is available to you is to opt out of the native .NET support for configuration files and use you own custom approach.

In this scenario you can just load up a configuration file using possibly the Xml DOM API, a File Stream API, etc. From there you would just read the configuration file as needed to get you configuration information, perhaps using XML DOM or deserializing it into an object. When this approach is use you clearly will not have the benefits of the native support provide by .NET, but that might, and quite often is, acceptable. Another feature you will loose is the application settings feature offered by WinForms. Another option also is to not require any out of band configuration information. If you choose this approach and do not need XML support I would also recommend that you remove the Syste.Xml.DLL reference to your assembly as well. This will save you a lot in runtime memory overhead.

The following is an example of a custom configuration that loads a config file that is assumed to be in the same directory as the exe process.

Data.cs

using System;

using System.Configuration;

using System.Runtime.InteropServices;

using System.EnterpriseServices;

using System.IO;

using System.Xml;

using System.Xml.Serialization;

namespace Norman.Headlam.Sample.NoConfig

{

/// <summary>

/// Summary description for Data class.

/// </summary>

[ComVisible(true)]

[ClassInterface(ClassInterfaceType.AutoDual)]

public class Data : ServicedComponent, IGetData

{

public Data()

{

}

public string GetData()

{

MyConfigurationType config = null;

FileStream fs = null;

XmlTextReader reader = null;

XmlSerializer ser = null;

// get the location of the configuration file

string configFile = AppDomain.CurrentDomain.SetupInformation.ApplicationBase + "custom.xml";

if( File.Exists( configFile ) )

{

// open the conlig file

using(fs = new FileStream( configFile, FileMode.Open) )

{

try

{

// deserialize config file into an object

reader = new XmlTextReader( fs );

ser = new XmlSerializer(typeof(MyConfigurationType));

config = ser.Deserialize( reader ) as MyConfigurationType;

}

catch( Exception ex )

{

return ex.Message;

}

return config.data + configFile;

}

XML Schema Generator

2005-08-03T22:51:00.000-05:00

Often I need to generate an XML schema from an XML document. My preferred tool is located here http://www.xmlforasp.net/CodeBank/System_Xml_Schema/BuildSchema/BuildXMLSchema.aspx.

I can choose between “Russian Doll” or “Separate Complex Type” style. The output is much better that XSD.EXE.

Unit Testing CAB

2005-07-19T11:45:00.000-05:00

One of the common problems reported with unit testing CAB via NUnit is the fact that the NUnit GUI crashes when executing the test. This is particular true with the Windows Forms unit test. To solve the problem we need to load the nunit-gui.exe application in a FX 2.0 environment. We can affect this by making the following change to the nunit-gui.exe.config file

<startup>
<supportedRuntime version="v2.0.50215" />  <supportedRuntime version="v2.0.40697" />  <supportedRuntime version="v1.1.4322" />  <supportedRuntime version="v1.0.3705" /> 

<requiredRuntime version="v1.0.3705" />
</startup>

You can also try using TestRunner instead of NUnit and you will not have this problem at all.

Composite UI Application Block (CAB)

2005-06-22T21:57:00.000-05:00

The second gotdotnet drop of the Composite UI Application Block – CAB for short – was drop about a week ago. CAB represents an import piece of software in the WinForm development space based on .NET 2.0. You can read more about CAB on the gotdotnet site here. I plan to start blogging about specific features of CAB going forward.

What is CAB

CAB is a guidance asset in the form of an application block like no other before it. CAB is based on .NET 2.0, but there is a strong possibility there will be a back port of the major features to .NET 1.1. CAB combines some of the development principles of EntLib, patterns such as MCV, Memento, Pub-Sub, etc. and codifies it into what I believe is a well factored set of classes for developing SO client applications. Unlike, the UIP block of past, CAB is very easy to understand and once you get some basic concepts it proves to be very useful and empowering.

BizTalk Server 2004

2004-11-25T13:54:00.000-06:00

BizTalk Server 2004 is a significant product. I think this piece of software (i.6 millions lines of C# code) is perhaps the least known, but yet, most useful software from Microsoft... ever. This is a product that we should learn from and use.

The Three Faces of Web Services

2004-10-26T09:01:00.000-05:00

I love Tim Ewal’s piece on “3 faces of Web services”. In the company I work for, most people would consider XML over HTTP not to be a web service because of the two missing elements “Envelope” and “Body”. This is unfortunate, but understandable. Most vendors have the same self-interest that we all have… looking out for number one (and in some case, the stock holders :-)). As such, most vendors will push the idea that if you are not using their toolkit (SOAP, SO< etc.), then you are not using web services. But, as other have pointed out (Tim Ewal and Sam Ruby), this is not the case in the real world. In the real world developers have done what they needed to do to get the product out. If you are big enough (read eBay) you can get away with a lot if the benefits of your service are worth the cost of getting in. But what about the internal corporate developer who have to integrate with more than one internal system to get her job done? For such a person, the eBay model usually works in the beginning, but once you begin to grow and would like the benefits of say Single Secure Sign-On, standards and conformance become very important. Tim Ewal said the overlap between SOAP and “XML over HTTP” is about 98%. Put another way, the differences between SOAP and “XML over HTTP” is 2% (read Envelope and Body element). Why not just put your XML in a SOAP envelope? Think of the great benefits you can gain down the road with WS-* (the ones you care about that is). For this reason, and knowing what we know today) I think XML over HTTP is just wrong… “Give SOAP a Chance”. Some might say that adding something to the XML (i.e., Envelope and Body elements) goes against principles such as TDD, but I would say that applies to code not data.

DevCon 2004

2004-10-26T08:03:00.000-05:00

Applied XML Developers Conference
Recently Tim Ewal posted a topic on wanting Relax NG. The premise of the blog is that Relax-NG provides a better sokution as compared to XSD. So why not adopt RNG instead? While I think Tim is right on, this feels like the VHS vs. Betamax debate. Most people felt that Betamax as better than VHS; yet VHS dominated the market (side note – I heard this was due in-part to the amount of porn videos that were release on VHS). So I say lets get on with it and embrace XSD. I'm sure it will be replace very soon... but not before its time. Fast forward to 2004, how many of you would buy a VHS tape when you have an option to buy a DVD instead. The same thing will happen with XSD; something better will come along and take hold. Along the way we will have some contenders (insert Laser Disk), but no technology will die before its time. Its time for XSD to live… give me the support (insert Tools… not porn) so I may live peacefully with my new friend (insert XSD).

... back to the topic

The Applied XML DevCon was simply awesome. The mode of the first day was somewhat pessimistic, but I learned a lot. Day two was more upbeat, but now I can’t get that song out of my head.

The truth of the matter is there are problems with the current stack of Web Services tools, specification, etc. out in the wild. Meanwhile, back in the real world, we are building application that work despite these imperfections and perceived drawbacks. I have yet to use perfect technology and if I did I would be worried. I’m convinced that no matter what the big vendors produce (read Microsoft and IBM); someone will find flaws and criticize it. However, this should not stop you form trying the technology... if it makes sense. In fact, you should welcome it. Most of the problems with these specifications is a result of not needing the technology. In that case, don’t use it. For the ones you need, just stay away from the edges if you don't have the stomach and you'll do fine. Most of the problems are indeed at the edges and not usually part of the core.

For more interesting summaries of the DevCon visit Chris's site for a list of sightings.

Fritz Onion On "Unfounded fears of 70%"

2004-07-27T13:33:00.000-05:00

Fritz Onion posted an excellent blog on ASP.NET 2.0 and unfounded fear of the new features being offered in the next released of the Framework and VS 2005.

Google is down?

2004-07-26T12:30:00.000-05:00

I can't believe it but the great Google is down

Google Error Server Error
The service you requested is not available at this time. Service error -27.

2003-11-03T15:01:00.000-06:00

ASP.NET and Client Certificate : Without .NET Enterprise Services

Microsoft has a fix to the System.DLL assembly that will allow an ASP.NET application to call a Web Service using the ASPNET account and SSL. You can find the notes to this fix at the following site http://support.microsoft.com/?id=817854

The architecture of the managed code is similar to the previous managed code version except there is no need to package the components in a COM+ Application. As a result all components can run in the same process space (and AppDomain). This will generally give better performance. However, you must find another way to keep your connections to the backend persisted (i.e., no Object Pooling). This is where you should consider using the ServicePoint and ServicePointManager classes.
Required Steps

1. Configure the ASPNET account to have access to the client certificate. You can accomplish this by using the winhttpcertcfg tool that comes with the WinHTTP SDK
a. winhttpcertcfg -g -c LOCAL_MACHINE\My -s MyCertificate -a ASPNET
b. Note: you can see who has access to a particular store by issuing the following command line command: winhttpcertcfg.exe -l -c LOCAL_MACHINE\My -s "mycertificate"

2. Apply the hot fix for the .NET Framework v1.0. You can find the relavant information at http://support.microsoft.com/?id=817854.

3. Export the client certificate to a file without the private key. You will not reference the client store directly; instead you will reference this file.

4. Implement the data access component using the WebResponse, WebRequest and optionally the ServicePoint and SerbvicePointManager classes.

5. Implement the ICertifciatePolicy interface.

6. Build the assembly and optionally signed the assembly with a strong name.

7. With the assembly now built and deployed to the Asp.NET application (i.e., virtual directory); you are now ready to use the certificate to communicate with the backend.

Sample Code

While this sample doesn't show it, you should build the data access component such that it is reusable (preferable via a configuration file) against any HTTP/HTTPS endpoints, etc. This sample also uses the ServicePoint and ServicePointManager classes to increase the number of persisted connections you can have against a single domain endpoint. The ServicePointManager class manages the connection for you and via the FindServicePoint method will return a connection if one already exist. If one does not exist, it will create a new connection.

The following files are associated with the data access component. The sample is meant to get the point across and as such all unnecessary code have been removed. In an enterprise version, you would have additional features such as: logging, tracing, configuration file, etc. (please email me to get a full sample).
You can test the sample by creating a client or ASP.NET web service to make a call to the MakeRequest method. Just pass the method the POST data (strData), the target URL (strURI e.g., https://:) and the method by which to sent the request (strMethod e.g., POST).

Post.cs file

using System;
using System.Net;
using System.Text;
using System.IO;
using System.Web;
using System.Security.Cryptography.X509Certificates;

namespace MyNamespace
{
public class HTTPDataAccess
{
public HTTPDataAccess( )
{
// Set a maximum of 20 connections to the host
ServicePointManager.DefaultConnectionLimit = 20;

// 1 minutes max ideal time
ServicePointManager.MaxServicePointIdleTime = 100000;
ServicePointManager.CertificatePolicy = new CertPolicy();
}

private string MakeRequest(string strData, string strURI, string strMethod)
{
// retrieve an existing connection to the specified URL (i.e., strURI) or create a new one
ServicePoint sp = ServicePointManager.FindServicePoint( strURI, null );

// create an instance of the httpWebRequest object
HttpWebRequest req = ( HttpWebRequest ) WebRequest.Create( sp.Address );

// add a client certificate to the http request object
req.ClientCertificates.Add( X509Certificate.CreateFromCertFile( @"D:\MyCertificates\dotnet.cer" ) );

// set the request method to POST, txml/xml with a 1 minute timeout
req.Method = "POST";
req.ContentType = "text/xml";
req.Timeout = 10000;
req.KeepAlive = true;

// if we have data to post, set the request stream object
if( strData != null )
{
byte[] SomeBytes = null;
SomeBytes = Encoding.UTF8.GetBytes( strData );
req.ContentLength = SomeBytes.Length;
Stream newStream = req.GetRequestStream( );
newStream.Write( SomeBytes, 0, SomeBytes.Length );
newStream.Close( );
}
else
{
req.ContentLength = 0;
}

WebResponse result = req.GetResponse( );
Stream ReceiveStream = result.GetResponseStream( );

Encoding encode = System.Text.Encoding.GetEncoding( "utf-8" );
StreamReader sr = new StreamReader( ReceiveStream, encode );

string strResponse = sr.ReadToEnd( );

sr.Close( );
result.Close( );
ReceiveStream.Close( );

return strResponse;
}
}
}

certpolicy.cs file

Same as .NET Enterprise Service Sample

2003-11-03T13:33:00.000-06:00

ASP.NET and Client Certificate : .NET Enterprise Services

Currently the Microsoft .NET Framework has a bug that does not allow for a configured .NET component (i.e., a .NET component that is configured as an Enterprise Service Application a.k.a. COM+ application) to access the client certificate from the key store unless the COM+ Application first loads up the user profile. This is true even if you configure the identity of the COM+ Application to be the same as the identity of the client certificate was installed under. To work around this problem you must take a few more steps. This process is outlined below and is further explained in this Microsoft article http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT13.asp.

Required Steps

1. Install the Client Certificate and note the id the certificate was installed under

2. Export the client certificate to a file without the private key. You will not reference the client store directly; rather you will reference this file

3. Implement the data access component using the WebResponse and WebRequest
a. Load the user profile the certificate is store under before accessing the certificate (see post.cs).
b. Implement the ICertifciatePolicy interface (see certpolicy.cs).
c. Extend you data access class with the ServiceComponent class (see post.cs)
i. Note: It is also advisable to create an interface to describe the public methods and implement the interface. This will allow you to see the public methods when viewing the configured component under the Component Service MMC snap-in.
d. Attribute the assembly to be a service component (assembly.cs …not shown).
e. Unload the user profile after the call has been made (see post.cs).

4. Build the assembly and signed the assembly with a strong name. This can be done via Visual Studio 2002/2003 or the Assembly Linker tool (al).

5. Register the assembly in the Component Service (RegSvcs) and copy to the GAC (gacutil).
a. regsvcs MyAssembly.DLL
b. gacutil /i MyAssembly.DLL

6. With the assembly registered in the GAC and configured as a .NET Enterprise Application (i.e., COM+ Application). Set the identity of the configured application to the user ID (i.e., principle) the certificate was installed with; you are now ready to use the certificate to communicate with the backend.

Sample Code

While this sample doesn’t show it, you should build the data access component such that it is reusable (preferable via a configuration file) against any HTTP/HTTPS endpoints, etc. You could also use the ServicePoint and ServicePointManager classes to increase the number of persisted connections you can have against a single domain endpoint. The ServicePointManager class manages the connection for you and via the FindServicePoint method will return a connection if one already exist. If one does not exist, it will create a new connection.
The following files are associated with the data access component. The sample is meant to get the point across and as such all unnecessary code have been removed. In an enterprise version, you would have additional features such as: logging, tracing, connection pooling, configuration file, etc. (please email me to get a full sample).
You can test the sample by creating a client or ASP.NET web service to make a call to the MakeRequest method. Just pass the method the POST data (strData), the target URL (strURI e.g., https://:) and the method by which to sent the request (strMethod e.g., POST).

Post.cs file

using System;
using System.Net;
using System.Text;
using System.IO;
using System.Web;
using System.Security.Principal;
using System.EnterpriseServices;
using System.Runtime.InteropServices;
using System.Security.Cryptography.X509Certificates;

namespace NyNamespace
{
public class HTTPDataAccess : ServicedComponent
{
[DllImport("advapi32.dll", CharSet=CharSet.Auto,
SetLastError=true)]

private extern static bool DuplicateToken(IntPtr
ExistingTokenHandle,
int SECURITY_IMPERSONATION_LEVEL,
ref IntPtr DuplicateTokenHandle);

[DllImport("kernel32.dll", CharSet=CharSet.Auto)]

private extern static bool CloseHandle(IntPtr handle);

public HTTPDataAccess( )
{
ServicePointManager.CertificatePolicy = new CertPolicy();
}

private IntPtr DupeToken(IntPtr token, int Level)
{
IntPtr dupeTokenHandle = new IntPtr(0);
bool retVal = DuplicateToken(token, Level, ref dupeTokenHandle);
if (false == retVal)
{
return IntPtr.Zero;
}
return dupeTokenHandle;
}

public string PostRequest( string strData, string strURI )
{
try
{
bool retVal = false;

// Need to duplicate the token. LoadUserProfile needs a token
// with TOKEN_IMPERSONATE and TOKEN_DUPLICATE.

const int SecurityImpersonation = 2;
IntPtr dupeTokenHandle = DupeToken(WindowsIdentity.GetCurrent().Token,SecurityImpersonation);

if(IntPtr.Zero == dupeTokenHandle)
{
throw new Exception("Unable to duplicate token.");
}

// Load the profile.

ProfileManager.PROFILEINFO profile = new ProfileManager.PROFILEINFO();
profile.dwSize = 32;
profile.lpUserName = @"headlam6\dotnetacct";

retVal = ProfileManager.LoadUserProfile(dupeTokenHandle, ref profile);

if(false == retVal)
{
throw new Exception("Error loading user profile. " + Marshal.GetLastWin32Error());
}

// create an instance of the httpWebRequest object
HttpWebRequest req = ( HttpWebRequest ) WebRequest.Create( strURL );

// set the request method to POST, txml/xml with a 1 minute timeout
req.Method = "POST";
req.ContentType = "text/xml";
req.Timeout = 1000;

// create an .X509 certificate and associated it with the
// HttpWebRequest object
// the certificate info we exported are stored in the file D:\MyCertificates.cer in this
// example

X509Certificate x509 =
X509Certificate.CreateFromCertFile( @"D:\MyCertificates.cer" );
req.ClientCertificates.Add( x509 );

// if we have data to post, set the request stream object
if( strData != null )
{
byte[] SomeBytes = null;
SomeBytes = Encoding.UTF8.GetBytes( strData );
req.ContentLength = SomeBytes.Length;
Stream newStream = req.GetRequestStream( );
newStream.Write( SomeBytes, 0, SomeBytes.Length );
newStream.Close( );
}
else
{
req.ContentLength = 0;
}

// get the response form the back end
WebResponse result = req.GetResponse( );

Stream ReceiveStream = result.GetResponseStream( );

Encoding encode = System.Text.Encoding.GetEncoding( "utf-8" );
StreamReader sr = new StreamReader( ReceiveStream, encode );

// unload the user profile and clean up the handel
ProfileManager.UnloadUserProfile (WindowsIdentity.GetCurrent().Token, profile.hProfile);
CloseHandle(dupeTokenHandle);

// return the result to the ASP.NET code or the client
return sr.ReadToEnd( );

}
catch( WebException ex )
{
return ex.Message;
}
catch( Exception ex )
{
return ex.Message;
}
}
}
}

CertPolicy.cs

using System;
using System.Net;
using System.Security.Cryptography.X509Certificates;

namespace NyNamespace
{
//Implement the ICertificatePolicy interface
class CertPolicy: ICertificatePolicy
{
public bool CheckValidationResult(ServicePoint srvPoint,
X509Certificate certificate, WebRequest request, int certificateProblem)
{
// you can do your own certificate checking here
// you can get the error values from WinError.h,
// all the certificate errors start with Cert_

// we just return true so any certificate will work with this sample
return true;
}
}
}

ProfileManager.cs

using System;
using System.Runtime.InteropServices;

namespace NyNamespace
{
internal class ProfileManager
{
[DllImport("Userenv.dll", SetLastError=true,
CharSet=System.Runtime.InteropServices.CharSet.Auto)]

internal static extern bool LoadUserProfile(IntPtr hToken,
ref PROFILEINFO lpProfileInfo);

[DllImport("Userenv.dll", SetLastError=true,
CharSet=System.Runtime.InteropServices.CharSet.Auto)]

internal static extern bool UnloadUserProfile( IntPtr hToken, IntPtr hProfile);

[StructLayout(LayoutKind.Sequential, CharSet=CharSet.Ansi)]
public struct PROFILEINFO
{
public int dwSize;
public int dwFlags;
public String lpUserName;
public String lpProfilePath;
public String lpDefaultPath;
public String lpServerName;
public String lpPolicyPath;
public IntPtr hProfile;
}
}
}

2003-11-02T16:33:00.000-06:00

ASP.NET & Client Certificates

ASP.NET v1.0 applications have a problem delivering a client certificate to a secure endpoint. While there are ways around this problem using .NET Enterprise Services (a.k.a. COM+ Services) the performance with the .NET Enterprise Services solution is less than ideal and the implementation has less to be desired. Microsoft has since come out with a fix that allow ASP.NET v1.0 to deliver the certificate Ckeck out the article. The performance with this solution is much better and the design is very simple. I have not tested ASP.NET v1.1 to see if the original problem still exists… stay tuned.

2003-11-02T16:08:00.000-06:00

PDC 2003

PDC 2003 was a blast. Microsoft for the first time publicly announced several products: Whidbey (the next version of Visual Studio .NET) and Longhorn (and http://www.longhornblogs.com/) (the next version of Windows). Within the Longhorn product there were four areas of interest: Avalon (a new UI interface), Indigo (a service oriented system for sending and processing messages), WinFS ( a new file system built on top of NTFS) and Yukon (the next version of SQL Server.

New C# Features.