Andru's WebLog : NETFX3

Adding a database project reference (DBPro) to a WIX 3.0 project

andresv — Tue, 17 Jul 2007 18:03:00 GMT

I'm building some installers for the project currently working on, and because we use TFS and Team Build I wanted to have the ability of creating MSI packages from the build script run at the build server.

Unfortunately MSBUILD doesn't natively support Visual Studio Setup projects so they won't compile your nice MSI setup packages out of the box. Of course you can just modify the MSBUILD script to add an EXEC task to run VS2005 in order to build the setup project, but that requires splitting the original solution (or creating a new one just for compiling the setup project) and this new setup project can't contain references to projects (all references must be changed into binary references).

For those reasons I explored WIX, the new (and open source) Windows Installer for Xml project from Microsoft, published in SourceForge and found in the Url http://wix.sourceforge.net/

I started with WIX 3.0 because it fully supports MSBUILD, but the version I downloaded had some serious drawbacks (it lacked support for Votive project variables, for example) and that was a show stopper for me. I also tried the stable WIX 2.0 release, but the lack of MSBUILD support and some other bugs (like no support for dots in project names) was also a show stopper for me. After some time I download the latest (unstable) version of WIX 3.0 (build 3.0.3106.0) and everything worked like a charm. Integration with MSBUILD was beautiful, Votive project variables were supported again and even the dots in the project names works as expected!

I started to code the installer and I wanted to include some SQL scripts to create some databases on install, and I wanted to automate this as much as possible. I have some VS2005 DBpro database projects and wanted to include the output scripts from those projects into my WIX project. The first version just referenced the SQL files from the projects and compiled just fine in my desktop machine, but failed miserably when compiled on the build server because the output paths are very different (Team Build just copies all output from compiled projects in the DROP folder defined in the build script, and don't use the output folder defined in the source projects).

So, the solution was to include a project reference in the WIX project to the DbPro projects, and later use those project variables to include the output script files in the setup package. So far, so good.... except that Visual Studio won't let you add this kind of project reference! If you try that you will get a nice dialog with an "Object Reference Not Set" error message. Not very helpful....

The solution is to add manually those references by editing the source WIX project file. You can do that by unloading the project in Visual Studio (right click on the project and select "Unload Project") and then right click again on the unloaded project and select the "Edit" option from the context menu. You can always use the good old notepad to do this, but the Visual Studio way is easier (and cooler...). After editing the source project file you can test everything by reloading the project (right click and click the "Reload Project" menu item).

Inside the WIX project file, near the end of the file (and inside the "ItemGroup" xml tag) you must add something like:

<ProjectReference Include="..\..\..\Databases\Workflow.Persistence\Persistence.dbproj">
<Name>Workflow.Persistence</Name>
<Project>{7b9401a5-5922-49ed-80ed-1d163f0036dd}</Project>
<Private>True</Private>
</ProjectReference>

Inside the <Project> xml tag you must type the project GUID you want to reference, and this project GUID can be found inside the project being references itself. In this case, I must open the "Persistence.dbproj" file and look for the "ProjectGuid" xml tag:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Default</Configuration>
    <Name>"DatabaseProject"</Name>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{4d8e8950-2bf5-4315-a539-ac80f7959187}</ProjectGuid>
    <ShowWizard>True</ShowWizard>
    <OutputType>Database</OutputType>
    <DBProduct>SQL Server 2005</DBProduct>

After that, you should have those nice database project references in your WIX project, like this:

Later, in the WIX setup script you can reference the output of those projects like this:

As you can see, I'm adding a binary file to the setup package using the "TargetDir" variable for the referenced project. Isn't that nice?

Usign the cool WIX "SqlExtension" I can very easily include and run those database scripts when installing my project, but that's for another post.

Andrés G Vettori
MCSE/MCSD/MCT
EDS Top Gun - .NET Capability Architect

Leader of the C# Community of the Microsoft Users Group Argentina

WCF Extensibility - Part 2

andresv — Mon, 23 Oct 2006 16:05:00 GMT

Service Description

Figure 2. ServiceDescription at runtime

The Service Description is the heart of the service and is created when a ServiceHost or client ChannelFactory is created to describe all aspects of the service, endpoints and behaviors. This description is a logical view of what the WCF runtime is going to build when the Open method on the ServiceHost is executed, and also is used to generate the WSDL and policy metadata for the service. This metadata is exposed through the ServiceDescription class and the Description property on the ServiceHost and can be changed, for example, by injecting behaviors. To build the ServiceDescription information the WCF runtime first reflects over the service types and then it loads the service configuration. This information is then used when you execute the Open method of the ServiceHost to build the runtime.

In the code shown below you can see how the service description information could be accessed and modified:

// Construct the ServiceHost
ServiceHost host = new ServiceHost(typeof(EchoService), new Uri(“http://localhost/echo”) );
// Add endpoints to description
host.AddServiceEndpoint(typeof(IEchoService), new BasicHttpBinding(), “”);
// You can access the Description property of the host
Console.Writeline(host.Description.ServiceType);
// And you can change things before calling Open
foreach( ServiceEndpoint endpoint in host.Description.Endpoints )
{
         // Add My behavior to all Http endpoints
         If( endpoint.Uri.Scheme == “http” )
                 endpoint.Behaviors.Add( new MyHttpBehavior() );
}
// Open the Host
Host.Open();

Next post: Building a Custom ServiceHost

Enjoy!

Andrés G Vettori
MCSE/MCSD/MCT
EDS Top Gun - .NET Capability Architect

Leader of the C# Community of the Microsoft Users Group Argentina

WCF Extensibility - Part 1

andresv — Fri, 20 Oct 2006 18:12:00 GMT

What we have in WCF

WCF has a design that clearly shows a very hard work of many talented people for a long time, and that kind of effort can only be a good thing.

The first thing you note when start working with WCF is the simplicity of the programming model, a thing that COM+ and Enterprise Services was very good at providing some interesting programming models, like declarative programming using attributes, that WCF tried to incorporate.

After that first impression you start digging a little more into the WCF inner workings and you note that it has all the flexibility and extensibility of WSE and Remoting, and then some more, and also supports the communication style of Remoting (although the WCF team doesn't want to encourage its use) side by side with the full Service Orientation support.

As WCF really is the unification of all previous communication technologies and development paradigms for application and integration scenarios, we can expect to find a more complex architecture underneath, and as I said before it can be a little intimidating when you start looking into all those interfaces and options for extensibility.

Figure 1. WCF Architecture

As we can see in the simplified architecture diagram shown above, WCF has two main layers where extensibility can be applied and the first decision you have to make is at what layer you need to apply the extensibility you need:

Customizations at the service model level: this is the higher level of abstraction in WCF and they apply to the higher level constructs like service, contracts and operations. Most common customizations are made at this level and they relate to the fact that you can change the local behavior of any of those service constructs.
Customizations at the messaging level: this is the lower level of the WCF infrastructure where you have protocols and transport channels. In this layer the message is serialized and transmitted using the selected transport, also protocol rules are applied (like reliable messaging) and security (like encryption). Customizations here are needed when you need to modify "what's on the wire".

Other extensibility points beyond these two include Bindings, Security, Metadata, Serializers and Hosting but they are somewhat less common in typical applications.

The three ways of customizing the service layer include:

Manipulate the Service Description.
Injecting Behaviors by hand.
Overriding ServiceHost / ChannelFactory<T>.

We are going to dive into these three customization methods in the next posts.

Next post: WCF Service Description Layer

Enjoy!

Andrés G Vettori
MCSE/MCSD/MCT
EDS Top Gun - .NET Capability Architect

Leader of the C# Community of the Microsoft Users Group Argentina

Understanding WCF Extensibility

andresv — Thu, 19 Oct 2006 20:15:00 GMT

I have written a white paper on WCF extensibility and I would like to share it with the community so I have attached a copy to this post in Word 2003 format.

Enjoy!

Andrés G Vettori
MCSE/MCSD/MCT
EDS Top Gun - .NET Capability Architect

Leader of the C# Community of the Microsoft Users Group Argentina

WS-Compression, WCF and Named Pipes

andresv — Thu, 12 Oct 2006 21:37:00 GMT

I found the WCF version of the WSE3 compression filters on the Pablo Cribaro's blog where he published an updated WCF RC1 version.

This code was first released by Morty for WSE2. At that time we (Rodolfo Finochieti and I) make some improvements to that code, and later Rodolfo migrated this code to WSE3. Is very interesting how the community works....

The thing is the WCF version was having problems when used over a Named Pipes transport, so I decided to take some time and discovered some interesting behavior.

The problem occured in the ReadXml method of the CompressionMethod.cs class, and only fails when using TCP or NamedPipes, not on Http. So after doing some debugging I found that in the case of the Http transport, when the Xml Reader was reading an XmlNode with attributes it first reads the StartElement and after that an EndElement. This behavior changes when you are using Named Pipes and after reading the XmlNode that has some attributes, the reader skips the EndNode completely and positions itself on the nect XmlNode.

I first made a quick fix just by asking the XmlReader if the next node was an EndElement before trying to execute a ReadEndElement, but it seems too much as a hack so I tryied another approach.

In the attached file I publish an updated version of the compression library for WCF (for RC1) and modified the CompressionMethod.cs so it doesn't use attributes anymore, and in that way it works as expected regarding the transport being used.

If you ask me it looks like a bug on the XmlReader, because both messages was exactly the same (checked with trace) and this different behavior is totally unexpected.

I found other bug related to the use of Request/Reply channels with void contract methods. In that case a NULL message was sent back as response and therefore the code fails. On the CompressionInterceptor.cs class I have to check if the passed message was equal to null in the Compress and Decompress methods, and everything works as expected now.

Enjoy!

Andrés G Vettori
MCSE/MCSD/MCT
EDS Top Gun - .NET Capability Architect

Leader of the C# Community of the Microsoft Users Group Argentina