Installing WCF Service via MSI using “publish” Visual Studio output

Question

I am working on a WCF service, which is published via an MSI package to an IIS website. The problem I have is more of an annoyance than anything, but I'd still like a way around it if possible.

Whilst we are creating the service, we publish it to our development server by means of right-clicking on the service host and selecting "Publish Website". When we do this, the following folder structure is installed:

• apsnet_client
• bin

Within the bin directory (along with the DLL files referring to the service), I have a DLL file named App_Code.dll , which contains a compiled version of my Service.cs file, which contains the actual service code.

Obviously we can't use Visual Studio deploy to go onto a live environment, so I've created an MSI package to install it. The MSI simply has content files from my service host and nothing else.

When the MSI is installing the required files, the directory structure is a little different. Instead of there being an App_Code.dll file, it simply creates an App_Code directory within the website and puts the Service.cs file within there. This works and I can access the service, but I'm really not overly keen on having the service instantiating code just sitting there for anyone with access to the server to change.

So basically what I need to do is to include the output of the website publish in my MSI package so that I will get the precompiled App_Code - is there a way to do this? In my solution there is no option to set the Service.cs file to be compiled, so there must be another way to do it.

Thanks.

Answer 1

In my build process, I use the WebDeploy infrastructure to create a pubxml file that uses the FileSystem WebPublishMethod to deploy to a relative directory that I'll call "Deploy". This models the website exactly the way it was intended. I then author my MSI around that structure and add in the IIS Metadata.

I'm not sure what MSI authoring tool you are using but I like to use Windows Installer XML and/or InstallShield. I say and/or because I'll frequently use WiX and IsWiX to create a merge module to express the contents of the site and then use InstallShield Limited Edition to describe the IIS Metadata.