Thanks Jeff.
Sorry if I'm wasting time here or not explaining things clearly.
If the port an SQL Server instance listens on is dynamically assigned, that means it can change each time the SQL Server service is (re)started, as per the explanation quoted below from SQL Server 2005 Books Online. So hard-coding a port number into connection strings wouldn't be a permanent solution.
The point you make about the problem not being DNN or even ASP.NET is understood.
The problem is that the DNN installation instructions don't work if SQL Server was installed as a named instance, even though the DNN install instructions refer broadly to SQL Server as THE RDBMS of choice.
If a connection string that specifies the SQL Server instance name is needed (so that the SQL Server Browser Service can return a port) for non-default installation of SQL Server then it might be worth trying to get that mentioned in the DNN install guide. Otherwise, if there is no connection string that works with the SQL Server Browser Service, then a fixed port number (whether it is 1433 or something else) is an installation prereq that has been omitted from the DNN install guide.
Thanks again,
D
---------------
from "SQL Server 2005 Books Online"
"When connecting, clients can specify the desired port, but if the port is dynamically assigned, the port number can change anytime SQL Server is restarted, so the correct port number is unknown to the client.
...
When SQL Server 2000 and SQL Server 2005 clients request SQL Server resources, the client network library sends a UDP message to the server using port 1434. SQL Server Browser responds with the TCP/IP port or named pipe of the requested instance. The network library on the client application then completes the connection by sending a request to the server using the port or named pipe of the desired instance.