NUnitAsp

When the machine has no internet connection, these request will result in
an obscure failure of all tests:
NUnit.Extensions.Asp.DoctypeDtdException :
Problems with DOCTYPE DTD: <Timeout für Vorgang überschritten>. Your
DOCTYPE is
probably incorrect. If you're not sure what the DOCTYPE should be, use
<!DOCTY
PE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >, Visual Studio
.NET's d
efault.

Also related: This creates a lot of completely unneccessary traffic, see:

http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic

Logged In: NO

Here's a workaround until the NUnitAsp team can come up
with a better approach. Ideally, maybe the
document.XmlResolver can be updated to know where
to 'find' local copies of these files in the NUnitAsp
distribution.

For now, you can serve up local copies of the files from
IIS.

Details follow...

Here's a workaround to serve up DTD files locally, which
prevents exceptions from
NUnit.Extensions.Asp.WebPage.ParsePageText when it calls
this.document.Load.

The workaround is short-circuit the real URL, and instead,
serve it locally from IIS.

Add an entry into your hosts file, C:\WINDOWS\SYSTEM32
\DRIVERS\ETC\HOSTS

127.0.0.1 www.w3.org

Create directory structure matching TR/xhtml1/DTD.
Example: C:\TR\xhtml1\DTD

Set up IIS to handle the /TR folder
- create a VDIR named TR, point to the TR folder
- change security to anonymous

Download 4 files from www.w3.org into folder TR/xhtml1/DTD

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent
http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent
http://www.w3.org/TR/xhtml1/DTD/xhtml-symbol.ent

Currently, these have the following sizes:

09/05/2006 10:47 PM 11,775 xhtml-
lat1.ent
09/05/2006 10:47 PM 4,131 xhtml-
special.ent
09/05/2006 10:47 PM 13,848 xhtml-
symbol.ent
09/06/2006 12:04 AM 26,450 xhtml1-
strict.dtd

Local IIS should be able to serve up the DTD file to
resolve request locally

Logged In: YES
user_id=779209

I found that NUnit.Extensions.Asp.WebPage.ParsePageText()
can be modified with a null XmlResolver to fix this issue:

try
{
this.document.XmlResolver = null; // <-- add this line
this.document.Load(reader1);
}

turns out others on the web have had this problem and used
this approach to fix it.

http://www.thescripts.com/forum/thread176851.html

Logged In: YES
user_id=779209

This bug is related to bug 1027754.

I'm seeing similar problems that manifest as a DTD
validation error ("The remote name could not be resolved")
when I use NUnitAsp offline (no internet connection). I'm
guessing that adding the DTDs programmatically somehow to
the XmlDocument so it can resolve them when it calls Load
would fix this bug (no longer needing to make outside
calls to resolve the DTD), and also eliminate the issue in
bug 1027754 where it fails to parse a given DTD.