Visual Studio slow? Try disabling hardware acceleration.

Ever since I got a new computer I’ve been frustrated by how slow Visual Studio 2013 has been. Granted, the computer is a little weak performance-wise, it’s of the Ultrabook type, but it’s been slow even at basic tasks such as moving the cursor around. Really strange.

But after a tip from an article at Code Project I decided to disable hardware acceleration:

Disable hardware acceleration in Visual Studio 2013

Disable hardware acceleration in Visual Studio 2013

And what do you know, it worked! Moving around with the cursor keys in source code is now much more responsive and no longer a source of frustration. Oh joy!


Exclude files and folders from Web Deployment projects

Getting a lot of garbage when compiling web deployment projects? Don’t worry, there’s an easy remedy!

This is how to do it (using Visual Studio):

  1. Check out the web deployment project.
  2. Right-click the deployment project in the Solution Explorer and select “Open Project File”. The project file will be opened in the built-in Xml editor.
  3. Insert Xml code similar to the following last in the file, just before the end tag for the Project element:
        <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\obj\**\*.*"/>
        <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\Properties\**\*.*"/>
        <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\*.csproj*"/>
        <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\*.resx"/>
        <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\*.Publish.xml"/>
  4. After this change, all files matching the wildcard expressions given in ExcludeFromBuild elements will be excluded. Problem fixed!

Good luck deploying!

Update: The double asterisks means that the path matching is done recursively in the file system. For example, to exclude everything from the “obj\” folder we have to use “obj\**\*.*” since “obj\*.*” only matches files placed directly in the folder. Files in sub-folders would not be excluded if we used that pattern.


Conditional Visual Studio build event scripts

In some projects there’s a need for manual operations after compilation. It might be to copy files, sign code or whatever. Of course it would be great to make these operations automatic, and that’s what build event scripts in Visual Studio are for.

Basically a build event script is a BAT file with some variables that are replace by Visual Studio when executing it. You create a build event script in the Properties dialog box of the project and here’s an example of what it may look like (in this case we package a set of files from the project into a Zip archive used for deploying the application):

REM If Debug config, do nothing...
if $(ConfigurationName) == Debug then goto endif

mkdir $(TargetDir)Imports\
mkdir $(TargetDir)Reports\
mkdir $(TargetDir)Faktureringsunderlag\

del /F /Q $(TargetDir)Imports\*.*
del /F /Q $(TargetDir)Reports\*.*
del /F /Q $(TargetDir)Faktureringsunderlag\*.*

copy /Y $(ProjectDir)Imports\*.xlt $(TargetDir)Imports\
copy /Y $(ProjectDir)Reports\*.rpt $(TargetDir)Reports\
copy /Y $(ProjectDir)Faktureringsunderlag\*.xlt $(TargetDir)Faktureringsunderlag\

REM Create Zip archive
del /Q

$(SolutionDir)Utils\7z.exe a Faktureringsunderlag Imports Reports
ErrorHandler.dll janus*.dll Microsoft.ApplicationBlocks.Data.dll new_*.dll
new_SFIStarter.exe SFI*.dll Svea.exe Svea.exe.config


The example illustrates several points:

  • The operations are conditional, i.e. are not done in Debug compilation. There’s no point it taking that time if we’re about to deploy the application.
  • It makes sense to use options for the respective tool to disable prompting (e.g. “Are you sure you want to delete XXX”) since we’ll never be able to answer.
  • Any command line utility can be used. In this case I have downloaded the great 7-Zip util and copied it’s binaries into the solution so that it’s always available on every developer’s computer.

Kind of useful, ain’t it? Of course, there are other ways of doing this, e.g. using MSBuild, but I find this method easy to understand and manage.

Refresh Visual Studio Add-in settings

Here are some steps to try if you’re having problems with addins in Visual Studio (for example if toolbars or menus have vanished, or have been duplicated).

First, close all Visual Studio instances.

Then open a command line console with Visual Studio settings (e.g. “Visual Studio 2005 Command Prompt” from the start menu) and type:

devenv /resetaddin *

That line will clear the settings for all addins and cause them to refresh menus and toolbars the next time Visual Studio is started. To do that with an individual add-in, which requires knowing its class name, including namespace, type

devenv /resetaddin CodeAssist.Connect

If the above does not help, then try this (NOTE: This will delete all customization done to Visual Studio, such as keyboard mappings, etc!):

devenv /resetsettings
devenv /resetaddin *

When starting Visual Studio, you should now face a fresh and clean environment.

Get IWin32Window for the main window of Visual Studio

This is a way to wrap the main window of Visual Studio in a klass that implements the IWin32Window interface.

Public Class MainWinWrapper
    Implements System.Windows.Forms.IWin32Window
    Overridable ReadOnly Property Handle() As System.IntPtr _
            Implements System.Windows.Forms.IWin32Window.Handle
            Dim iptr As New System.IntPtr(DTE.MainWindow.HWnd)
            Return iptr
        End Get
    End Property
End Class

This is useful for example when Visual Studio should be used as the owner of a MessageBox.

Dim res As DialogResult
res = MessageBox.Show(New MainWinWrapper(), "Hello!")

The code was found here.

Auto-expanding custom (and standard) types in the watch window

The default for complex types is to just display the type name in the debugger’s watch window. Some system types however display the values of one or more properties instead of the type name. What is displayed is configurable which also makes it possible to show more information about user-defined types. This is how it’s done:

  1. Edit C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Packages\Debugger\mcee_cs.dat for C#, mcee_mc.dat for managed C++, vjsee.dat for J#. Sorry, no VB!
  2. Add/modify rows in the file. Each row describes how a type should be displayed. Example:
    &lt;System.DateTime&gt;=&lt;Year&gt;-&lt;Month&gt;-&lt;Day&gt; &lt;Hour&gt;:&lt;Minute&gt;:&lt;Second&gt;
  3. The first part is the type name, followed by ‘=’. The rest of the line contains property names surrounded with ‘< ' and '>‘, mixed with fixed text that is displayed as it is.

The example above will display DateTime values as "{2005-4-23 16:2:51}".

In addition to property names, one can also use expressions and method names.