memory.Refresh()

Microsoft’s Brad Abrams and Somasegar both posted about a set of standard Microsoft icons that ship with Visual Studio 2005. They can be found in a zip file in the Visual Studio 2005 installation directory (usually C:\Program Files\Microsoft Visual Studio 8\Common7\VS2005ImageLibrary\VS2005ImageLibrary.zip). There are over 600 icons in total with a mixture of Windows, Office and Visual Studio icons, and are licenced for reuse in your own applications.

I’ve recently been doing some work in Visual Studio 2005 which consisted of several projects in a single solution that I’d converted from Visual Studio 2003 format. Since the AssemblyKeyFile attribute has been deprecated, I began to add the shared strong name key to each project using the project properties view. The problem with this is that it copies the strong name key file to each project directory, making a shared key a bit pointless. This behaviour doesn’t happen (as explained in more detail by Shawnfa) if the strong name key file is added to the project as a linked item before setting it in the project properties view. This leaves a single strong name key file on disk, but still includes it in each project as with Visual Studio 2003’s AssemblyKeyFile attribute.

After trying to modify unique index names on tables in a database using the INFORMATION_SCHEMA views and getting nowhere fast, I delved into the system tables to see if they would shed any light on how to do it. This was even more confusing as it’s not obvious how these tables fit together. If only there was a map of the relationships between the system tables. Well, there is - Microsoft helpfully supply one on their SQL Server website. Very useful.

Using Visual Studio 2005 today, I received a “407 Proxy Authentication Required” message when trying to search the online help integrated into the IDE. KB910804 from Microsoft held the answer.

In order to allow VS2005 through an authenticating proxy, you have to edit the Visual Studio configuration file located at C:\Program Files\Common Files\Microsoft Shared\Help 8\dexplore.exe.config. To add support for the proxy, make sure the proxy element is present:

<configuration>
    ...
    <system.net>
        ...
        <defaultProxy enabled="true" useDefaultCredentials="true">
            <proxy bypassOnLocal="True"
                   proxyAddress="http://yourproxy:port"/>
        </defaultProxy>
    </system.net>
</configuration>

where the correct proxy server is configured in the proxyaddress element.

If you use the integrated help viewer, you must also add this xml to the configuration file located at C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe.config.

Whilst trying to work out why some code was running very slowly (see System.Diagnostics.Process and speed), I tried to see whether the slowness was caused by loading code contained in a separate dll. To get this information, I needed to look at the fusion logs. Configuring these logs is not fool-proof, so having spent a few hours getting it working, I thought I’d document the process.

Suzanne Cook’s blog was quite useful, as was the Assembly Binding Log Viewer article on MSDN, but neither of them contained exactly what was needed.

To set up the fusion logs ready for viewing, some entries need to be added to the registry in the HKEY_LOCAL_MACHINE\Software\Microsoft\Fusion key. The combination needed depends on what you’re trying to inspect. The keys are:

• LogFailures = 1 (DWORD Value)
  This turns on failure logging so that failed attempts to locate all assemblies are logged.

• LogResourceBinds = 1 (DWORD Value)
  This turns on failure logging so that failed attempts to locate satellite assemblies are logged. This is not logged by default.

• ForceLog = 1 (DWORD Value)
  This turns on logging for all assembly binds - both failures and successes. By default, only failures are logged. This is useful if you want to verify that an assembly is loading from a specific directory instead of from the global assembly cache.

• LogPath = “C:\fusionlogs" (String Value)
  If you want to view the fusion logs easily, set the LogPath to a directory to output them to. By default the log files go into the Temporary Internet Files folder of the current user’s profile. For an ASP.Net or a .Net Windows service application, the only way to view the fusion log is to use this option. This is because they run as users other than the current user. The directory specified must already exist and have appropriate file permissions to be written to. For ASP.Net applications, the ASPNET user must have write permission to the directory. If the permissions are wrong, there will be no log output.

Once you have configured the relevant logging options, running the .Net application will generation the fusion logs. Once generated, the logs can be viewed using the fuslogvw.exe tool that comes as part of the framework SDK (mine was inside the SDK folder inside Visual Studio’s installation folder). I found that either the 1.1 or 2.0 version will work, but the 2.0 version is a little better as it has a few more options in the GUI:

To view a specific log, choose it from the main section and click the view log button. The log will open in an internet browser showing the assembly binding details.