Using the Res: protocol, you can package Web content for an application in the resources of a module. This has two advantages:

•	You do not have to put these Web content files on the file system.
•	You have access to the Web content files when you access the modules.

This article describes how to use this protocol and summarizes some known related issues.

Back to the top

The Res: protocol specifies a resource that will be obtained from a module, and uses the following syntax:

res://sFile[/sType]/sID
				

where the tokens for this code are as follows:

•	sFile. Path and file name of the module that contains the resource.
•	sType. Optional. String or numeric resource type. This can be either a custom resource, or one of the RT_ predefined resource types that is described in the FindResource function reference. If this parameter is not specified, the default resource type is RT_HTML.
•	sID. String or numeric identifier of the resource.

Back to the top

Summary of Some Known Related Issues

•	Although Visual Studio, by default, defines resource ID names like IDR_HTML1, you must change the name to something similar to test.htm for it to succeed. For example: • Incorrect: Res://test.exe/IDR_HTML1 • Correct: Res://test.exe/test.htm
•	You can insert other resources (such as .gif or .jpg files) that are referenced from your Web content (under the HTML resource type that is in Visual Studio). This means that you can also use the default for these resources. For example, if BMP is under HTML, you can use Res://test.exe/picture.bmp. However, if BMP is under Bitmap, you must use Res://test.exe/2/picture.bmp.
•	You do not have to specify the whole path to the module, on the condition that the module is either in the path or is a loaded DLL. For example, you can shorten this longer path from Res://c:\projects\debug\Test.exe/Test.htm to the shorter path of Res://Test.exe/Test.htm on the condition that Test.exe is in the path, in the startup directory, or in the working directory.
•	The Res: protocol cannot support display of licensed controls because the license manager does not support accessing the .lpk file from a Res: protocol. More specifically, the License Manager uses URLDownloadToCacheFile, which does not handle Res: protocol resources. For additional information, click the article number below to view the article in the Microsoft Knowledge Base: 272762 (http://support.microsoft.com/kb/272762/EN-US/) BUG: Cannot Use RES Protocol to Display Licensed Controls
•	You cannot use the Res: protocol to reference .xsl or .xml files. If you try to, you may receive one of the following error messages: • "Access Denied." If you receive this error message, you might be making a security violation when you reference anything outside the current domain. Add the domain or protocol to the list of Trusted Sites so that the customer setting Access data across domains is turned on. If this does not resolve the error, the only resolution is to stop using the Res: protocol. • "No Data is Available for the Requested Resource." If you receive this error message, a bug is present in the Res: protocol. In any situation where content is downloaded synchronously by means of URLMON, the underlying protocol handler must create a cache file for the download to succeed. Unfortunately, the Res: protocol does not do this, so the whole download fails at the URLMON level.

Back to the top

For more information about pluggable protocols, visit the following Microsoft Web site: For additional information about the Res: and About: protocols, click the article numbers below to view the articles in the Microsoft Knowledge Base: For additional information about the XSL stylesheet, click the article number below to view the article in the Microsoft Knowledge Base:

Back to the top