質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
XML

XMLは仕様の1つで、マークアップ言語群を構築するために使われています。

C++

C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

Q&A

解決済

1回答

2513閲覧

OS、VSが違う環境で作成されたmsxml6.dll使用のヘッダファイル使用について

JanTh1989

総合スコア87

XML

XMLは仕様の1つで、マークアップ言語群を構築するために使われています。

C++

C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

0グッド

0クリップ

投稿2019/05/15 15:23

編集2019/05/15 22:17

前提

Windows10、VisualStudio2010で作成されたmsxml6.dllをimportしてXML系ファイルを解析するC++のヘッダファイルが入っているプロジェクトが提供されました。
その中から、ヘッダファイルのみを取り出して、私の開発環境となるWindows7、VisualStudio2015のC++/CLIプロジェクトで、XML解析用部品として使用することとなりました。
そして、こちらをプロジェクトに足してみたところ、警告が発生しました。
警告コード:C4279
そのほか、そのヘッダファイルをVisualStudioで開いてみると、MSXML2::IXMLDOMElement型変数の"->"参照のものが概ね定義されていない旨のエラーが発生してしまっています。

ヘッダファイルに記載されているimport文は以下になります。

C++

1#import <msxml6.dll>

質問

①この現象は、どういった経緯から発生することものになるでしょうか。
・双方のプロジェクトのプラットフォームv100とv140などの違い
・OSが違うことによる、System32のmsxml6.dllのバージョン違い
(この場合、作っているプロジェクトをWindows10でビルドすると正常動作するのでしょうか?)
などが自身の調査結果から予想しているところなのです。
ただ、元プロジェクト側でビルドをしても、警告、エラーは特になかったため、プラットフォームの違いが有力そうに考えています。

②この現象の解決方法としては、どのようなものがあるでしょうか。
・msxml6.dllのバージョン変更
・OSを変える
などを予想しています。
そのほか、調査してみたところ、importにオプション追加やrenameを入れて対応などの情報は見かけたのですが、頂いたヘッダファイルの編集は動作保証を取る必要が出てくるなどもあり、基本的には客先に編集NGとされています。
ヘッダファイル編集が解決方法として必須となるのでしたら、せめてその旨だけでもご回答頂けないかと思います。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

atata0319

2019/05/15 15:27

実際の #import 文を記載いただければ、回答が得られるかもしれません。
JanTh1989

2019/05/15 16:09

ご指摘ありがとうございます。 import文を追記しました。
atata0319

2019/05/15 16:20 編集

せっかく追記していただいところ申し訳ないのですが、特殊なことをしなくても普通に再現しますね。ちょっと対応は考えてみます。
guest

回答1

0

ベストアンサー

ぱっと作ってみたら C4279 は発生しますが警告扱いで、動作するコードは普通に生成されてしまいました。警告だけが問題であればワーニングを除外してしまえばいいかと思いますが、IXMLDOMDocument 型変数が概ね定義されていないとかいう問題はこちらでは再現できませんでした。具体的にエラーになるコードを提示していただいた方が早いと思います。

①この現象は、どういった経緯から発生することものになるでしょうか。

VS2013 から /CLR オプション付きだと value が予約語となって警告になるようになったのが原因ですね。プラットフォームバージョンの違いと言うよりコンパイラの差です。

②この現象の解決方法としては、どのようなものがあるでしょうか。

Visual Studio を 2010 にダウングレードするのが一番お勧めですね。と言うのは警告だけであれば、オプションで無視すればよいのですが、他に発生している現象がこちらでは再現できていないので、適用しているヘッダファイル自体が Visual Studio 2015 に対応できていないのではないかと推測しています。こちらの再現環境の OS は Windows 10 x64 ですので、OS を変えても解決しないと思います。また、msxml6 のタイプライブラリは 7 と 10 で同じ内容になっているので、細かいバージョンを変えたとしても解決策とはなりえません。

msxml6 自体の警告だけであれば rename で解決できますが、これはあくまでも警告なので実行には影響してません。無視してよいレベルです。警告だけを避けるなら以下の記述となります。

C++

1#import <msxml6.dll> rename("value", "value2015")

投稿2019/05/15 16:59

atata0319

総合スコア881

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

JanTh1989

2019/05/15 22:30 編集

記載内容指摘に続き、早速の回答ありがとうございます。 コンパイラの違いが危惧されるところですか・・・。 既存の2015ソリューション(主にC#プロジェクト)にC++/CLIのプロジェクト追加という流れで今回の作業となっているので、ダウングレードは困りそうです。 こちらは検討してみます。 また、前提部分を一部変更しました。 参照していて定義されていないの結果になるのは、MSXML2を経由したものでした。 MSXML2::IXMLDOMElementPtr data; data->namexxxxxx ←ここでエラーが出ます(ifの条件などで使っています) ※xxxxxxは名称が現状明確に出てきませんでした 出社ののち、サンプルコードを出すようにします。
JanTh1989

2019/05/16 05:20 編集

状況が少し進展?しました。 デバッグを目的に、C#アプリソリューションにC++/CLIライブラリのプロジェクトを入れ込み、動かしてみたところ、動作することができました。 同様にそのプロジェクトでは、namexxxxxxが定義されていないなどの告知がでますが、動いてくれたみたいです。 赤線が出ていても、ビルドすれば解消するようなものだったのかもしれません。 そこで、本来の予定する動作となるC#アプリソリューションで生成したexeからApp.configのprivatePathを基にC++/CLIライブラリを呼び出すという動作を行ってみました。 結果、以下のようなアサート失敗ウィンドウが表示されました。 メッセージ:This function must be called in the default domain 場所: _atexit_m(Intptr func) 自作クラス名.XMLファイル解析関数(自作クラス名*, _com_ptr_t<_com_IIID<MSXML2::IXCMLDOMDocument2\,\&_GUID_2933bf95_7b36_11d2_b20e_00c04f983e60>>* lpxmlDoc) 自作クラス名.{ctor}(自作クラス名*, CStringT<wchar_t\,StrTraitMFC_DLL<wchar_t\,ATL::ChTraitsCRT<wchar_t>>>* strXMLFilePath) 同ソリューションからの呼び出しでは動けて、別ソリューションからだと動けない?と疑問符がでているところです。 C#側がAppDomain、App.configのprivatePathからDLL参照するようにしていることなどから、参照に詰まっているなどだろうか?と思っている状況になります。
atata0319

2019/05/16 14:29 編集

エラーメッセージから判断すると元のアプリケーションドメインと異なるドメインで動作させているのでしょうか? Windows 7 と言いますか .NET Framework 4.0 以降、.NET Framework のマルチバージョニング対応によってアプリケーションドメインが 1 つのスレッド上に複数存在している場合、CCW と RCW の動作がけっこう変わっていますが、C++/CLI とはいえ COM アクセス部分は C++ なので関係なさそうですね。 スタックトレースから読み取れるのは上記とは異なりデバッグのアサーションに失敗している感じがしますね。msxml が正しく初期化できているかなどを確認していただいた方が良いかもしれません。アプリケーションのビット数や CoInitialize 関連処理が正しく呼び出せているかどうかというところですね。
JanTh1989

2019/05/19 13:21

いくつか試してみたところ、本番環境のAppDomainのCreateInstanceAndUunwrap関数を使用したDLL呼び出しの手法を取ると、上記のアサート失敗が発生することが分かりました。 また、提供されているヘッダファイルでは、CoIniializeがそもそも入っていないようです。 ひとまずCoIntializeを入れて再動作確認を予定しています。 ただ、CoIntializeが入っていないからが原因とされているなら、AppDomainを経由しない、参照設定による静的参照であれば動くという道理には疑問です。 明日午前にまた会社で試してみます。
atata0319

2019/05/19 16:39

すっかり忘れてましたが、CLR プロジェクトの場合、CoInitialize(Ex) はどこかのタイミングで暗黙的に呼び出されます。フォームアプリの場合、STAThread 属性が付くので CoInitializeEx がフォーム作成前に自動的に呼び出されてアパートメントスレッドモデルとなりますが、CreateInstanceAndUunwrap の呼び出し先は暗黙的に MTA になります。ただし、CoInitializeEx 呼び出しは遅延されるため、実際にコンポーネント作成する際にエラーになっているのではないでしょうか?この場合、CreateInstanceAndUunwrap を呼び出す処理を STA ではない別スレッドで呼び出すと解消されると思われます。
JanTh1989

2019/05/20 04:27 編集

STA,MTAなども見てみましたが、思っている成果が出てくれませんでした。 調査を進めてみたところ、以下のサイトで、アンマネージがAppDomainに対して良い結果が出ないことの記載がされていました。 http://www.windows-tech.info/13/74e4948c5792075a.php ひとまずAppDomainの動作は補正し、Assemblyクラスからの呼び出し方法に変更しようか、ということになりました。 (今回FIX品ではなく、プロトタイプ相当で良いようなので、課題として残して今回妥協という感じです。) アンロードはしたいので、やはりAppDomainは使いたいところではありますので、 受領ヘッダをCLR化してくれないものか、などの要望や、こちらで変更しても良いかなどを交渉しつつ、 今後の対応を検討しようと思います。
JanTh1989

2019/05/20 14:30

数日かかってしまいましたが、いくつもご回答いただきありがとうございました。 Assemblyで動くことまでは確認が取れましたので、一旦処理を固めてしまおうと思まいます。 プロトタイプ後に本開発も待っているので、そのあたりから再検討するようにします。 ありがとうございました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問