Visual Studio: default build action for non-default file-types

July 2, 2010 at 11:12 AMAndre Loker

With a simple file you can tell Visual Studio to use a certain default Build Action for specific file types. This reduces the chance of missing files on the server when using the built-in publishing functionality. 


Updated: if you don’t feel like hacking pkgdef files manually, check out my little helper tool at

For each file in the solution you can define a build action by selecting the file and choosing the appropriate “Build Action” in the properties window.

The build action defines how Visual Studio handles the file when building and publishing the solution. For example, the default build action for C# source file is “Compile”. Files that have no special meaning for Visual Studio get the build action “None” by default, telling VS to basically ignore the file and just leave it as is.

In an ASP.NET MVC project that uses a view engine different from the default one (such as Spark or Brail) one will frequently add such “meaningless” files to the solution, namely the view files: .spark, .brail, .brailjs etc.

Publishing in Visual Studio

This section only provides the context of this article. You may skip it if you know about publishing.

deploy Visual Studio offers a nice publishing function that makes publishing applications rather easy (Build -> Publish). The Web Deploy method is pretty cool, because it can deploy the project to a remote web server with one button click.

The publishing functionality can be configured in the project properties, tabs Package/Publish Web (and Package/Publish SQL for that matter).

One essential option is the choice of the “Items to deploy”. There are three choices: “Only files needed to run this application”, “All files in the project” and All files in the project folder. “All files in the project directory” publishes, well, all files in the directory where the project files lives and all subdirectories. “All files in the project” only deploys files that are part of the solution, that is, all files shown in the solution explorer (with “Show All Files” off, of course), plus the build results. publishAs a result, this will copy among other things all source files to the web server. It is not much of a security problem, because by default IIS is configured to not serve those files at all. Still, I don’t see the need to publish unnecessary files. That’s where the first option comes in: “Only files needed to run this application”. It basically deploys all compilation results and all files with the “Content” Build Action defined. For many file types, VS sets the Build Action to Content by default, for example .css, .js and .config files. For “unknown” file types, such as .spark or .brail, the Build Action is “None”. As a result, those files are not deployed to the server on publish with the “Only files needed to run this application” setting on. Of course, you can change the Build Action for each and every file, but it is a tedious task and can easily be forgotten, causing missing files on the server. Luckily, you can tell Visual Studio to use a different default Build Action for any file type.

Changing the default Build Action for a file-type

The default build action of a file type can be configured in the registry. However, instead of hacking the registry manually, we use a much better approach: pkgdef files (a good article about pkgdef files). In essence, pkdef are configuration files similar to .reg files that define registry keys and values that are automatically merged into the correct location in the real registry. If the pkgfile is removed, the changes are automatically undone. Thus, you can safely modify the registry without the danger of breaking anything – or at least, it’s easy to undo the damage.

Finally, here’s an example of how to change the default build action of a file type:

   1: [$RootKey$\Projects\{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}\FileExtensions\.spark]
   2: "DefaultBuildAction"="Content"

The Guid in the key refers to project type. In this case, “{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}” means “C# projects”. A rather comprehensive list of project type guids can be found here. Although it does not cover Visual Studio 2010 explicitly, the Guids apply to the current version as well. By the way, we can use C# as the project type here, because C# based MVC projects are in fact C# projects (and web application projects). For Visual Basic, you’d use “{F184B08F-C81C-45F6-A57F-5ABD9991F28F}” instead.

$RootKey$ is in abstraction of the real registry key that Visual Studio stores the configuration under: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config (Note: Do not try to manually edit anything under this key as it can be overwritten at any time by Visual Studio).

The rest should be self explanatory: this option sets the default build action of .spark files to “Content”, so those files are included in the publishing process.

All you need to do now is to put this piece of text into a file with the extension pkgdef, put it somewhere under %PROGRAMFILES(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\Extensions (on 64-bit systems) or %PROGRAMFILES(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\Extensions (on 32-bit systems) and Visual Studio will load and apply the settings automatically the next time it starts. To undo the changes, simply remove the files.

Finally, I’ve attached a bunch of pkgdef files that are use in production that define the “Content” default Build Action for C# and VB projects for .spark, .brail, .brailjs and .less files respectively. Download them, save them somewhere in the Extensions folder and you’re good to go.

brail - Content.pkgdef (528.00 bytes)

brailjs - Content.pkgdef (534.00 bytes)

less - Content.pkgdef (525.00 bytes)

spark - Content.pkgdef (528.00 bytes)

Posted in: Visual Studio

Tags: , , ,

Speed up Firefox when using Development Server

June 18, 2008 at 1:17 PMAndre Loker

The problem

Using Firefox on Vista to view websites hosted by the Visual Studio Development Server can be unbearably slow. Pages take aeons (i.e. several seconds) to load while viewing the same site under IE does not suffer from this issue.

The solution

As mentioned in this blog post, this problem can be solved like this:

  1. Open the Firefox config (browse to about:config)
  2. Locate the setting: network.dns.disableIPv6 (type "v6" into the filter field)
  3. Change the value to true (double click the row)

The result

Now sites on the built in development server work fast even under Firefox and Vista.

The conclusion

What can I say - it works :-)

Update 06/19/2008: works with Firefox 3 as well

Posted in: ASP.NET

Tags: ,

VS web app: System.Runtime.InteropServices.COMException

April 28, 2008 at 10:41 AMAndre Loker


Two minutes ago I opened a solution in VS 2008 that contained a web app project. An error message box popped up saying "System.Runtime.InteropServices.COMException". The web app project was not loaded and could not be reloaded afterwards, either. I was slightly confused because I had worked on the project successfully yesterday.

Then I realized what has changed since the last time I ran VS: yesterday I had opened the solution in a VS instance that ran under the administrator account. I had then changed the web app’s properties to let it use IIS instead of the internal web server. Opening the modified solution in a non-privileged instance of VS today caused the error. After undoing the web properties in a privileged Visual Studio instance the project loaded correctly in the non-privileged instance as well.

Posted in: Visual Studio

Tags: ,

Web Deployment Projects in Visual Studio 2008

April 14, 2008 at 10:27 PMAndre Loker

Seit kurzem hatte ich das Problem, dass beim Öffnen von Projektmappen, die ein oder mehrere Web Deployment Projects enthielten, jedes Mal der Conversion Wizard von Visual Studio erschien, um das Projekt in das "aktuelle" Format zu übertragen.

Offensichtlich war ich damit nicht alleine, wie aus den Kommentaren der WDP Ankündigung zu lesen war. Glücklicherweise bot Vishal R. Joshi an, auf Anfrage per Mail eine gepatchte DLL zu versenden, mit der das Problem behoben werden sollte. Gesagt, getan. Innerhalb weniger Stunden erhielt ich eine freundliche Mail von Herrn Joshi inklusive der DLL. Mit letzterer brauchte nur noch die ältere Version in %Program Files%\Microsoft Visual Studio 9.0\Common7\Packages überschrieben werden. Und siehe da: der Conversion Wizard erscheint nicht mehr.

Vielen Dank an Vishal R. Joshi für seine schnelle und freundliche Unterstützung. Vermutlich wird eine Lösung für das Problem kurzfristig auch offiziell veröffentlicht. Laut Mr Joshi gibt es zurzeit lediglich noch einige logistische Verzögerungen.

Posted in: Tools | Visual Studio

Tags: ,