How to preserve ampersand in URL's querystring when using RegisterClientScriptInclude?

I have the need to add a javascript include to my ASP.NET page. The url of the javascript file has two key/value pairs in the开发者_运维问答 query string. But the ampersand is being escaped and I don't want that.

Page.ClientScript.RegisterClientScriptInclude("myKey",
    "https://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.2&s=1")

This results in the following HTML:

<script
    src="https://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.2&amp;s=1"
    type="text/javascript"></script>

But what I really want is:

<script
    src="https://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.2&s=1"
    type="text/javascript"></script>

Help?

Actually the encoded ampersand is valid HTML markup. Your goal is an attempt to generate invalid markup. Unencoded ampersands are not valid.

I have run into this in the past and never found a way around it. I needed to create the URL server side and I don't like putting inline code in my aspx pages so I ended up using a Literal control and building the script tag and assigning it.

For your example:

<form id="form1" runat="server">
    <asp:Literal ID="ltScriptInclude" runat="server"></asp:Literal>

Then in the Page_Load:

string url = "https://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.2&s=1";
ltScriptInclude.Text = string.Format(
    "<script src=\"{0}\" type=\"text/javascript\"></script>",
    url);

A complete recreation would be to also do a check for the registered key by wrapping the assignment in an if like:

if (IsStartupScriptRegistered("myKey"))
{
    // assign
    // set the key
}

But that is probably not needed since it is not being assigned anywhere else with the change of a PostBack double assigning it.

It's not the cleanest solution and it would have been nice if the RegisterClientScriptInclude had some type of param to tell it to not encode. Unfortunately I don't think there is any way around it and the above isn't too bad. Most includes for script files usually don't have the & so the vast majority would never run into this problem.