none
ASP.NET WebフォームでURLルーティングをすると、javascriptのフォルダ階層がずれて読みこまれない RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    Web開発：ASP.NET4 Webフォーム（Webサイト）
    開発環境：VB2010 /Windows7 Pro x64

    Webフォームの開発で以下を参照しながら、URLルーティングを組み込みました。

    チュートリアル: Web フォーム アプリケーションでの ASP.NET ルーティングの使用

    今までは、URLクエリでパラメータを渡していました。

    ここで、１つ問題が発生しました。
    *.aspxファイル内で、cssとjavascriptを外部参照していますが、cssは自動的にフォルダ階層が
    変わるのですが、javascriptは素のままになっているため、読み込まれない現象が発生しています。

    例えば、

    IDE上の*.aspxファイル内記述　        ：<link href="CSS/graph.css" rel="stylesheet" type="text/css" />
    URLルーティングで呼びだされた *.aspx：<link href="../CSS/graph.css" rel="stylesheet" type="text/css" />

    この「../」がjavascriptの参照に自動的に付与されないため、ハードコーディングで記述して対処しています。
    ただ、この方法だと、通常の呼び出しの時に、階層が違うため、当然javascriptは読み込まれません。

    いちおう、こちらの内容も、合わせたつもりです。

    方法 : Web フォームでルーティングを使用する

    皆様は、どのように対処されていますでしょうか。何かアドバイスを頂けたらと思います。
    よろしくお願いいたします。






    • 編集済み Kino001 2018年7月24日 11:24
    2018年7月24日 10:15
    |

回答

  • Question
    サインインして投票
    2
    サインインして投票

    web.config は関係なくて、アプリケーション名がパスに入ってないという問題でしょう。

    > フォルダの構成は以下のようになっています。
    >
    > F:\WebDataSystem\CSS\graph.css
    > F:\WebDataSystem\js\graph.js

    F ドライブ直下にある WebDataSystem フォルダを VS2010 で［ファイル(F)］⇒［開く(O)］⇒［Web サイト(E)...］⇒［ファイルシステム］ダイアログで選んで開発サーバー上で実行させていると思いますが、そうすると WebDataSystem はアプリケーション名になるはずです。

    例えば、WebDataSystem フォルダ直下の Default.aspx をブラウザ上に表示したときは、ブラウザのアドレスバーには以下のように表示されるはずです。

    http://localhost:51333/WebDataSystem/Default.aspx

    注：ポート番号 51333 は質問者さんの環境では異なると思いますが。 

    その場合、上記 .css, .js ファイルのパスは、それぞれ、

    http://localhost:51333/WebDataSystem/CSS/graph.css
    http://localhost:51333/WebDataSystem/js/graph.js

    となるはずで、サイトルート相対パスは、それぞれ、

    /WebDataSystem/CSS/graph.css
    /WebDataSystem/js/graph.js

    となります。

    IIS での実環境の場合も同様、サイト直下でなくアプリケーション直下にあれば、アプリケーション名も必要です。


    • 編集済み SurferOnWww 2018年7月26日 3:59
    • 回答としてマーク Kino001 2018年7月26日 4:23
    2018年7月26日 3:58
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様

    コメントありがとうございます。

    無駄ではありますが、別のページの確認があって、とりあえず試してみた結果を記載・・・といったところです。

    開発サーバーだけ、物理サーバーだけ、というわけにもいかないので、どちらでも稼働させる方法が見つかりましたので、こちらを採用することにしました（IE11はNGのようですが・・ EdgeはOK）。

    ASP.Net Master Page and File path issues



    • 編集済み Kino001 2018年7月26日 10:52
    • 回答としてマーク Kino001 2018年7月26日 23:53
    • 回答としてマークされていない Kino001 2018年7月27日 4:56
    • 回答としてマーク Kino001 2018年7月27日 4:57
    2018年7月26日 10:37
    |

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票
    質問者さんが参考にされている記事はほとんど読んでませんし（それを読むのは自分には負担が大きすぎますので）、質問者さんがどのような設定を行っているかも不明なのでハズレかもしれませんが・・・

    サイト ルート相対パス（詳しくは以下の記事参照）を使うことはできないのでしょうか？

    ASP.NET Web サイトのパス
    https://msdn.microsoft.com/ja-jp/library/ms178116%28v=VS.100%29.aspx

    それがダメと言うことですと、VirtualPathUtility.ToAbsolute メソッドを利用して ~ 演算子にに相当するパスを取得する方法はいかがですか？　詳しくは以下の記事を見てください。

    パスの設定
    http://surferonwww.info/BlogEngine/post/2011/09/04/How-to-specify-path-for-respurce-in-ASPNET-web-application.aspx
    2018年7月25日 7:00
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様

    コメントありがとうございます。

    リンクはURLルーティングを実装する上で、参考にしたということだけでした。

    実際に、URLルーティング自体は稼働しています（何か足りなのかもしれませんが・・）
    また、JSファイル/CSSファイルの指定は相対パスで記述しております。

    URLルーティングで呼び出したときは、CSSファイルの相対パスは自動的に変換されるのですが、JSファイルの相対パスには変更がなく、読み込めないといった状況です。

    ・CSS
    <link href="CSS/graph.css ･･･　->　<link href=../CSS/graph.css" ･･･

    ・JS
    <script src="js/graph.js" ･･･   -> <script src="js/graph.js" ･･･  　<<-- 相対パスはそのまま　

    <script src="../js/graph.js"　にならないと読めない。

    metaやlinkは、コードビハインドから追加することはできると思いますが、
    scriptは、クライアントスクリプトブロックとして記述しなければならないので、
    メンテナンス性に難ありのため実施していませんでしたが、出来ないものは致し方ないので、
    運用方法を再検討してみます。

    2018年7月26日 1:57
    |
  • Question
    サインインして投票
    1
    サインインして投票
    私のレスを読んでもらってますか？　紹介した記事「ASP.NET Web サイトのパス」は読みましたか？　話は通じてますか？　先の私のレスで、

    > サイト ルート相対パス（詳しくは以下の記事参照）を使うことはできないのでしょうか？

    と提案しましたが、それはやってみたんですか？

    「サイト ルート相対パス」＝「相対パス」ではないですよ。

    「サイト ルート相対パス」を使えばたぶん解決すると思います。自信度 90% ぐらいはあります。

    「サイト ルート相対パス」の意味が分からず、どのようにすればいいか分からないなら聞いてください。

    もし、やってみたがダメだったということなら、具体的にどのようにしてどのような結果になったのかフィードバックしてください。
    2018年7月26日 2:45
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様

    コメントありがとうございます。

    すみません、勘違いしていました。

    ここに質問を出す前に、確認済みでした　->　サイトルート相対パス

    「ASP.NET開発サーバー」での確認になりますが、なぜか、CSSもJSも読み込まれませんでした。

    フォルダの構成は以下のようになっています。

    F:\WebDataSystem\CSS\graph.css
    F:\WebDataSystem\js\graph.js
    F:\WebDataSystem\WebDataSystem.sln

    左側が、IDE上のコードで、右側がブラウザから取得したものです（ChromeのDevTool）
    場所は「*.aspx」における、<head></head>の中に記述しています。

    ・CSS
    <link href="/CSS/graph.css ･･･　->　<link href=/CSS/graph.css" ･･･

    ・JS
    <script src="/js/graph.js" ･･･   -> <script src="/js/graph.js" ･･･

    パスの構成上、まったく問題ないと思うのですが、なぜか、404（Not Found）になってしまいます。

    web.config あたりの問題でしょうか・・・

    2018年7月26日 3:28
    |
  • Question
    サインインして投票
    2
    サインインして投票

    web.config は関係なくて、アプリケーション名がパスに入ってないという問題でしょう。

    > フォルダの構成は以下のようになっています。
    >
    > F:\WebDataSystem\CSS\graph.css
    > F:\WebDataSystem\js\graph.js

    F ドライブ直下にある WebDataSystem フォルダを VS2010 で［ファイル(F)］⇒［開く(O)］⇒［Web サイト(E)...］⇒［ファイルシステム］ダイアログで選んで開発サーバー上で実行させていると思いますが、そうすると WebDataSystem はアプリケーション名になるはずです。

    例えば、WebDataSystem フォルダ直下の Default.aspx をブラウザ上に表示したときは、ブラウザのアドレスバーには以下のように表示されるはずです。

    http://localhost:51333/WebDataSystem/Default.aspx

    注：ポート番号 51333 は質問者さんの環境では異なると思いますが。 

    その場合、上記 .css, .js ファイルのパスは、それぞれ、

    http://localhost:51333/WebDataSystem/CSS/graph.css
    http://localhost:51333/WebDataSystem/js/graph.js

    となるはずで、サイトルート相対パスは、それぞれ、

    /WebDataSystem/CSS/graph.css
    /WebDataSystem/js/graph.js

    となります。

    IIS での実環境の場合も同様、サイト直下でなくアプリケーション直下にあれば、アプリケーション名も必要です。


    • 編集済み SurferOnWww 2018年7月26日 3:59
    • 回答としてマーク Kino001 2018年7月26日 4:23
    2018年7月26日 3:58
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様

    コメントありがとうございます。

    サイトルート相対パスの指摘ありがとうございます。

    ご紹介いただいたページで、
    「Server.MapPath("~") でWeb サイトのルートのファイル パスを返します」とあって、
    デバッグモードで実行した結果、「    "F:\WebDataSystem"」であったため、そこから下の階層と
    勘違いしていました。

    おっしゃるとおり
    「http://localhost:51333/WebDataSystem/CSS/graph.css」　となっています。

    「/WebDataSystem/CSS/graph.css」　とすることで、解決しました。

    ありがとうございました。

    2018年7月26日 4:23
    |
  • Question
    サインインして投票
    1
    サインインして投票

    > ご紹介いただいたページで、
    > 「Server.MapPath("~") でWeb サイトのルートのファイル パスを返します」とあって、
    > デバッグモードで実行した結果、「"F:\WebDataSystem"」であったため、そこから下の階層と
    > 勘違いしていました。

    その「ルート」というのはサイトではなくアプリケーションのルートです。同じ記事に "ASP.NET は、~ 演算子を現在のアプリケーションのルートに解決します" という説明があります。

    ASP.NET Web アプリ開発では常識ですので、おぼえておかれるのが良いと思います。

    ちなみに、link 要素の href 属性には ~ 演算子を使えます（script 要素の src 属性にはダメですが）。なので、

    <link href="/WebDataSystem/CSS/graph.css" ...

    に代えて、以下のようにしても OK のはずです。

    <link href="~/CSS/graph.css" ...

    お試しください。

    2018年7月26日 6:04
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様

    コメントありがとうございます。

    サイトルートの件、覚えておきます。

    /WebDataSystem/・・・ のままとして、Deployしてサーバーで動作確認をしてみました。
    （Windows Server 2012R2 Standard + IIS8.5)

    サーバーでは、「WebDataSystem」の配下にしていないかったため・・・・　読み込まれませんでした。
    (https://hoge.hogehoge.jp/js/graph.js)

    CSSは何もしなくても問題ないので、以下の３つがOKでした。

    <link href="/CSS/graph.css" ･･･
    <link href="CSS/graph.css" ･･･
    <link href="~/CSS/graph.css" ･･･

    JSに関しては、以下のみがOKでした。
    <script src="/js/graph.js" ･･･
    <script src="../js/graph.js" ･･･

    IDEで動かすには、後者のみが稼働するので、当面はそれにしようかと思います。




    • 編集済み Kino001 2018年7月26日 9:45
    2018年7月26日 8:58
    |
  • Question
    サインインして投票
    0
    サインインして投票
    先にレスしたことがほとんど理解されてないようで残念です。

    > /WebDataSystem/・・・ のままとして、Deployしてサーバーで動作確認をしてみました。
    > サーバーでは、「WebDataSystem」の配下にしていないかったため・・・・　読み込まれませんでした。
    > (https://hoge.hogehoge.jp/js/graph.js)

    サーバーで動作確認のとき <script src="/WebDataSystem/js/graph.js" ... としたのですか？

    であれば、当たり前ですよ。私が今まで説明したこと、紹介した記事を理解していれば、そんなことは試すことさえしないはず。

    サイトルートのサイトというのは、以下のそれぞれのケースでどこだと思いますか？　先の私のレスや紹介した記事を読んでよく考えてみてください。

    開発環境： http://localhost:51333/WebDataSystem/js/graph.js
    運用環境： https://hoge.hogehoge.jp/js/graph.js

    先の私のレスで、

    > IIS での実環境の場合も同様、サイト直下でなくアプリケーション直下にあれば、アプリケーション名も必要です。

    と言いましたが、誤解を招いたのですか？　「アプリケーション名も必要」というところだけ読んだのですか？　それは、「サイト直下でなくアプリケーション直下にあれば」という条件付きです。
    2018年7月26日 10:03
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様

    コメントありがとうございます。

    無駄ではありますが、別のページの確認があって、とりあえず試してみた結果を記載・・・といったところです。

    開発サーバーだけ、物理サーバーだけ、というわけにもいかないので、どちらでも稼働させる方法が見つかりましたので、こちらを採用することにしました（IE11はNGのようですが・・ EdgeはOK）。

    ASP.Net Master Page and File path issues



    • 編集済み Kino001 2018年7月26日 10:52
    • 回答としてマーク Kino001 2018年7月26日 23:53
    • 回答としてマークされていない Kino001 2018年7月27日 4:56
    • 回答としてマーク Kino001 2018年7月27日 4:57
    2018年7月26日 10:37
    |
  • Question
    サインインして投票
    0
    サインインして投票
    > 無駄ではありますが、別のページの確認があって、とりあえず試してみた結果を記載・・・といったところです。

    無駄だと分かってるなら、そんなことは書かない方が良いと思います。少なくとも私はそういう意味のないことは聞きたくないです。多分、他の方にとっても、混乱を与えるだけで、情報として役に立つとは思えません。質問者さんの胸の内に留めておいていただけたらと思います。

    > 開発サーバーだけ、物理サーバーだけ、というわけにもいかないので、どちらでも稼働させる方法が見つかりましたので、こちらを採用することにしました（IE11はNGのようですが・・ EdgeはOK）。

    それは前の質問者さんのレスにあった「メンテナンス性に難ありのため実施していませんでした」ということと同じになるのでは？

    開発環境で、ASP.NET 開発サーバーではなくて、IIS Express や ローカル IIS を使うとかで簡単に解決できる問題ですよ。VS2010 でも IIS Express やローカル IIS を使って開発するのはもちろん可能です。
    2018年7月26日 11:26
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様

    コメントありがとうございます。

    余計なことを書いてしまってすみませんでした。
    意味のない情報で他の方を混乱させるのもよくないので、後で削除しておきます。

    > それは前の質問者さんのレスにあった「メンテナンス性に難ありのため実施していませんでした」ということと同じになるのでは？

    こちらに関しましては、他によい方法も見つけられないことと、コードビハインド側を変更する必要がないことから、ベターな方法であると考えています。また、IE11は、起動側でURLクエリ呼出しにします。


    2018年7月26日 23:52
    |
  • Question
    サインインして投票
    0
    サインインして投票
    > 後で削除しておきます。

    いえ、レスが付いたらそれはそれは止めてください。

    今までこのスレッドに参加してきてない人が検索などでここを見るという可能性もあります。そういった人が一番最初の質問から順に下から読んでいくと、話がつながらなくなり、訳が分からなくなるかもしれません。

    このフォーラムは技術者間の情報交換の場として提供されているとのことですので、そう言ったことも配慮ください。
    • 編集済み SurferOnWww 2018年7月27日 0:42 訂正
    2018年7月27日 0:41
    |
  • Question
    サインインして投票
    0
    サインインして投票

    > 他によい方法も見つけられないことと、

    ScriptManager を使うとかコードブロックを埋め込むとかいう方法が、質問者さんにとって他よりよい方法ということですか？

    であれば、コードブロックを使う方法は最初の私のレスで紹介した 2 つめの記事に書きました（中身は少々違いますが）。読んでないのですか？　それとも、読んだけど理解できなかったということですか？

    それはちょっと置いといて、質問者さんの問題・課題がよく分からないので、そこをクリアにしていただけませんか？

    自分は、

    開発環境での外部 .css, .js ファイルへの参照（.aspx ソース内の link 要素と script 要素の記述）を、運用環境にそのまま一切手を加えずデプロイしたい。

    しかしながら、開発環境と運用環境では、以下の違いがあってそれができないのが問題・課題。

    (1) 開発環境：F ドライブ直下にある WebDataSystem フォルダ下に、開発中・保守中の ASP.NET Web Forms の Web サイトプロジェクトがある。開発・保守は、そのフォルダを Visual Studio 2010 で［ファイル(F)］⇒［開く(O)］⇒［Web サイト(E)...］⇒［ファイルシステム］ダイアログで選んで開き、Visual Studio の［デバッグ開始］または［デバッグなしで開始］で ASP.NET 開発サーバー上で実行させて行っている。

    (2) 運用環境：開発環境からデプロイされたフォルダを、IIS 上ではサイトに設定している（アプリケーションではなく）。

    (3) 結果 URL が以下のように異なり、.css, js ファイルへのパスは「サイト ルート相対パス」も「相対パス」違ってくる。

    開発環境： http://localhost:51333/WebDataSystem/js/graph.js
    運用環境： https://hoge.hogehoge.jp/js/graph.js

    ・・・と理解しています。違う点があれば詳しく指摘してください。


    > 起動側でURLクエリ呼出しにします。

    「起動側でURLクエリ呼出し」というのはどういうことですか？　そこのところが不明なのですが、上記 (1), (2) 以外の何か特別なことをしているのですか？

    以上の点をクリアにしていただいた上で、「他によい方法も見つけられない」ということであれば納得ですが、そうでなければ質問者さんのレスに自分で「回答としてマーク」を付けるというのはいかがなものかと思うのですが。





    • 編集済み SurferOnWww 2018年7月27日 2:42 訂正
    2018年7月27日 1:21
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様

    > であれば、コードブロックを使う方法は最初の私のレスで紹介した 2 つめの記事に書きました（中身は少々違いますが）。

    すみません、せっかく紹介いただいたのですが、理解できなかったのと、色々と手を加えなければいけなさそうだったため、こちらは試していません。

    私にとっては、「ASP.Net Master Page and File path issues」で記載されている方法が、比較的簡単に自分の目的のことができる内容でしたので、回答マークを付けました。

    > 開発環境での外部 .css, .js ファイルへの参照（.aspx ソース内の link 要素と script 要素の記述）を、運用環境にそのまま一切手を加えずデプロイしたい。

    その通りです。IIS6のころに、「サイト」として稼働していたので、IIS8.5でも「サイト」で稼働させています。
    最初の質問に記載しましたように、URLルーティングで起動した場合と、URLクエリで起動した場合とで、JSファイルの
    パスを変更しなければならないため、その対処方法について知りたかったのです(物理サーバー、開発環境に関わらず）。

    最初に物理サーバーの環境についても書いておけばよかったですね。

    > 「起動側でURLクエリ呼出し」というのはどういうことですか？　そこのところが不明なのですが、上記 (1), (2) 以外の何か特別なことをしているのですか？

    URLクエリパラメータで起動していたものを、URLルーティングとして起動すると、パスがかわるため、JSファイルが読み込めないことが発生し、「ASP.Net Master Page and File path issues」で対策をとりました。
    しかし、IE11はこの方法で対策できなかったため（パスが動的に変わらない）、IEの場合は、呼出し側の対策としてURLクエリとして起動することで、パスの問題の解消をすることにしたのです（IE11対策の根本的な解決ではありません）。

    2018年7月27日 5:25
    |
  • Question
    サインインして投票
    0
    サインインして投票

    前の私のレスの質問、

    > 「起動側でURLクエリ呼出し」というのはどういうことですか？　そこのところが不明なのですが、上記 (1), (2) 以外の何か特別なことをしているのですか？

    に対する答えが、上の質問者さんのレスの、

    > URLクエリパラメータで起動していたものを、URLルーティングとして起動すると、パスがかわるため、

    ということのようですが、「URLクエリパラメータで起動」とか「URLルーティングとして起動」とか意味が分かりません。

    くどいようですが、上の私のレスで書いたことを再度聞かせてください。以下の話とは違うのですか？

    (1) 開発環境：F ドライブ直下にある WebDataSystem フォルダ下に、開発中・保守中の ASP.NET Web Forms の Web サイトプロジェクトがある。開発・保守は、そのフォルダを Visual Studio 2010 で［ファイル(F)］⇒［開く(O)］⇒［Web サイト(E)...］⇒［ファイルシステム］ダイアログで選んで開き、Visual Studio の［デバッグ開始］または［デバッグなしで開始］で ASP.NET 開発サーバー上で実行させて行っている。

    (2) 運用環境：開発環境からデプロイされたフォルダを、IIS 上ではサイトに設定している（アプリケーションではなく）。

    (3) 結果 URL が以下のように異なり、.css, js ファイルへのパスは「サイト ルート相対パス」も「相対パス」違ってくる。

    開発環境： http://localhost:51333/WebDataSystem/js/graph.js
    運用環境： https://hoge.hogehoge.jp/js/graph.js

    そして、上の (1), (2) の状況で (3) のようにパスが異なるのを何とかしたい、すなわち、運用環境と同じく、

    開発環境： http://localhost:51333/js/graph.js

    とできればいいのであれば、これも上のレスに書きましたが、開発環境で、ASP.NET 開発サーバーではなくて、IIS Express や ローカル IIS を使うとかで簡単に解決できる問題です。

    ASP.NET 開発サーバー

    IIS Express

    そのように対応しないと、link, script 要素以外にも img, a 要素、リダイレクト先などのパスにも影響してきて、手に負えなくなると思うのですが。

    ただし、質問者さんが言う「URLクエリパラメータで起動していたものを、URLルーティングとして起動する」ということが上の (1), (2), (3) のような話ではなくて、何か別なことだとすると、自分は話についていけませんので何もコメントできませんしお手上げです。

    2018年7月27日 6:53
    |
  • Question
    サインインして投票
    0
    サインインして投票

    >とできればいいのであれば、これも上のレスに書きましたが、開発環境で、ASP.NET 開発サーバーではなくて、IIS Express や ローカル IIS を使うとかで簡単に解決できる問題です。

    そうですね。「IIS Express や ローカル IIS」で解決できるのだと思います。
    保守的なもので、今ままでの環境をなるべく変えないで何とかしたかったというのがあります。

    ローカルIISは、物理サーバーに導入する前の確認用途としては利用していますが、デプロイしないといけない(この方法以外知らない）ので、なるべく手間を省きたいことから、デバッグ用としては利用していません。

    SurferOnWwwさんの欲しい回答になっていないかもしれませんが・・・
    トップページから別ページを呼び出す場合に、ある種のパラメータを渡して    (JSから)起動したいので、今まではURLクエリパラメータを渡していましたが、それをURLルーティングとしても呼出せるように対応しました(最初の質問に貼ってあるリンク）。
    見た目の違いだけで機能は変わりません    。
    後者の場合は、呼び出したページの階層が１段階下がることから、JSが読み込めなくなったという次第です。
    今のところのかくにんでは、「link」と「src」    は自動で階層補完がされましたが、「script src」 のみがそのままだったため。

    同じプログラムを別のサーバー（別サブドメイン）で運用することもあり、開発環境はいままでどおりで、物理サーバーにそのままポイといれれば、稼働する・・・というのが私の考える理想です。

    そんな後ろ向きな考えのものに回答マークをつけるのはまかりならんということであれば、解除します。

    2018年7月27日 11:03
    |
  • Question
    サインインして投票
    0
    サインインして投票
    何を説明をしようと、ノレンに腕押しという感じがしてますが・・・

    > そうですね。「IIS Express や ローカル IIS」で解決できるのだと思います。
    > 保守的なもので、今ままでの環境をなるべく変えないで何とかしたかったというのがあります。
    > ローカルIISは、物理サーバーに導入する前の確認用途としては利用していますが、

    IIS Express で良いと言ってますけど（ローカル IIS を使う必要はない）。VS2010 でも IIS Express が使えますがご存知ですか？

    それにもかかわらず、「今ままでの環境をなるべく変えないで何とかしたかった」とか言われては話ができないですよ。何も変えたくないなら、ここで質問する意味はあまりなさそうですし。
     
    とにかく、私のレスの (1), (2), (3) の話が質問者さんにとって最優先で解決したい問題・課題ということでいいのですよね。であれば、解決策は：

    ・サイトルート相対パスを使う
    ・可能なら ~ 演算子を使う
    ・開発環境で IIS Express を使う

    ・・・です。それで対応できる以上、それ以外に正解はないと言ってもいいと思ってます。


    > トップページから別ページを呼び出す場合に、ある種のパラメータを渡して(JSから)起動したいので、今まではURLクエリパラメータを渡していましたが、それをURLルーティングとしても呼出せるように対応しました(最初の質問に貼ってあるリンク）。
    > 見た目の違いだけで機能は変わりません。
    > 後者の場合は、呼び出したページの階層が１段階下がることから、JSが読み込めなくなったという次第です。
    > 今のところのかくにんでは、「link」と「src」は自動で階層補完がされましたが、「script src」 のみがそのままだったため。

    > 同じプログラムを別のサーバー（別サブドメイン）で運用することもあり、開発環境はいままでどおりで、物理サーバーにそのままポイといれれば、稼働する・・・というのが私の考える理想です。

    意味が分かりませんが、何にせよ、それらすべては質問者さんの特殊事情では？

    特殊事情を勘案した話がしたいのなら、一番最初の質問にその特殊事情を具体的に、ここに書いてあること以外は知り得ない第三者が理解できるように説明して、その特殊事情を含めた対応をどうすればいいかという質問をすべきです。

    特殊事情に「今ままでの環境をなるべく変えないで何とかしたかった」も含まれるなら、最初に質問に「今までの環境」を明記しておくべきですね。

    はっきり言わせていただくと、自分のやり方が間違ってないと言うために、いろいろ取り繕っているようにしか思えません。
    2018年7月27日 13:12
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SurferOnWww 様の言われる通りこの機能が、実現できればと思っていました。

    > ・サイトルート相対パスを使う

    これを、「特殊事情」下で、最短で実現できるのが、「ASP.Net Master Page and File path issues」でした。

    IIS Expressで実現できるのだと思いますが、セットアップや環境構築にどれだけ時間がかかるか
    わかりませんでしたので手を付けていません。
    「前々からセットアップしておけよ」というのはごもっともだと思います。
    （ここで質問する時間があるなら・・・　と言われそうですが・・・。）
    少し時間的余裕ができたら、確認してみます。

    「今ままでの環境をなるべく変えない・・・」などは、私の特殊事情ですね。
    確かに最初に書いておけばよかったと思います。

    「間違えてない」ということではなく、「こういう方法でもできる」ということを記載しているつもりでした。
    そうとらえられたのでしたら、私の文章力の問題だと思います。
    すみません、以後、誤解のないような説明を心がけたいと思います。

    URLルーティングを利用するとブラウザで表示したときにパス構造が変わるとは思っていなかったので、
    セットアップに問題があるのかと考えて、最初に参照したページのリンクを貼りました。
    同じところを参照されて、そうならない方がいらっしゃったら、こちらのセットアップを見直すヒントがもらえたら
    と考えてました。
    セットアップに間違いがあれば、それを解決するのが    早道だと考えましたが、確かに長い文章なので、
    それについて回答をもらおうとしていたのは間違いだったのかもしれません。

    2018年7月31日 1:15
    |