My Vista IIS 7 box recently stopped listening on the localhost ip addresses for no apparent reason.  I don’t know how this happened but I eventually found the solution.

I ran across the following command line that lists all the ip addresses that IIS is listening on (but I'm not sure how this differs from the IIS web site bindings):

netsh http show iplisten

This showed one ip address, which was my machine's ip address.

I ran this command on another vista pc that was working and it returned an empty list.

I then ran the following command line to remove the rouge ip address from the list:

netsh http delete iplisten ipaddress=192.1.1.123

Once I removed the ip address so the list was empty (which is what I have on another vista machine for comparison), localhost started working again.

FYI: This also applied to .NET WCF endpoints.

I believe the httpcfg command can do the same in older Windows OS versions.

Although there is a relative Reference HintPath in the .csproj file, when you move a solution to a different machine, the hint path may not be correct for that machine.  An easy way to get around this problem is to just ensure that your needed assembly is in the Public Assemblies folder: Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies.  Of course this should really only be done when you don't make any changes to the referenced assembly, such as a 3rd party dll.

A good summary: http://blogs.msdn.com/manishagarwal/archive/2005/09/28/474769.aspx

From: http://msdn2.microsoft.com/en-us/library/8y13ka7c(VS.80).aspx

When the project system finds an assembly reference, it resolves the reference by looking in the following locations, in the following order:

1. The project directory. The project directory files appear in Solution Explorer when Show All Files is not in effect.
2. Directories specified in this dialog box.
3. Directories displaying files in the Add Reference Dialog Box.
4. The project's obj directory. (Any assemblies created as a result of adding a COM reference to your project are added to the project's obj directory.)

From: http://msdn2.microsoft.com/en-us/library/wkze6zky(VS.80).aspx

To display an assembly in the Add Reference dialog box

* Move or copy the assembly to one of the following locations:

o The current project directory (you can find these assemblies using the Browse tab).
o Other project directories within the same solution (you can find these assemblies using the Projects tab).
o The Public Assemblies folder: Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies; (you can find these assemblies on the .NET tab).

* Set a reference path to the directory containing the assembly using the Reference Paths Dialog Box (Visual Basic) or the Reference Paths Page, Project Designer (C#, J#).
* Set a registry key that specifies the location of assemblies to display (This works with MSBUILD):

Add one of the following registry keys, where <AssemblyLocation> is the directory of the assemblies that you want to appear in the Add Reference dialog box, for example, C:\MyAssemblies\.

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"

Basically the AssemblyFoldersEx key can have lots of subkeys.  The subkeys can have any name.

I seem to forget the ASP.NET tracing page name occasionally, so here it is if I forget again:

trace.axd

Here's more detailed information:  ASP.NET Tracing Overview

Wondering how the different .NET versions really fit together?  Scott Hanselman gives a good rundown in his How to set an IIS Application or AppPool to use ASP.NET 3.5 rather than 2.0 article.

Reading and Writing unicode strings to and from a Unicode Oracle database can be seem tricky and there isn't much information available on the subject.  The solution is actually fairly simple, just make sure you are using the proper connection string.

ADO.NET: This is simple, using the OracleClient ensure that the connection string has: Unicode=true

Example: Data Source=ds;User ID=username;Password=pass1;Unicode=true;

ADO (VB6): In short the only 100% compatible solution is to use the ADO OraOleDB.Oracle data provider.

Example: Provider=ORAOLEDB.ORACLE;Data Source=ds;User Id=username;Password=password;

It also seems that the East Asian language files must be installed when writing those characters (at least with ADO).  This is done from the Regional and Language Option control panel, Languages tab.

When using parameters (at least with ADO) if not using a DSN connection (which you can't really if using unicode), the appropriate parameter properties must be set manually (such as size), otherwise the following error occurs: Run-time error '-2147217839 (80040e51)  Provider cannot derive parameter information and SetParameterInfo has not been called.

The grid below shows my test results from a VB6 application using ADO.

Actual 2 Japanese chars written: "とら" which has unicode values of 12392 and 12425.

Oracle 10g AL32UTF8 database.

write method  vb shows in      read     read char 1    readchar 2        actual value stored
              debug window     length   unicode value  unicode value     in the database

MSDAORA: Provider=msdaora;Data Source=ds;User Id=username;Password=password;
FROM SQL:     ‚Æ‚ç             2        12392          12425             ‚Æ‚ç  (4 characters)
FROM PARARMS: ‚Æ‚ç             2        12392          12425             ‚Æ‚ç  (4 characters)
PRESAVED:     ¿¿               2        -129           -129              とら
Conclusion: Reads and writes each encoded byte as separate characters, so the database ends up storing 4 characters in this case instead of 2.  Reading is consistent with writing so the resulting read value is actually correct in memory, but the stored database value is incorrectly stored.  Reading a properly stored unicode string from the database results in a corrupt read value.

DSN (Force SQL_WCHAR Support checked): dsn=dsnname;uid=username;pwd=password
FROM SQL:     ??               2        191            191               ¿¿
FROM PARARMS: ‚Æ‚ç             2        12392          12425             とら
PRESAVED:     ‚Æ‚ç             2        12392          12425             とら
Conclusion: When writing unicode strings using normal sql the stored value is corrupt, however using parameters when writing results in a properly stored value. Reading a properly stored unicode string from the database is successfull.

DSN (no workarounds checked): dsn=dsnname;uid=username;pwd=password
FROM SQL:     ¿¿               2       -129            -129              ¿¿
FROM PARARMS: ¿¿               2       -129            -129              とら
PRESAVED:     ¿¿               2       -129            -129              とら
Conclusion: When writing unicode strings using normal sql the stored value is corrupt, however using parameters when writing results in a properly stored value. Reading a properly stored unicode string from the database is NOT successful.

ORAOLEDB.ORACLE: Provider=ORAOLEDB.ORACLE;Data Source=ds;User Id=username;Password=password;
FROM SQL:     ‚Æ‚ç             2        12392          12425             とら
FROM PARARMS: ‚Æ‚ç             2        12392          12425             とら
PRESAVED:     ‚Æ‚ç             2        12392          12425             とら
Conclusion: This works in all situations.

The PRESAVED lines above indicate a record was previously saved to the database with a valid unicode value and was then read using the indicated data provider.