Visual Studio HintPath

From Visual WebGui Wiki
Jump to: navigation, search
VWG 64+ The content of this article is valid for version 6.4 and later, including v7.x;



Visual Studio sometimes adds HintPath settings to project files to help locating some, but not all, of the assemblies referenced in the project. In some cases those HintPath settings are added as absolute paths, which may introduce strange problems later on, especially if the project is copied to another location and used from there, with the original project still available on the original location.

This article applies to Visual Studio 2005 and Visual Studio 2008. Not yet verified for Visual Studio 2010.


To understand the problem, the article will introduce a specific scenario, assuming that HintPath settings are added during the creation and building of the particular project in question. Please note that HintPath settings are not added in all environments, and at the time of this writing, it is not known which environment do suffer and which do not. See the Workarounds section for details on how to temporary fix and how you can prevent those hintpaths from being added.

Viewing or editing the project file

In the Scenario below, we will discuss editing and/or viewing a project file. The project file in VB.NET will be named YourProject.vbproj and in C# it will be YourProject.csproj. Remember that the project files are XML files. They can be edited or viewed outside of Visual Studio, but they can also be edited within Visual studion by following this procedure:

  • Right-Click the project in solution explorer and select "Unload project".
  • This will make the project inactive in solution explorer.
  • Right-Click the project again, while it is inactive, and select "Edit YourProject.ext" where ext is either vbproj or csproj.
  • This will open an XML editor in Visual studio.
  • If you need to search within the file, you can press Ctrl-F, but remember you will have to adjust the "Look in:" to be "Current document", otherwise it will not be searched.
  • When viewing/editing has been completed and changes saved, you close the XML file, Right-Click the project again and select "Reload project".

The scenario

Create a project - ProjectA

  • You are using a specific version of Visual WebGui, say 6.3.15.
  • You create a Visual WebGui project, ProjectA, in folder c:\Projects\ProjectA.
  • To pick one, let's say this is a VB.NET project. For C# project it's the exact same problem.
  • You add references to all the usual Gizmox assemblies and make sure all are set with Copy Local = True
  • You build and run your application and all is working normally.

Status after creating ProjectA

After creating ProjectA, and again assuming you do suffer from the HintPath problem, the contents of the project file, ProjectA.vbproj, have a new <ItemGroup> section added (see Viewing or editing the project file that might look somthing like the following section.

    <CustomReference Include="Gizmox.WebGUI.Forms">
    <CustomReference Include="Gizmox.WebGUI.Forms.Themes">

Pay special attention to how the HintPath settings are constructed, as absolute paths to ProjectA's bin folder.

Upgrade Visual WebGui version

  • You decide to test a new version of Visual WebGui, say version 6.4.0Beta3
  • You uninstall your current 6.3.15 and install version 6.4.0Beta3
  • You decide you don't want to risk corrupting ProjectA, so you make a copy of it to C:\Projects\ProjectB
  • You open ProjectB in Visual Studio and perform all the necessary procedures, uppering private version, rereference all assemblies etc.
  • You run ProjectB, and all you get is a lot of errors, many of which are reporting that types can not be loaded etc.

Is the new Visual WebGui version a complete disaster then?

Not at all. What has happened here is that you suffer badly from the HintPath problem.

Take a look at your project file and look for the HintPath settings within it, following the procedure in Viewing or editing the project file. What you will find here is that the same HintPath settings still exist within your project file, and by saying "same", I mean literally the same. Your ProjectB is still providing HintPaths to ProjectA's bin folder, meaning that it will try using the 6.3.15 assemblies in your 6.4.0Beta3 project. This will never work.

What can be done

There are two methods to work around this problem. For the Preventive one, you will most of the time have to use the Temporary workaround once for every project that does have HintPath settings, but after that, no HintPath sections will be added any more.

Temporary workaround

Use the Viewing or editing the project file above and search for "HintPath". Locate an <ItemGroup> section, like the one in the XML above. This will be an <ItemGroup> section that contains only <CustomReference> subsection with the HintPath settings. There might be other HintPath settings within the project file that do not appear within a <CustomReference> subsection, and they should be left alone. Usually there is only one <ItemGroup> that falls under these constraints, so there is no doubt what section is the one to locate.

When you have located that <ItemGroup> section, then simply delete it. You should delete the whole section, including the start <ItemGroup> and end </ItemGroup> tags. Then you can safe the project file and reload the project.

If you only use this temporary workaround, Visual Studio is likely to add this section again in your project file during the next build. That will be quite ok, as long as you don't make a copy of that project to another location, as described in the scenario of this article.

Preventive workaround

There is a switch in the Visual WebGui options which you will find in Tools, Options, Visual WebGui, General, "Copy theme assemblies to bin directory". This switch will be checked (active) by default in a new Visual WebGui installation. Unchecking that switch will make Visual Studio stop adding the HintPath settings to your project, but it will not remove existing ones, so you still have to check and possibly apply the Temporary workaround above.

This switch is a Visual Studio global switch and not a project setting, so it will hold it's position through reloads of Visual Studio and opening of other projects.

VWG reference The following section is a reference only section;


Other references