Nicolas Moreau's Blog

Deploying Web Application Projects

Web Application Projects (WAP) are a great feature that has been in the field for a while, but which will progressively appear more and more due to its presence in Visual Studio 2005 SP1.

Recently, I had to automate the deployment of a WAP.

To my surprise, there is not easy way to do it in a clean manner.

Publish Wizard in Visual Studio 2005 is great : It copies only the necessary files.

But How Achieve the same Results with Command Line Scripts ? No so straightforward.

Web Deployment Projects (WDP) were the immediate Answer.

Unfortunately, have a limitation of WDP with WAP : the Deployed project contains useless file that should NOT appear in the published location; such as *.csproj, *.csproj.user, *.sln.

Even if you loose the opportunity to precompile the site (remove code in aspx files), merge assemblies, (…) , it appeared to me as a better option not to use WDP.

What is the solution then ?

The solution is to use a "Hidden" target of WebApplication Target.

The target file is located at :

C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets

This file contains the definition of the Target available with WebApplication Project.

_CopyWebApplication enables to copy the WebSite in specific location.

Yet another limitation comes : referenced Dll within the WAP are not copies in the target Bin directory.

A workaround is to

1. Compile the site

msbuild WebApplication1.csproj /p:Configuration=Release

2. Copy all assemblies in the target Bin directory

Robocopy.exe bin\ ..\_PublishedWebsites\WebApplication1\bin\ XF *.dll

3. Call the _CopyWebApplication target

msbuild WebApplication1.csproj /target:_CopyWebApplication /property:OutDir=..\ /p:Configuration=Release

You finaly end up with the compiled site, with all and only what you need.

Structuring Solutions & Projects in Team Foundation Server

Team Foundation Server is a great Product.

No matter how great it is, the same questions do arise on any large scale development project I face, with any SCM & Build tool :

• How to manage dependencies between teams?
• How to deal with versioning and versions dependencies ?

Here are some simple rules & trick that we found appropriate to use with TFS:

• Dependencies within VS Projects in a Solution are “Project Dependencies”
• Dependencies between VS Projects within different Solutions within the same Team Project are Binaries Dependencies handled with an M:  Drive (subst) that points to a local Binary Repository.
• Build Configuration within a Team Project deal manually with the build order.
• Dependencies between Projects within different Team Projects are Binaries Dependencies (Same with M drive).

Developers have an M: Drive mapped to a local copy of the repository.

Most dependencies reference the LATEST version (except in some cases where the explicitly reference a Released version ex : 1.0)

Developers work with their local copy. When the version is stable, that can update their local Repo with a script from the repository (robocopy), an build again ( with the latest build assemblies).

Comments on this are more than welcome.

Calling WebServices from a VB6 Application

I recently faced a situation in which a customer had to interoperate between a Visual Basic 6 application and existing WebServices. Interesting challenge, with many different options.

The following direction were foreseen as follows :

1. Use XMLHTTP an code SOAP call and serialization by hand
2. Using SOAP Toolkit : it is deprecated by the Framework .NET and support policy sticks to the issue of the Extended Support lasting until March 31, 2008
3. Using .NET assemblies on the client called by VB6 components through COM Interop, thus leveraging the ability of .NET to easily deal with WebServices (Proxy generation, Serialization)
4. Using Liquid XML http://www.liquid-technologies.com/default.aspx

A solution that "mimics" VB6/COM world what VS & .NET do : class generation & handling serialization

Finaly an interesting alternative was seen. The existing applicaiton was already using a COM+ middle tier. So the solution used was the following ;

5. Use a COM+ .NET Enterprise Services Middle tier component that
1. Make the WebService call
2. Deserialize the objets into .NET Structs
3. Pass by value the objects back to the VB6 Client using DCOM, and marshalling the Struct byValue.

And it works !

Interesting integration Pattern to reuse to call WebServices from a VB6 Application that cannot sustain .NET framework on the client station.