リソース エディター上で ActiveX コントロールのメニューが表示されない現象について

こんにちは、Visual Studio サポートチームです。 今回は、Visual C++ 6.0 では使用できていたものの、現行の Visual C++ では使用できなくなっている機能の一つについてご案内します。   リソース編集時の ActiveX コントロールのメニューについて Visual C++ 6.0 では、リソース エディターを使用したダイアログ リソースの編集時に、ダイアログに配置された ActiveX コントロールを右クリックすることで、コンテキスト メニューに対応する Verb 表示することが可能となっていました。また、同様の機能は、現行バージョンの Visual Studio における .NET Framework アプリケーションの Windows Form のデザイン画面でも利用可能です。 しかしながら、現行バージョンの Visual C++ のリソース エディターではこの機能が廃止されており、ActiveX コントロール側で適切に EnumVerbs メソッドを実装していた場合であっても、メニューに表示することができなくなっています。このため、編集時に利用可能なメニューとして ActiveX コントロールが提供していた拡張機能などが使用できない場合があります。 この動作は、ActiveX コントロール側の実装の問題などではなく、Visual C++ における機能の廃止に起因しています。また、現在のところ リソース エディターで本機能が改めて提供される予定はありません。 Visual C++ 6.0 で本機能を利用されていたご利用者様や ActiveX…


CDatabase クラスで発生するメモリ リークの問題について

こんにちは、Visual Studio サポート チームです。 今回は、MFC の CDatabase クラスを特定の方法で使用した場合に発生するメモリ リークの問題についてご案内します。この現象は、Visual Studio 2012 以降のバージョンに含まれる MFC で発生します。   現象 CDatabase クラスの同一のオブジェクトに対して OpenEx メソッドと Close メソッドを使用するとメモリ リークが発生し、メモリ使用量が増加し続けます。   原因 この現象は Visual Studio 2012 で追加された、CDatabase クラスの接続文字列の暗号化を行う処理に起因しています。 OpenEx メソッドで接続文字列を暗号化するためのメモリが割り当てられますが、再度 OpenEx メソッドが呼び出された際にメモリを解放せず、新たに割り当てを行っていました。 なお、弊社ではこの問題を MFC の不具合と認識しており、Visual Studio の将来のバージョンで修正を検討しています。 弊社製品の不具合によりご迷惑をおかけし、大変申し訳ございません。   対処方法 以下のいずれかの方法により、メモリ リークの問題に対処することが可能です。 同一のオブジェクトに対して OpenEx メソッドを複数呼び出さないようにする。(OpenEx メソッドで割り当てたメモリはデストラクタで解放されます。) CDatabase クラスを継承し、OpenEx メソッドを修正する。 上記 2. の具体的な実装例を以下にご案内いたします。…


Visual Studio 2015 / 2017 で発生する可能性がある _snscanf_s 関数の問題について

こんにちは、Visual Studio サポート チームです。 今回は、Visual Studio 2015 / 2017 で発生する可能性がある _snscanf_s 関数の問題とその影響についてご案内します。 この問題は以下のように Stack Overflow でも報告されておりましたが、この度、複数のお客様から弊社へお問い合わせをいただきましたので本ブログでもご紹介させていただきます。より多くの開発者様のお役に立てましたら幸いです。   VC2015で、double変数ddx_textのトラブル https://ja.stackoverflow.com/questions/16592/vc2015%E3%81%A7-double%E5%A4%89%E6%95%B0ddx-text%E3%81%AE%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB   現象 _snscanf_s 関数で浮動小数点書式を指定した場合、先頭が ‘0’ で始まる場合に終端文字 ‘\0’ が正しく扱われず、_snscanf_s 関数に指定した文字数全体に対して解析が行われます。例えば、文字配列の内容が “0\02\0” であった場合、_snscanf_s 関数で期待される結果は 0 ですが、不具合により実際には 2 が返されます。 また、MFC ライブラリの DDX_Text 関数では内部で _snscanf_s 関数を使用しているため、この問題の影響を受けて、入力した値と異なる値が浮動小数点型変数に格納される可能性があります。エディット コントロールに “0” を入力した場合、文字列バッファの “0\0” 以降の値はスタックの状態によって不定となるため、DDX_Text 関数で変数に格納される値も不定となります。   原因 Visual Studio 2015 以降で利用されている新しい C ランタイム…


Windows 10 Anniversary Update 以前の OS 上で、Visual Studio 2017 を使用して .NET Framework 4.7 アプリケーションを開発する方法について

こんにちは、 Visual Studio サポート チームです。 今回は、Windows 10 Anniversary Update 以前の OS 上で、Visual Studio 2017 を使用して .NET Framework 4.7 アプリケーションを開発する方法をご紹介します。   背景 Windows 10 Creators Update (バージョン 1703) 上で Visual Studio 2017 を使用すると、特定のパッケージなどをインストールしなくても、.NET Framework 4.7 アプリケーションを開発することが可能です。これは、Windows 10 Creators Update  には .NET Framework 4.7 が同梱されているためです。 一方、Windows 10 Anniversary Update (バージョン 1607) 以前の OS には .NET Framework 4.7…


.NET Framework のコンソール アプリケーションで STA スレッドから XmlSerializer クラスを利用する場合の注意事項

こんにちは、Visual Studio サポート チームです。 今回は、.NET Framework のコンソール アプリケーションで STA 属性を指定したスレッドから、XmlSerializer クラスを利用するなどして直接、または間接的に COM コンポーネントが利用される場合の注意事項についてご案内します。   注意事項 STA に属する COM コンポーネントを作成した場合は、COM のガイドラインに則り、対象の STA スレッドでは定期的にメッセージ ポンプを動作させてウィンドウ メッセージを処理する必要があります。メッセージ ポンプの処理を実装していないと、対象 STA の外部からは COM コンポーネントにアクセスすることができません。このため、特に .NET Framework のコンソール アプリケーションでは、ファイナライザー スレッドが対象の STA スレッドと通信できずにハング アップしてしまい、メモリ リークなどの問題を引き起こす可能性があります。 STA スレッドがメッセージ ポンプを実装する必要がある点については以下のドキュメントに解説がありますのでご参照ください。 [OLE] OLE スレッド モデルの概要としくみ https://support.microsoft.com/ja-jp/help/150777/info-descriptions-and-workings-of-ole-threading-models   具体例 .NET Framework の XmlSerializer クラスでは、コンストラクタの特定のオーバーロード (*1) を利用すると、内部でアセンブリを生成してキャッシュする処理が行われます。この処理では内部的に…


Visual Studio 2017 で Visual C++ ”14” ランタイム ライブラリをインストーラーに含めた場合に発生する問題について (2)

こんにちは、Visual Studio サポート チームです。 今回は、先日ご案内した以下の記事に関連して、新しいバージョンのVisual C++ ランタイム ライブラリをご利用される際に発生する可能性がある問題とその対処方法をご案内いたします。   Visual Studio 2017 で Visual C++ “14” ランタイム ライブラリをインストーラーに含めた場合に発生する問題について https://blogs.msdn.microsoft.com/jpvsblog/2017/06/22/vs2017-vc14-installer/   現象 作成したパッケージに含まれる Visual C++ “14” ランタイム ライブラリよりも、さらに新しいバージョンの Visual C++ “14” ランタイム ライブラリが既にインストールされているにもかかわらず、インストーラーの実行時にランタイム ライブラリのインストールが求められる。   原因 Visual C++ ランタイム ライブラリ用の Product.xml では、対象の製品がインストールされているかどうかの検証に Product Code を使用します。 この検証では、対象の Product Code の製品がインストールされているかどうかを調べますが、Visual C++ ランタイム ライブラリはアップデートごとに新しい Product Code を採番しているため、インストール対象のランタイム ライブラリよりも新しいバージョンのライブラリが既にインストールされていたとしても、それらは検出されないため、ライブラリのインストールが必要と判断される動作となります。…


Visual Studio 2017 で Visual C++ “14” ランタイム ライブラリをインストーラーに含めた場合に発生する問題について

こんにちは、Visual Studio サポート チームです。 今回は Microsoft Visual Studio 2017 に含まれる Visual C++ “14” ランタイム ライブラリを必須コンポーネントに含めてインストーラーを作成する場合に発生する可能性がある問題と対処方法をご案内いたします。 <2017 年 7 月 4 日追記> Product.xml に指定する Product 属性の内容につきましては、Visual Studio 2017 RTMに対する値でのご案内となっております。 ダウンロード ページから入手していただける最新の Visual C++ 2017 Redistributable のバージョンに対する Product 属性の値につきましては、現在正しい値を確認中です。 確認の結果が得られ次第この記事にてご案内いたしますので、大変恐れ入りますが今しばらくお待ちください。 <2017 年 7 月11 日修正> Visual C++ “14” ランタイム ライブラリのインストーラーの入手先に関する記述を修正しました。   現象 a) [アプリケーションと同じ場所から必須コンポーネントをダウンロードする] を指定して Visual C++…


Visual Studio 2012 以降のバージョンにおけるセットアップ プロジェクトについて

こんにちは、Visual Studio サポート チームです。 今回は Visual Studio 2012 以降のバージョンにおけるセットアップ プロジェクトの扱いと、セットアップ プロジェクトの作成にご利用いただける拡張機能についてご案内します。   Visual Studio を使用して Windows インストーラー形式のインストーラー パッケージを開発する方法として、Visual Studio 2010 以前のバージョンではセットアップ プロジェクトが用意されていましたが、Visual Studio 2012 以降ではセットアップ プロジェクトは提供されておらず、多くのお客様では InstallShield などのサードパーティ製品をご利用いただいています。 しかしながら、従来のようにセットアップ プロジェクトを開発されたいというお客様からのご要望も多いことから、Visual Studio 2013 以降を対象として、Visual Studio 2010 以前のセットアップ プロジェクトと同等の機能を提供する Visual Studio 拡張機能が以下のとおり公開されています。   Microsoft Visual Studio 2013 Installer Projects https://marketplace.visualstudio.com/items?itemName=UnniRavindranathan-MSFT.MicrosoftVisualStudio2013InstallerProjects Microsoft Visual Studio 2015 Installer Projects https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2015InstallerProjects…


Visual C++ 2010 の setlocale 関数の問題について

こんにちは、Visual Studio サポート チームです。 今回は、Visual C++ 2010 で確認されている setlocale 関数の問題と対処方法についてご案内します。なお、本問題は Visual C++ 2012 以降のバージョンでは修正されています。   現象 Visual C++ 2010 の setlocale 関数において、以下のような現象が発生する場合があります。   a) 引数に不正なロケール (例 : “Japanese_Japan.9326389”) を指定しても、NULL ポインターが返却されない b) 上記 a) の問題が発生した状態から、正しいロケールを指定して setlocale 関数を実行しても、処理に失敗して NULL ポインターが返却される   原因 本現象は Visual C++ 2010 の setlocale 関数の不具合に起因して発生しています。製品の不具合でご迷惑をおかけしておりますこと深くお詫び申し上げます。本不具合は Visual C++ 2012 以降のバージョンの製品では修正されています。   対処策 a) の問題については、正しいロケールを指定するようアプリケーションを修正してください。ロケールの詳細については以下のドキュメントをご参照ください。…


Visual C++ の同時実行ランタイムを利用するアプリケーションがハングアップする問題について

こんにちは、Visual Studio サポート チームです。 今回は、Visual C++ で提供されている同時実行ランタイム (ConcRT : Concurrency Runtime) で確認されている問題と対処方法についてご案内します。この問題は Visual C++ 2010、2012、2013 で発生する可能性がありますが、Visual C++ 2015 以降では発生しません。   現象 ConcRT を使用するアプリケーションで、EnterCriticalSection 関数など、Win32 の同期オブジェクトを直接使用する処理を行うと、スレッド間でデッドロックが発生して、プログラムがハングアップする場合があります。   原因 Visual C++ 2013 以前の ConcRT では、Win32 の同期オブジェクトを直接利用しない形で内部の同期処理を実現していました。 この関係で、アプリケーション側のコードで Win32 の同期オブジェクトを直接使用すると、ConcRT 内の同期処理と アプリケーションで実装した同期処理の間でデッドロックが発生する場合があります。   対処方法 Visual C++ 2015 以降の ConcRT では同期処理の実装が見直され、Win32 の同期オブジェクトを直接的に利用する方法で統一されているため、この問題は発生しません。このため、可能であれば Visual C++ 2015 以降のバージョンへのバージョン アップをご検討ください。 バージョン アップを行うことが難しい場合は、Win32…