16

すべてのクライアント WCF 構成 (<system.serviceModel>) をメインの app.config ファイルから別の XML ファイルに削除するという特定の要件があります。私が見たい動作は、File="" ディレクティブを使用して appSettings セクションで利用できるものと似ています。実際、消費されるサービスごとに個別のファイルを指定できるようにしたいのですが...

XML ファイル (または一連のファイル) から構成データを読み取るカスタム ChannelBuilder ファクトリを構築できることはわかっていますが、クライアントによって構成データが「自動検出」されるようにしたいと考えています。

いくつかの基本的なGoogle検索では、これは不可能であることが示唆されているようですが、SOからのビューを取得したかったのです-ここで誰かが私が見つけられなかったものを知っていますか? :)

編集 ::

Tim Scott と davogones の両方が可能な提案を思いつきましたが、system.serviceModel セクションのコンポーネント セクションを別のファイルに分割することに依存するものです。これは私が探しているものではありませんが (サービスごとに 1 つのファイルで、各サービスとそれに関連する要素を別々に定義したいと思います)、オプションです調べて思ったことをお伝えします。

4

8 に答える 8

17

configSource を使用して、WCF 構成を分離できます。手順はこちら:

http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx

もう 1 つのオプションは、WCF サービスをプログラムで構成することです。

于 2009-01-28T07:37:44.283 に答える
6
using System;
using System.Configuration;
using System.IO;
using System.ServiceModel;
using System.ServiceModel.Configuration;

namespace ConsoleHost
{
    public class CustomServiceHost : ServiceHost
    {
        public CustomServiceHost(string customConfigPath, Type serviceType, 
            params Uri[] baseAddresses)
        {
            CustomConfigPath = customConfigPath;
            var collection = new UriSchemeKeyedCollection(baseAddresses);
            InitializeDescription(serviceType, collection);
        }

        public string CustomConfigPath { get; private set; }

        protected override void ApplyConfiguration()
        {
            if (string.IsNullOrEmpty(CustomConfigPath) ||
                !File.Exists(CustomConfigPath))
            {
                base.ApplyConfiguration();
            }
            else
            {
                LoadConfigFromCustomLocation(CustomConfigPath);
            }
        }

        void LoadConfigFromCustomLocation(string configFilename)
        {
            var filemap = new ExeConfigurationFileMap
            {
                ExeConfigFilename = configFilename
            };
            Configuration config = ConfigurationManager.
                OpenMappedExeConfiguration(filemap, ConfigurationUserLevel.None);

            var serviceModel = ServiceModelSectionGroup.GetSectionGroup(config);

            bool loaded = false;
            foreach (ServiceElement se in serviceModel.Services.Services)
            {
                if (se.Name == Description.ConfigurationName)
                {
                    LoadConfigurationSection(se);
                    loaded = true;
                    break;
                }
            }

            if (!loaded)
                throw new ArgumentException("ServiceElement doesn't exist");
        }
    }
}

このクラスの後は、サービス ホストを初期化するために通常使用するのと同じように使用します。

myServiceHost = new CustomServiceHost(ConfigFileName, typeof(QueryTree));

myServiceHost.Open();

于 2010-12-31T11:45:45.680 に答える
5

私はすべてのサービス設定をプログラムで構成する傾向があります。

私のクライアントは実際にはXMLを理解するタイプではなく、構成ファイルを古いINIスタイルのようにするように求められました。

これは簡単に実行できます(INIファイルコードの読み取りは含まれていません)。

        // create the URI which is used as the service endpoint
        Uri tcpBaseAddress = new Uri(
                string.Format("net.tcp://{0}:{1}",
                    LocalIPAddress.ToString(), GeneralPortNumber));

        // create the net.tcp binding for the service endpoint
        NetTcpBinding ntcBinding = new NetTcpBinding();
        ntcBinding.Security.Mode = SecurityMode.None;
        System.ServiceModel.Channels.Binding tcpBinding = ntcBinding;

        // create the service host and add the endpoint
        Host = new ServiceHost(typeof(WordWarService), tcpBaseAddress);

ホスト(さらに言えばクライアント)をプログラムで構成できるので、選択した方法(データベース、xml、クレイジーテキストファイルなど)で設定を提供することを妨げるものは何もありません。

于 2009-01-27T19:29:02.273 に答える
3

あなたに役立つかもしれないこの記事を見つけました。試したことはありませんが、かなり簡単なようです。

http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx

" configSource 属性は、外部構成ファイルをサポートするために .NET Framework 2.0 で最初に導入されました。この属性を任意の構成セクションに追加して、そのセクションの外部ファイルを指定できます。

残念ながら、system.serviceModel セクション グループはこの属性をサポートしていません。追加しようとすると、次の例外が発生します。

名前が予約済みの接頭辞「config」または「lock」で始まるため、属性「configSource」を指定できません

私が見つけたのは、サービス、動作、バインディングなど、system.serviceModel の下のさまざまなセクションでこの属性を使用できることです。"

于 2010-06-25T12:55:09.913 に答える
2

私は同じことをしたいと思っていました-基本的にはさらに一歩:WCF構成をデータベーステーブルに配置します(変更できるため-ホストプロバイダーのファイルシステムにアクセスして構成ファイルを変更することはできません:-() 。

残念ながら、これは単純ではないようです。

基本的には、必要に応じて構成を処理できる独自のカスタム「ServiceHost」子孫を作成する必要があります。

これは、カスタム構成の場所からWCF構成をロードする例です。

これはあなたを動かすかもしれませんか?いつか「データベーステーブルから設定をロードする」ことを理解できるようになることを私はまだ望んでいます.....仕事で一週間静かにする必要があると思います:-)

于 2009-01-27T18:18:15.927 に答える
1

System.ServiceModel.Configuration.ConfigurationChannelFactoryet alは、System.Configuration.Configurationインスタンスからの構成の読み取りをサポートしています。<system.servicemodel ...つまり、web / app.configから参照しなくても、専用のファイルにデータを入れることができます。クライアントごとに1つずつ、複数の構成ファイルを作成できます。

SharePoint 2010は、サービスアプリケーションモデルでこれを過度に使用します。各サービスプロキシは、必ずしもweb.configまたはapp.configである必要はなく、そこからも参照されない専用の.configから設定を読み取ります。

于 2010-06-25T13:13:47.513 に答える
0

次のようにできます。

<system.serviceModel configSource="wcf.config"/>

サービス モデルのセクションを切り取って、別のファイルに入れるだけです。セクション全体を別の構成ファイルに入れる必要があります。この方法を使用すると、セクションを複数のファイルにまたがらせることはできません。

于 2009-01-27T22:26:36.500 に答える
0

私は、あなたがここで話しているのと同じように機能するアプリケーションを使用しています。複数のプロジェクトに複数の WCF サービスがあり、それらの構成情報はすべて単一の構成ファイルに存在します。

私の会社が選択した解決策は、構成ファイルからサービス構成を読み取り、読み取った値に基づいてバインディング、動作などをプログラムでセットアップすることでした。構成ファイルの値は、WCF サービスで通常見られる構成に準拠していません。実行時にすべての構成を行うためにヘルパー クラスで簡単に使用できるように設計されています。

とは言っても、私はそれを行うのがまったく好きではありません.カップリングが多すぎて、かなり面倒です.

ただし、それが可能であることを示しています。これは、設計において考慮すべきことの 1 つです。

于 2009-01-27T16:47:31.397 に答える