0

クライアント アプリからアプリで Web API Rest メソッドを呼び出そうとしています。私は 2 つのクライアント アプリを持っています。1 つは機能し、もう 1 つは機能しません。

REST メソッドを呼び出すコードは同じです。もちろん、これまったく同じサーバーコードです。

失敗したクライアント アプリでは、次の行で失敗します。

var webResponse = (HttpWebResponse)webRequest.GetResponse();

...そして、2 つのアプリのコードは、失敗した時点まではまったく同じですが、失敗した方がイベント ハンドラーにあり、動作しているものはそうではありません。テスト コードがイベント ハンドラにあり、「実際の」コードが別のメソッドにあることに加えて、もう 1 つの (関連する) 違いは、別のメソッドも別のクラスにあるということです。なぜこれが違いを生むのか、私にはわかりませんが、私はここでストローをつかんでいます. ここにあります:

Cursor.Current = Cursors.WaitCursor;
try
{
    // Cannot start with String.Empty or " "; they both fail for some reason - Controller method is not even called.
    string lastIDFetched = "0";
    const int RECORDS_TO_FETCH = 100;
    bool moreRecordsExist = true;

    try
    {
        while (moreRecordsExist)
        {
            string formatargready_uri = string.Format("http://localhost:28642/api/InventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH);
            var webRequest = (HttpWebRequest)WebRequest.Create(formatargready_uri); 
            // GET is the default method/verb, but it's here for clarity
            webRequest.Method = "GET";
            var webResponse = (HttpWebResponse)webRequest.GetResponse();// <-- this throws an exception when there is no longer any data left

失敗したメソッドの定義:

private void buttonGetInvItemsInBlocks_Click(object sender, EventArgs e)

作業方法の定義:

public static List<HHSUtils.InventoryItem> GetBatchOfInventoryItems()

失敗した場合、最後の行で F10 キーを押すと、例外ブロックに直接移動します (有害と見なされます - 冗談ではありません!) が、例外は何も表示しません - この行にカーソルを合わせます:

catch (Exception ex)

...「Exception | System.Exception base {object} | object」しか見えません

どちらのクライアントも Visual Studio 2008 で構築されており、.NET 3.5 をターゲットとしています。サーバーはVS 2013、.NET 4.5.1です

ここに手がかりがあると思います: 失敗したコードでは、ターゲット デバイスが "Windows CE デバイス" に設定されています (ハンドヘルド デバイスに展開され、"Windows CE のリモート ディスプレイ コントロール" を介して制御されます)。

内なるコロンボと連絡を取り合っている人はいますか?

アップデート

私はこれからコードを変更しました:

var webResponse = (HttpWebResponse)webRequest.GetResponse();

...これに:

using (var webResponse = (HttpWebResponse)webRequest.GetResponse())

...そして違いはありません-例外に有用なデータが表示されずに、その行からcatchブロックに直接ジャンプします。

私のテストアプリでは、「より良い」方法を使用するようにコードを変更しました(使用)。どちらの方法でも機能しますが、他のアプリはどちらの方法でも機能しません. IOW: 使用するのは良いことですが、この場合は実際の違いはありません。

更新 2

JayC の回答に応えて、次のすべての「接続文字列」を試しましたが、結果はすべてまったく同じでした。

string uri = string.Format("http://localhost:28642/api/InventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH); // Fails on "using" line below with no usable exception data
//string uri = string.Format("http://192.112.263.38:28642/api/InventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH); <-- same failure
//string uri = string.Format("http://192.112.263.38/api/InventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH); <-- same failure
//string uri = string.Format("http://192.112.263.38:80/api/InventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH); <-- same failure
//string uri = string.Format("http://192.112.263.38:777/api/InventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH); <-- same failure
//string uri = string.Format("http://192.112.263.38:28642/api/inventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH); <-- same failure
//string uri = string.Format("http://192.112.263.38/api/inventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH); <-- same failure
//string uri = string.Format("http://192.112.263.38:80/api/inventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH); <-- same failure
//string uri = string.Format("http://192.112.263.38:777/api/inventoryItems/{0}/{1}", lastIDFetched, RECORDS_TO_FETCH); <-- same failure

更新 3

CAS に関する Roman Gruber のコメントに応えて: ウィキペディアには CAS の曖昧さ回避ページ ( http://en.wikipedia.org/wiki/Cas_(disambiguation) ) がありますが、提案された可能性はどれもこの文脈では賢明ではないようです。

主な記事である OTOH のコンピューティング セクションには、いくつかの CAS の頭字語があります。次のうちどれに言及していますか。

Central Authentication Service, a single sign-on protocol
Channel Associated Signaling, a type of communication signaling
Code Access Security in the Microsoft .NET framework

?

更新 4

わかりました、私は数匹の猫によって提案されたコードを追加しました:

catch (WebException webex)
{
    HttpWebResponse hwr = (HttpWebResponse) webex.Response;
    HttpStatusCode hsc = hwr.StatusCode;
    MessageBox.Show(string.Format("{0} Status code == {1}", webex.Message, hsc.ToString()));
}

...そして、ブレークポイントがキャッチに到達したときに表示されるものは次のとおりです。

ここに画像の説明を入力

そして、表示されるエラーメッセージは次のとおりです。

「リモート サーバーがエラーを返しました: (400) 不正な要求。ステータス コード == 不正な要求」

問題は「接続文字列」にあると思います。Update 2 に見られるように、考えられる限りのことを試しましたが、デバイスをデスクトップに接続することはできませんでした。

4

5 に答える 5

2

ハンドヘルド デバイスへの展開に失敗したアプリですが、URI は localhost に設定されていますか??

サービスをホストしている実際のコンピューターに解決されるホスト名を使用することをお勧めします。

編集: Windows CE デバイスについては何も知りませんが、デバイスに展開されたデバイスからより明示的な例外情報を取得する簡単な方法があるはずです。あなたの差し迫った問題がたまたま上で述べたことによって解決された場合、それが解決する必要があるあなたの主要な問題だと思います。debug="True" app.config ファイルで設定できるような些細なことだといいのですが、それを調査する必要があります。

于 2013-11-15T18:22:40.530 に答える
1

デバッガーを使用して CE デバイスでアプリケーションを実行してみましたか? 障害がデバッグ環境でのみ発生しているかどうかに興味があります。

また、Roman Gruber は良い質問をしましたが、私は応答を見ていませんでした:

あなたのPCからデバイスを見ることができますが、デバイスはネットワークを見ることができますか? デバイスで Web ブラウザを開き、ネットワーク上の任意のページにアクセスして確認します...

于 2013-11-22T14:40:31.083 に答える
1

質問からのメモを明確にするための答えとしてこれを試します:

1.: CAS = Code Access Security - 申し訳ありませんが、.NET 環境では十分一般的な頭字語だと思います。

2.: サーバーでリクエストを認証します。

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url);
req.Credentials = new NetworkCredential("username", "password");

しかし:私は何か他のことに気づきました...以前の回答や質問は私を少し誤解させ、サンプルコードのスクロールバーも役に立ちませんでした。例外をスローするのは「WebRequest.Create」メソッドですか?? それはまだネットワークにまったくアクセスしていません。この場合、ホスト名/IP アドレスでも資格情報でもありません。それまだCASに関連している可能性があります。しかし、より可能性が高いのは、不正な形式の URI です...

を追加してみてください

MessageBox.Show(formatargready_uri);

WebRequest.Create を呼び出す前に、アプリがデバイス上で生成する URL を確認してください。URI 解析も「軽量」である可能性があります。次に、catch-block 内でもメッセージ ボックスを使用することをお勧めします。

catch (Exception ex)
{
    MessageBox.Show(ex.Message);
}

3.: 広告ネットワーク接続: あなたが示しているのは、PC からデバイスを見ることができるということだけですが、デバイスはネットワークを見ることができますか? デバイスで Web ブラウザを開き、ネットワーク上の任意のページにアクセスして確認します...

于 2013-11-18T20:50:27.767 に答える
0

これを C:\Users\clay\Documents\IISExpress\config\applicationhost.config に追加する必要がありました。

<binding protocol="http" bindingInformation="*:28642:shannon2" />

...そして、私のコードでこの「接続文字列」を使用します:

http://shannon2:28642/api/InventoryItems

これで接続できます。以前はとても近くにいたと思いますが(とても近く、それでも遠く離れていました)、うまくいくにはまさにこの組み合わせでなければなりませんでした。

于 2013-11-26T19:55:53.260 に答える