URL and Assembly Loading

A URL is a string used to locate a resource in the Internet.


Raw URLs are simply sequences of (Unicode) characters. For example, URL http://server/dir/%file.htm represent a file called “%file.htm” in the virtual directory “dir” of an http server “server”.


Raw URLs sometimes are called “Unescaped URLs”.


According to the URL RFC (http://www.ietf.org/rfc/rfc1738.txt),


   Octets must be encoded if they have no corresponding graphic
   character within the US-ASCII coded character set, if the use of the
   corresponding character is unsafe, or if the corresponding character
   is reserved for some other interpretation within the particular URL


A raw URL may include those characters. Thus a raw URL usually requires encoding before it is transported. A typical encoding scheme is to UTF8 encode the raw URL, then encode all the non graphic characters, unsafe characters, and the reserved characters with a character triplet consisting of the character “%” followed by the two hexadecimal digits (from “0123456789ABCDEF”) which forming the hexadecimal value of the octet.


The raw URL example above http://server/dir/%file.htm will be encoded to http://server/dir/%25file.htm


The encoded URLs sometimes are called “Escaped URLs”.


In general URLs are written as follows:



Some common schemes are ftp, http, https, file, news, nntp, mailto, telnet.


In .Net framework, for Assembly loading, we only support Raw URLs with scheme of either http, https or file.  This includes Assembly.LoadFrom, and codebase hint in config files.


In .Net framework 1.0/1.1, we have a bug that we did not handle Unicode URLs correctly. This is fixed in .Net framework 2.0. We may backport the fix to 1.0/1.1, depending on the demand.

Comments (5)

  1. Dinis Cruz says:

    what bug is there in version 1.1 and 1.0?

    How can this bug be mitigated in 1.0 and 1.1 sites?

  2. For example, if you call Assembly.LoadFrom on URL with Japanese characters, we may return an error.

  3. Dinis Cruz says:

    Where does the error occour?

    is it when the CLR tries to find the assembly in the OS?

  4. The error happens in the URL transportation. We did the encoding wrong. So typically the server will simply return file not found. Sometimes the server will return an HTML file to us, which will result in a BadImageFileException.

    Think of it, it is possible that the URL we send out may exist in the server, but a different file. Fortunately we will always do assembly name mis-match check, and strong name hash validation, so the server can’t spoof the assembly.