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.

When calling a web service using ASP.NET AJAX, if an error occurs the error information may exclude any error details and just provide the following:

Stack Trace: <empty>
Error: There was an error processing the request.
Status Code: 500
Exception Type: <empty>
Timed Out: false

This occurs when the web.config file customErrors element's mode attribute is set to "On" or "RemoteOnly" and you are not on the server.

To get the full detailed error information, ensure the mode attribute is set to "On", or "RemoteOnly" if accessing from a remote machine.

MSBUILD can give the following error message when compiling using a UNC path:

Error: Could not load file or assembly 'YOURASSEMBLYHERE' or one of its dependencies. Failed to grant minimum permission requests. (Exception from HRESULT: 0x80131417)
              - Required permissions cannot be acquired.

C:\WINNT\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1892,9): error MSB6006: "sgen.exe" exited with code 1.

This occurs when MSBUILD executes sgen.exe to build the optional XmlSerializers.dll assembly.

There are at least 3 ways to work around this error:

1. Don't use a UNC path when compiling.
2. In the project properties Build tab, Set 'Generate serialization assembly' to Off.
3. Use caspol.exe to grant full trust to the UNC path. See Running a .Net application from a network share.

You must edit the windows registry:

System Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\View Source Editor\Editor Name]
Value Name: (Default)
Data Type: REG_SZ (String Value)
Value Data: Path and Filename of Editor