問題タブ [app-startup]

Azure アプリケーションの構成値をより簡単に構成するためのサービスを作成しようとしています。現在、7 つの異なる環境で同じ設定を変更したい場合は、7 つの異なる .cscfg ファイルで変更する必要があります。

私の考えは、アプリケーションがその構成値を照会する Web サービスを作成できるということです。Web サービスは、Azure テーブルなどのストレージの場所を調べて、正しい構成値を返します。

これを非常に簡単に展開スクリプトに統合することができました (アプリのパッケージ化、設定の取得、cscfg ファイルの変更、展開)。これに関する問題は、設定を変更するたびに、再デプロイする必要があることです。

最後に質問 - アプリケーションの起動後、ロールの起動時に構成設定を取得する方法はありますか? もちろん、アプリを起動するには基本的な設定が必要です。アプリケーションの起動時に Web サービスから設定を取得するとよいでしょう。アプリケーションを再デプロイする必要がなく、それらを自動的に取得する方法はすべて機能します。

前もって感謝します！

アプリの更新をアプリストアにリリースしました。新しいバージョンは、シミュレーターと開発デバイスで非常にうまく機能しますが、アプリストアから更新を行うと、アプリを削除して再インストールしない限り、起動時にアプリがクラッシュします。開始画面しか表示されず、1 秒後にアプリがクラッシュします。それに関する他のトピックを検索したところ、Core Data Migration である可能性があることがわかりましたが、InMemoryStore でのみ Core Data を使用しています。データベースの移行は必要ですか?

開発中のアプリケーションの 1 つに、Spring Bean である独自のキャッシュ マネージャーがあります。この Web アプリケーションが JBoss (具体的には EAP 6.0) で起動すると、init メソッドが呼び出されます。

アプリケーションはまだ開発中であるため、開発者がアプリケーションを起動すると、キャッシュされると言及されている特定のデータベース マスター データ テーブルが開発者の db インスタンスで誤って使用できない場合があります。

このような場合に回復不能な例外が発生した場合に Web アプリケーションを停止して、アプリケーションが起動しないようにする方法はありますか?

最初に起動時に言語を選択するウィンドウが表示されるときに、私はWPFアプリケーションを持っています。したがって、App.xaml では次のようになります。

WindowLanguage で:

動作しますが、不要なウィンドウが初期化されています。

次の方法について考えます： App.xaml.cs

StartupUri を変更するこの 2 番目の方法は、優れているかどうか? 私の状況 (アプリの最初の起動時に WindowLanguage を開く) に最適な方法はどれですか?

Windows の起動時に特定のプロセスを実行する必要があるアプリケーションを作成しました。プログラムへのパスを受け取り、それをレジストリに追加することでそれを行うメソッドを作成しました。これは方法です：

このコードは機能していますが、問題は、追加したプロセスがデスクトップの読み込みを停止させているように見えることです。デスクトップの読み込み中に背景の壁紙が読み込まれますが、アイコンは読み込まれません。タスク マネージャーにアクセスできます。起動プログラムに追加したプロセスを閉じると、デスクトップが「フリーズ」し、すべての読み込みが完了します。

奇妙なことに、プロセスを閉じても、デスクトップの読み込みが完了した後、プロセスが再び実行され、すべてが正常に実行されます。つまり、何らかの理由で 2 回実行されます。

私の質問は、デスクトップの読み込みが完了した後にのみプロセスを実行するように設定するにはどうすればよいですか?

ほとんどのデバイスで正常に動作するストアにアプリがありますが、Android 4.1.2 (バージョン JZO54K.I9100XWLSS) を実行している特定の Samsung Galaxy S2 で動作します。

Googleまたは統合したcrashlyticsからのクラッシュレポートなしで、起動時にクラッシュします。実際にはクラッシュではなく、電話がシャットダウンするまでメイン アクティビティがしばらく点滅するだけです 。

ユーザーからのデバイスなので、ローカルでデバッグできません。(無線で電話からライブ logcat ストリームを取得するものはありますか?)

特定の 1 つのデバイスのみに影響する起動時の「クラッシュ」を経験した人はいますか? 私はSGS2を持っていますが、問題なく動作します。メモリの問題など、このようなクラッシュを引き起こすハードウェア上の理由はありますか。

この問題は、ソース コードやクラッシュ レポートがなければ解決できない可能性が高いことはわかっていますが、誰かが正しい方向に向けてくれるかもしれません。

敬具、マイク

現在、C#/.Net/MVC アプリケーションで DI を処理するために Ninject を使用しています。サービスのインスタンスの作成を追跡すると、ライフサイクル中にサービスがかなり頻繁に呼び出されて構築されることがわかります。そのため、サービスをインスタンス化してキャッシュし、キャッシュされたサービスをチェックしてから別のサービスをインスタンス化する必要があります。コンストラクターは非常に重い場合があります)。

サービスは一意のコンストラクター引数を必要としないため、これはばかげているように思えます。そのため、一度インスタンス化するだけで、アプリケーション スコープ全体で十分です。

私が簡単な代替手段として行ったこと（今のところ概念実証のために、それが機能するかどうかを確認するためだけです）は...

• すべてのサービス インターフェイスをプロパティとして持つ静的クラス (AppServices と呼ばれる) を作成しました。
• このクラスに、サービス ライブラリから各サービス インターフェイスの直接実装をインスタンス化する Init() メソッドを指定します。これは、Ninject (または他の DI ハンドラー) を使用していた場合に、それらをカーネルにバインドすることを模倣しています。

例えば

• App_Start で、Init() メソッドを呼び出して、一度だけインスタンス化される、グローバルにアクセス可能なサービスのリストを作成します。
• それ以降、サービスのインスタンスが必要になるたびに、AppServices から取得しています。このようにして、必要のない新しいインスタンスを作成し続ける必要がなくなります。

例えば

var IMyService _myService = AppServices.MyService;

これは正常に機能し、まだ問題が発生したことはありません。私の問題は、これが単純すぎるように見えることです。アプリケーション スコープで静的クラスを作成するのは、ほんの数行のコードです。Ninjectが必要とすることを正確に実行しますが、(私の目的では私には思われる)はるかにクリーンでパフォーマンスを節約する方法で、なぜNinjectが必要なのですか? つまり、これらの複雑な依存性注入ハンドラーが作成されるのには理由がありますよね? 私の「単純な」DI の解釈には何か問題があるに違いありません。

サービス インスタンス用にグローバルな静的コンテナーを作成することがなぜ悪い考えなのか、誰でも教えてもらえますか? また、Ninject (または他の DI ハンドラー) が必要な理由を正確に説明できますか? 私は DI の概念を理解しているので、DI の優れた点を説明しようとしないでください。知っている。私の App_Start メソッドとは大きく異なる内部での動作を正確に知りたいです。

ありがとう