MSDN によると、今ぶつかった壁は固いようです。
http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getentryassembly.aspx
マネージ アセンブリがアンマネージ アプリケーションから読み込まれた場合、GetEntryAssembly メソッドは null を返すことができます。たとえば、アンマネージ アプリケーションが C# で記述された COM コンポーネントのインスタンスを作成する場合、C# コンポーネントから GetEntryAssembly メソッドを呼び出すと null が返されます。これは、プロセスのエントリ ポイントがマネージ アセンブリではなくアンマネージ コードであるためです。
ResourceDictionaryandの使用を開始するまでMergedDictionaries、冗長な XAML がたくさんありました。<controls:MyCustomControl.Resources>これだけを残して、すべて削除しました：
<controls:GlossyContentControl.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="pack:application:,,,,/MyApp.Namespace;component/Themes/generic.xaml" />
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</controls:GlossyContentControl.Resources>
プロジェクトをビルドすることはできますが、光沢のあるコンテンツ コントロールのいずれかを使用するウィンドウのデザイナーを開くと、IOExceptionが表示されます。"MyShinyNewControl" のインスタンスを作成できません。リストには、ソリューションがビルドされますが、 Cannot create an instance of "MyShinyNewControl" とも表示されます (ただし、COM を介して実行すると、同じ IOException で爆発します)。
プロジェクトは、一連のクラスライブラリを含むソリューションのプレゼンテーション レイヤーであるクラス ライブラリです。主要なものは、いくつかの VB6 コードによってインスタンス化されるオブジェクトを公開します。共有リソース/スタイルの概念を紹介する前は、それは魔法のように機能していましたが、どこにでも大量の冗長な XAML がありました。
COM を介して動作させるための回避策はありますか、または回避策はすべてのスタイルをどこにでも複製することですか?
デザイナーでの例外のスタック トレース:
リソース 'themes/generic.xaml' が見つかりません。MS.Internal.AppModel.ResourcePart.GetStreamCore (FileMode モード、System.IO.Packaging.PackagePart.GetStream での FileAccess アクセス (FileMode モード、FileAccess アクセス) で System.IO.Packaging.PackWebResponse.CachedResponse.GetResponseStream() で System. IO.Packaging.PackWebResponse.GetResponseStream() で System.IO.Packaging.PackWebResponse.get_ContentType() で MS.Internal.WpfWebRequestHelper.GetContentType(WebResponse 応答) で MS.Internal.WpfWebRequestHelper.GetResponseStream(WebRequest 要求、ContentType& contentType) で System System.Windows.Baml2006.WpfSharedBamlSchemaContext.b__1c4 の .Windows.ResourceDictionary.set_Source(Uri 値) (オブジェクト ターゲット、オブジェクト値) System.Windows.Baml2006.WpfKnownMemberInvoker.SetValue(オブジェクト インスタンス、
実行時の XamlParseException (フランス語から翻訳された例外) のスタック トレース:
型参照は、'{clr-namespace:MyApp.Common.Controls}GlossyContentControl' という名前の型を見つけることができません。MS.Internal.Xaml.Context.ObjectWriterContext.ServiceProvider_Resolve (文字列 qName) で MS.Internal.Xaml.ServiceProviderContext.System.Windows.Markup.IXamlTypeResolver.Resolve (文字列 qName) で System.Xaml.Replacements.TypeTypeConverter.ConvertFrom (ITypeDescriptorContext) System.Xaml.XamlObjectWriter.Logic_CreateFromValue(ObjectWriterContext ctx, XamlValueConverter`1
1 ts, Object value) at MS.Internal.Xaml.Runtime.ClrObjectRuntime.CreateFromValue(ServiceProviderContext serviceContext, XamlValueConvertertypeConverter 、オブジェクト値、XamlMember プロパティ、文字列 targetName、IAddLineInfo lineInfo)
奇妙なことに、任意の光沢のあるコンテンツ コントロールのデザイナーを開くと、スタイルが適用され、すべてが適切に表示されます。しかし、そのようなコントロールをホストするウィンドウはそれらをレンダリングできません。
ソリューションの概要は次のとおりです。
- VB6 ActiveX dll はマネージド コードをインスタンス化し、C# で記述された機能を実行します。
- C# 機能は、データをフェッチし、ビュー モデルを定義し、WPF ウィンドウをインスタンス化します
- WPFウィンドウが表示され、すべてが機能します
app.xaml は関係なく、コードはWindowオブジェクトをインスタンス化して呼び出すだけShowDialog()で、機能しました。
共有リソースの紹介のある時点で、 が必要であると思われたapp.xamlので、それを作成し、代わりにApplication Definitionそのビルド アクションをに設定しましたPage。これを行うと、一部のオブジェクトをそのカスタム コンテンツ コントロールのインスタンスGlossyContentControlに置き換えるために使用したmyを使用できるようになりました。UserControl
私はまだエントリ ポイントも WPF アプリケーション自体も持っていないので、WPF は私がここで何をしようとしているのかを理解するのに苦労していると思います。まだ試していないことの 1 つは、カスタム エントリ ポイントを使用して実際の WPF アプリケーション (別のアセンブリ) を作成することです。そのため、クラス ライブラリは、ウィンドウがインスタンス化されるのを待つだけのある種の「アイドル」モードで WPF アプリケーションを「起動」できます。と表示されます。これはうまくいくでしょうか、それとも時間の無駄でしょうか?