Использование тильды (~) в пути asp.net

Question

Использование тильды (~) в пути asp.net

Я работаю над приложением asp.net, следующая ссылка работает в IE, но не в FF.

<a href="~/BusinessOrderInfo/page.aspx" >

Разве это не то, что можно использовать только в элементах управления сервером asp.net. Где это будет заменено реальным путем?

Можно ли использовать тильду в теге привязки? Если так, что это значит?

Когда я в корне, ссылка работает

www.myserver.com/default.aspx, click the link, ok!

www.myserver.com/otherpart/default.aspx, click the link, not ok!

Ссылка, сгенерированная ASP.NET:

www.myserver.com/otherpart/~BusinessOrderInfo/page.aspx

Это по замыслу?

81

c# asp.net

Источник

user103089 19 июн '10 в 22:58

6 ответов

Решение

Элементы управления HTML можно превратить в элементы управления сервером, добавив атрибут runat="server".

<a href="~/BusinessOrderInfo/page.aspx" runat="server">

23

Источник

user365817 19 июн '10 в 23:12

Тильда относится к корневому каталогу приложения и будет правильно переведена в свойства элемента управления, такие как NavigateUrl.

Насколько я понимаю, если вы используете его в тегах обычного HTML, он не будет переведен ASP.Net.

12

Источник

user21336 19 июн '10 в 23:06

Эта функция также может использоваться для разрешения путей для несерверных элементов.

VirtualPathUtility.ToAbsolute($"~/App_Themes/Default/Icons/myimage.gif")

1

Источник

user1786596 09 ноя '17 в 14:52

Если вы удалите тильду и используете только косую черту, вы получите тот же результат, то есть указание на корневую папку в текущем домене:

<a href="/BusinessOrderInfo/page.aspx" >

0

Источник

user3254405 16 фев '17 в 15:32

Использование веб-путей и тильды «~» в ASP.NET

не является частью систем путей HTML, CSS или JavaScript.
является искусственным символом разрешения пути, который используется только в продуктах ASP.NET или сторонних производителей.
— это путь только для веб-сервера, который преобразуется в новый путь кодом, работающим на сервере.
— это символ, который указывает ASP.NET на сервере IIs WindowsServer найти «корневой каталог приложения» вашего веб-сайта.
разрешается как «виртуальный путь», поскольку он указывает серверу найти виртуальный корень или корень приложения веб-приложения ASP.NET, управляемого данным доменом приложения на сервере, и разрешить его из этого нового виртуального корня.
в большинстве случаев разрешается в корень веб-сайта любого веб-сайта сразу после домена, независимо от того, на какой странице или вложенной папке вы находитесь, когда вызывается путь. Почти во всех случаях это разрешается в . Таким образом, в БОЛЬШИНСТВЕ случаев они одинаковы, если вы не настроилиVirtual Applicationна сервере.
действительно полезен только тогда, когда ваш веб-сайт использует один или несколькоVirtual Applicationsна веб-сервере, таком как IIs. Это искусственные подприложения в вашем веб-домене, которые добавляют новую папку или путь в корневом каталоге веб-сайта, которые на самом деле не существуют, но представляют собой отдельные приложения и процессы, управляемые сервером. Это часто создает одну или несколько папок виртуальных приложений в вашем домене в II, которыми ASP.NET и II управляют при запуске отдельных экземпляров вашего веб-сайта ASP.NET в одном домене. См. ниже...
Microsoft .NET теперь использует пути атрибутов маршрутизации . При использовании они начинают обратный путь в корне веб-сайта как абсолютный путь, но также переопределяют пути всех контроллеров или других атрибутов.

ВИРТУАЛЬНЫЕ ВЕБ-ПРИЛОЖЕНИЯ

Раньше мы создавали виртуальные приложения на веб-сервере II, чтобы создать еще два веб-пути, чтобы изолировать один или несколько веб-опытов с использованием одного и того же домена. Каждый виртуальный путь может быть «призрачным» путем, который указывает на корневой веб-узел, но создает дополнительную призрачную папку в корневом веб-узле. Во многих случаях этот новый виртуальный путь указывал на физическую папку, отдельную от обычного веб-пути, или даже на путь или сопоставление жесткого диска компьютера. ASP.NET с правильным разрешением затем запустил оттуда код веб-сайта. Новый виртуальный путь, показанный посетителям вашего веб-домена, будет отображаться как часть основного сайта, но запускать второй экземпляр вашего веб-приложения с помощью отдельного процесса, запускаемого ASP.NET (отдельный AppPool или рабочий процесс).

был тогда очень полезен в тех случаях. Он использовался для разрешения пути и легко сопоставлялся с корнем этих новых корней виртуальных приложений или путей, созданных сервером, что позволяло запускать несколько приложений на одном веб-сайте без изменения путей в коде ASP.NET. После этого код на стороне сервера разрешал бы для вас пути внутри каждого виртуального приложения без каких-либо изменений в кодовой базе.

в этих ситуациях было чрезвычайно ценно , поскольку вам больше не нужно было управлять несколькими путями в вашем веб-приложении для каждого приложения, если оно работало в нескольких виртуальных веб-приложениях на одном веб-сайте с разными веб-корнями. Он всегда мог найти новый корень в каждом приложении, используя вместо настоящего веб-корня, который всегда былhttp://example.com/

ПРИМЕРЫ

Большинство путей в ASP.NET, использующих, разрешаются на обычном веб-сайте без виртуальных приложений и указывают все пути к корневому веб-сайту URL-адреса ниже. В большинстве случаев именно поэтому ASP.NET является избыточным.Просто используйте. Оба указывают на веб-корень:

      https://example.com/

Однако, если вы добавили в свой домен виртуальные каталоги, как показано в приведенном ниже примере, внутри каждого отдельного веб-приложения будет разрешено два разных веб-корня:

      https://example.com/virtualapplication1/
https://example.com/virtualapplication2/

На заре ASP.NET я всегда брал путь к приложению , используя приведенный ниже код, хранящийся в глобальной переменной. Это позволило мне полностью контролировать все пути от относительного веб-корня приложения вне корня домена или виртуального корня, независимо от того, куда было перемещено мое веб-приложение. Но этот путь и есть~/заменен давно. Тем не менее, это все же может быть лучше, поскольку вы можете динамически создавать пути из него на сервере:

      var myWebRoot = HttpContext.Current.Request.ApplicationPath;

Мое мнение, что виртуальные приложения, подобные этому, сегодня редко используются, поскольку домены дешевы, а вместо них часто используются поддомены, например:

      https://app1.example.com/
https://app2.example.com/

Все веб-пути должны использовать абсолютные пути во всех возможных случаях. Исключением являются пути CSS, которые относятся к исходной странице или коду, вызывающему их внутри. Многие говорят, что это означает, что эти абсолютные веб-пути ломаются, если вы их перемещаете. Но я спорю, зачем вам нужно ссылаться на корень вашего сайта, а затем внезапно менять его? Если вы это сделаете, это должно управляться на стороне сервера и внедряться в ваш HTML и JavaScript, а не наоборот.

Во-вторых, многие поставщики с открытым исходным кодом, основанные на UNIX, создают библиотеки JavaScript API, которые спотыкаются о точечные пути , которые HTML и CSS не поддерживают , например или

Это соглашения UNIX, которые просто указывают на локальную папку или ту же папку, в которой находится вызывающий код. Это то же самое, что и NO PATH, так зачем его использовать? Есть случаи их использования, но конечный результат не влияет на веб-пути. Поэтому я бы избегал их использования. ЕДИНСТВЕННОЕ место, где они надежно работают в JavaScript, — это новый модуль JavaScript в ECMAScript. Но в проприетарных API, таких как Google Angular, они необходимы.

Например, эти два пути к изображениям используют соглашения о локальных путях UNIX с использованием./или.оба терпят неудачу в HTML и создают ошибки отсутствующего изображения:

      // These return broken image icons in browsers when using
// these unconventional UNIX local dot path conventions on the Web:
<img id="image1" src="./images/image1.png" />
<img id="image2" src="/images/.image2.png" />

Так что избегайте всей этой системы отклоняющихся путей и придерживайтесь /абсолютные HTML-пути, и ваш код всегда будет работать десятилетиями!

0

Источник

user5555938 23 янв '23 в 09:16

Другие вопросы по тегам c# asp.net

user241462 19 июн '10 в 23:03 2010-06-19 23:03 · Accepted Answer · 2010-06-19 23:03

Вы правы, это работает только в серверных элементах управления. У вас есть эти основные опции:

Изменить на HyperLink работать как веб- элемент управления:

<asp:HyperLink NavigateUrl="~/BusinessOrderInfo/page.aspx" Text="Whatever" runat="server" />

Или запустите привязку на стороне сервера как элемент управления HTML:

<a href="~/BusinessOrderInfo/page.aspx" runat="server" >

Или используйте Page.ResolveUrl:

<a href="<%= Page.ResolveUrl("~/BusinessOrderInfo/page.aspx") %>">...</a>