Visual Studio サポート チーム blog https://docs.microsoft.com/archive/blogs/jpvsblog/feed.xml Visual Studio / .NET Framework をご利用いただいている開発者の方に役立つ情報をお届けします。 Sun, 06 Jan 2019 23:30:48 GMT ja hourly 1 Visual Studio サポート チーム ブログ終了のお知らせ https://docs.microsoft.com/archive/blogs/jpvsblog/announce Mon, 07 Jan 2019 08:30:47 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2425 Visual Studio サポート チーム フォーラム

  これまで多くのお客様に本ブログをご覧いただき、誠にありがとうございました。 開発者様のお役に立てるよう情報発信を続けてまいりますので、今後ともどうぞよろしくお願いいたします。]]> .NET Framework の更新プログラムを手動でインストールする際の注意事項について https://docs.microsoft.com/archive/blogs/jpvsblog/netfx-update Mon, 13 Aug 2018 10:03:10 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2395 こんにちは、Visual Studio サポート チームです。 今回は、.NET Framework の更新プログラムの構成と、更新プログラムを手動でインストールする場合の注意事項についてご案内します。 なお、Windows Update の自動更新や WSUS (Windows Server Update Services) をご利用の場合には、本内容は該当しません。また、Windows 10 や Windows Server 2016 については、.NET Framework の更新プログラムは OS の更新プログラムに含まれる形で提供されているため、本内容は該当しません。   .NET Framework の更新プログラムの構成について こちらのドキュメントで紹介されているように、.NET Framework の更新プログラムは、「セキュリティおよび品質ロールアップ」、「セキュリティのみの更新プログラム」、「品質ロールアップ プレビュー」の 3 種類の形態で提供されています。 これらの更新プログラムのパッケージは、以下のように、「(A) .NET Framework の各バージョン向けのパッケージを対象 OS ごとにまとめた KB」 と、「(B) 更新プログラムの実体の KB」から構成されています。   <更新プログラムの構成> (A) 各バージョン向けを OS ごとにまとめた KB

(B-1) .NET Framework 4.5.2 向けの KB (B-2) .NET Framework 4.6 以上向けの KB (*1) (B-3) .NET Framework 3.5 向けの KB (B-4) 問題発生時の修復用プログラム (msipatchregfix.exe) (*2) (B-5) .NET Framework 4.7 の前提となるKB4019990 (未適用の場合、B-2 の適用時に必要な場合あり)

  (*1) .NET Framework 4.6 以上では更新プログラムは共通化されており、例えば、.NET Framework 4.6 と .NET Framework 4.7.2 でも更新プログラムは共通です。 (*2) 手動で更新プログラムをインストールする場合、msipatchregfix.exe は不要です。   一例として、Windows 7 および Windows Server 2008 R2 向けの 2018 年 5 月の 「セキュリティおよび品質ロールアップ (KB4099633)」の場合は、以下の 5 つのファイルから構成されており、Microsoft Update カタログ上から公開されています。

  前述の順に並べると以下のとおりです。   (A) 2018-05 Security and Quality Rollup for .NET Framework 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1 on Windows 7 and Server 2008 R2 for x64 (KB4099633)

(B-1) ndp45-kb4096495-x64_41a96e508184f9dac887e02a2c1caf75842a4e95.exe (B-2) ndp47-kb4096418-x64_09433765a4d90e1a2295da0a1a1cf9b1b8a64f56.exe (B-3) windows6.1-kb4095874-x64_13904512d1614ba1a336061e90f7078becf3be5a.msu (B-4) msipatchregfix-amd64_5011cb29b096fb674a4795ee8fc2f7fdad33863a.exe (B-5) windows6.1-kb4019990-x64_35cc310e81ef23439ba0ec1f11d7b71dd34adfe5.msu

  例えば、対象の環境に .NET Framework 3.5 と .NET Framework 4.5.2 がインストールされている場合は、上記の (B-1) と (B-3) のみをインストールします。 それぞれの KB 番号に対応したドキュメント (KB4096495、KB4096418、KB4095874、KB4019990) も公開されていますので、対象の環境にインストールすべき更新プログラムがどれであるのかご確認ください。対象の環境にインストールされている .NET Framework のバージョンを確認する方法については、こちらのドキュメントをご参照ください。   ご注意事項 手動でのインストールの場合、.NET Framework 4.5.2 を利用している環境であっても、.NET Framework 4.6 以上向けの更新プログラムを適用できてしまう動作となっています。また、逆に、.NET Framework 4.6 以上の環境に対して .NET Framework 4.5.2 向けの更新プログラムを適用できてしまうケースがあります。(*3) このように誤ったバージョンの更新プログラムを適用してしまうと、.NET Framework のランタイム ライブラリ間のバージョンに不整合が生じ、以下のドキュメントで紹介されているような問題が発生する場合があります。  

.NET Framework 4 以降の環境に異なるバージョンの .NET Framework 向けの更新プログラムを適用すると発生する問題について https://support.microsoft.com/ja-jp/help/3122487

  誤ったバージョンの更新プログラムを適用してしまった場合は、コントロールパネルの「インストールされた更新プログラムの一覧」から対象の更新プログラムをアンインストールし、正しい更新プログラムを適用しなおしてください。  

  対象の更新プログラムについては、以下の一覧から ".NET Framework" や "4.6" をキーワードに検索し、対象の OS に該当する KB のリンク先ページをご覧いただくなどしてご確認ください。

Software Update Services and Windows Server Update Services changes in content for 2017 Software Update Services and Windows Server Update Services changes in content for 2016 Software Update Services and Windows Server Update Services changes in content for 2015

  (*3) 具体的には、Windows Server 2012、Windows 8.1、Windows Server 2012 R2 に対して、2017 年 9 月より前の更新プログラムを適用する場合が該当します。2017 年 9 月以降の更新プログラムでは、OS の機能と連携して不適切な更新プログラムのインストールをブロックする機能が追加されています。これより前の時点では、Windows Server 2012 においては .NET Framework の誤ったバージョンの手動インストールをブロックする機能が提供されておらず、OS の機能上の制限事項として、不適切な更新プログラムのインストールが許容されておりました。   更新プログラムの構成や Microsoft Update カタログの表示に分かりづらい面があり、手動で適用されているご利用者様にはご不便をおかけいたしますが、上記内容についてご承知おきくださいますようお願い申し上げます。]]> Azure DevTest Labs および Azure VM の自動シャットダウン機能の設定時刻について https://docs.microsoft.com/archive/blogs/jpvsblog/dtl-autoshutdown-time Wed, 20 Jun 2018 16:12:47 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2365 こんにちは、Visual Studio サポート チームです。 今回は、Azure DevTest Labs および Azure VM の自動シャットダウン機能 (*1) を設定した時刻と、実際にシャットダウンが行われる実行タイミングの関係について、ご案内します。 設定内容によっては、意図したタイミングでシャットダウンできないケースがありますので、本稿が参考になりましたら幸いです。  

(*1) Azure DevTest Labs は、アプリケーションのテスト環境となる VM を Azure 上に構築・管理し、アプリケーションのデプロイプロセスにテスト環境のプロビジョニングを組み込んで、テスト環境の構築に要するコストを削減するためのサービスです。Azure VM の自動シャットダウン機能も、DevTest Labs から提供されています。

Azure DevTest Labs とは https://docs.microsoft.com/ja-jp/azure/lab-services/devtest-lab-overview

  現象 DevTest Labs または Azure VM で、自動シャットダウンの設定したにも関わらず、設定当日に対象 VM の自動シャットダウンが実行されない場合があります。   原因 本現象は、自動シャットダウン機能の想定された動作に依存して発生している可能性があります。 DevTest Labs および Azure VM の自動シャットダウン機能では、設定を行った時点から所定の時間間隔をあけて実行される必要があり、この間隔が短いと当日のシャットダウンは行われず、翌日の当該時刻にシャットダウンが実行される動作となります。 この所定の時間間隔の目安は、通知機能 (Email または Webhook) の設定に応じて以下とおりとなっています。  

通知機能を有効にしている場合 : 31 分間

通知機能を無効にしている場合 : 1 分間

  以下に、具体的な設定と、想定される結果の例を示します。  

例 1)　2018 年 6 月 18 日 13:00 に、通知機能付きで自動シャットダウンの実行時刻を 13:15 に設定した場合

設定時点 (13:00) から自動シャットダウンの実行時刻 (13:15) までに 31 分以上の時間間隔があけられていないため、翌日の 6 月 19 日 13:15 から毎日自動シャットダウンが実行されます。

 

例 2) 2018 年 6 月 18 日 13:00 に、通知機能付きで自動シャットダウンの実行時間を 13:35 に設定した場合

設定時点 (13:00) から自動シャットダウンの実行時間 (13:35) までに 31 分以上の時間間隔があけられているため、設定当日の 6 月 18 日 13:35 から毎日自動シャットダウンが実行されます。

  なお、Azure VM や DevTest Labs の自動シャットダウンと通知は以下の画面から設定してご利用いただけます。 ・ 対象の Azure VM -> 自動シャットダウン

・ 対象の DevTest Labs -> 構成とポリシー -> 自動シャットダウン

  対処方法 自動シャットダウンを設定した当日から、通知機能付きで自動シャットダウンを動作させたい場合は、設定時点から、余裕をもって 35 分以上の時間をおいて、シャットダウン時刻を指定してください。 通知機能を利用されない場合は、余裕をもって 5 分以上の時間をおいてシャットダウンが行われるよう設定してください。 なお、35 分以上時間をあけているにも関わらず、自動シャットダウンが正常に動作しなかった場合は、Azure 内のネットワーク等の一時的な問題などに起因している可能性が考えられますので、翌日など、タイミングを改めてご確認ください。 ]]> Visual Studio 2015 および Visual C++ 2017 のリンク時のコード生成における最適化の不具合について https://docs.microsoft.com/archive/blogs/jpvsblog/link-optimization-virtual Mon, 04 Jun 2018 09:39:03 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2335 こんにちは、Visual Studio サポート チームです。 今回は、Visual C++ 2015 および Visual C++ 2017 で確認されている、C++ プロジェクトのリンク時のコード生成における最適化の不具合についてご案内します。 なお、この事象については報告が非常に少なく現在も修正に向けて調査中ですが、進展があり次第この記事を更新する予定です。   現象 以下の条件を満たす場合に、仮想関数呼び出しが正常に行われず基底クラスのメンバー関数が実行される場合があります。
  • 速度優先の最適化 (/O2 オプションもしくは /Ox オプション) を指定している。
  • リンク時のコード生成 (/LTCG オプション) を指定している。
  • プログラム全体の最適化 (/GL オプション) を指定している。
  • 仮想関数の呼び出しと仮想関数の実装が異なるバイナリ間で行われている。
  原因 本現象は弊社製品の不具合に起因して発生しています。 Visual C++ コンパイラーおよびリンカーは、呼び出される仮想関数がコード生成時に静的に決定でき、かつ最適化によるパフォーマンスの向上が見込めると判断した場合、devirtualization と呼ばれる仮想関数呼び出しを直接呼び出しに置き換える最適化を行います。 リンク時のコード生成が指定されている場合、仮想関数の呼び出しと仮想関数の実装が異なるバイナリ間で行われている場合も devirtualization が試みられますが、仮想関数ではなく基底クラスの関数が呼び出されるコードが生成される場合があります。   回避策 以下のいずれかの方法でリンク時のコード生成における devirtualization の最適化を無効化することで、この問題を回避できます。
  • コンパイラー オプションで /d2notypeopt を指定する
  • リンカー オプションで /d2:-notypeopt オプションを指定する
  留意事項 上記の回避策では最適化が一部行われないことにより、アプリケーションの実装によってはパフォーマンスが低下する可能性があります。また、/sdl オプションで出力される警告の一部は、上記の回避策を適用した場合コンパイラーやリンカーによって摘出されなくなる可能性があります。 そのため、現象で示した問題に該当し、アプリケーションのパフォーマンスへの影響を許容できる場合のみ、回避策の適用をご検討ください。   ステータス マイクロソフトはこの問題を Visual C++ 2015 と Visual C++ 2017 における不具合と認識しています。 この問題は、Visual Studio 2017 version 15.8 以降での修正を予定しています。 修正がリリースされましたら改めてこの記事でご案内します。]]> .NET Framework のネイティブ イメージが無効になる状況と考えられる影響について https://docs.microsoft.com/archive/blogs/jpvsblog/ngen Mon, 07 May 2018 10:34:57 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2325 こんにちは、Visual Studio サポート チームです。 .NET Framework のライブラリは中間言語 (MSIL) 形式のアセンブリとして提供されていますが、これらは事前にコンパイルされるか、アプリケーションの実行時に JIT コンパイルされて機械語に変換され、プログラムから利用されます。 今回は、Windows Update の適用などに伴い .NET Framework のネイティブ イメージが無効になり再作成が行われる動作と、考えられる影響などについてご案内します。   現象 Windows Update や .NET Framework の更新プログラムの適用後、.NET Framework を使用するアプリケーションやサービスの動作が遅くなる場合や、CPU 使用率が高騰する場合があります。 PowerShell など、 .NET Framework 上で動作するスクリプトをホストするプロセスも同様の事象が発生する場合があります。 なお、下記の KB で案内しているとおり、32 ビットの .NET Framework に比べて 64 ビットの .NET Framework のほうが JIT コンパイルが必要となることに伴う影響は大きい傾向があります。

64 ビットの .NET Framework アプリケーションの起動に時間がかかる https://support.microsoft.com/ja-jp/help/2833666

  また、この事象は一般的には一時的なものですが、何らかの理由で常に高い負荷の状態となっているコンピューターでは長期にわたり解消されないことがあります。   原因 Windows Update や .NET Framework の更新プログラムの適用でアセンブリが置き換わった場合、ネイティブ イメージとの不整合を避けるため、ネイティブ イメージは一旦無効な状態として扱われます。 このとき同時にネイティブ イメージの再作成がスケジュールされますが、実行はシステムのアイドル時に行われるため、再作成されるまでの間、アプリケーションの実行時は JIT コンパイルが必要となります。 この場合も、ネイティブ イメージでの動作と中間言語のアセンブリでの動作の間で、アプリケーションの実行結果に相違が生じることはありません。 ただし、JIT コンパイルの処理によって、アプリケーションの起動や実行が遅くなる場合や、プロセスの CPU 使用率やメモリ使用量が高くなる場合があります。 なお、Windows 10 および Windows Server 2016 では .NET Framework の更新プログラムは OS の更新プログラムとともにリリースされるため、OS の更新プログラムの適用時にもネイティブ イメージが無効となる可能性があります。 また、システムがアイドル状態とならないような常に高い負荷が続く状況ではネイティブ イメージの再作成が行われないため、自動的には JIT コンパイルが必要な状況が解消されません。   対処方法 通常この現象は一時的なもので、システムがアイドル状態になった後自動的にネイティブ イメージが再作成されるため、特別な対処は必要ないことがほとんどです。 ネイティブ イメージが自動的に再作成されることを待たず直ちに再作成が必要となる場合、もしくは常に高い負荷が続く状況などで自動的な再作成が期待できない場合は、明示的にネイティブ イメージの再作成を行ってください。 明示的にネイティブ イメージの再作成を行うには、.NET Framework に含まれる ngen.exe を以下の手順で実行します。   (1) 管理者権限でコマンド プロンプトを起動します。 (2) 下記の 2 つのコマンドを実行します。

C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe executeQueuedItems

C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe update

(3) 64 bit OS の場合は、続けて下記の 2 つのコマンドを実行します。

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe executeQueuedItems

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update

  なお、上記コマンドの実行中はネイティブ イメージの生成のためシステムの負荷が高くなります。 実行が完了するまでの所要時間はインストールされているネイティブ イメージの状況に依存するため、あらかじめ検証可能な環境などで所要時間をご確認いただいた上で実施することをお勧めします。   参考情報 – ネイティブ イメージについて .NET Framework 上で動作するアセンブリには、CPU が直接実行できる命令ではなく、.NET Framework が実行時 (JIT : Just-in-Time) にコンパイルして CPU 命令に変換するための中間言語が含まれています。 JIT コンパイルはアプリケーションの起動や実行のパフォーマンスに影響を与える可能性があるため、その対処として予め CPU が直接実行できる命令にコンパイルしておくことも可能です。 予めコンパイルされたファイルをネイティブ イメージと呼び、 C:\windows\assembly フォルダー配下の NativeImages_v4.0.30319_32 フォルダーなどに、***.ni.dll という名称で保存されています。 ネイティブ イメージの生成には長時間を要するため、更新プログラムの適用により無効となった場合も再作成は同時には行われず、更新プログラムの適用後に実行するようにスケジュールされます。 また、ネイティブ イメージの生成は CPU やメモリ、ディスク IO などのリソースを多く使用するため、実行中のアプリケーションやサービスの動作に影響を与えないよう、システムがアイドル状態のときに実行されます。 ネイティブ イメージの詳細につきましては下記のドキュメントをご確認ください。

Ngen.exe (ネイティブ イメージ ジェネレーター) https://docs.microsoft.com/ja-jp/dotnet/framework/tools/ngen-exe-native-image-generator

]]> プロジェクト参照を含むソリューションのビルド時に、変更のないプロジェクトに対してもリビルドが行われる https://docs.microsoft.com/archive/blogs/jpvsblog/projref-rebuild Fri, 23 Mar 2018 22:10:08 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2285 こんにちは、Visual Studio サポート チームです。 今回は、Visual Studio でソリューションをビルドする際のリビルドの動作に関して、ご留意いただきたい内容をご紹介します。   現象 プロジェクト参照 (*1) を含むソリューションを Visual Studio で開き、ソリューション構成 (Debug/Release など) を切り替えてビルドを行うと、プロジェクトに変更が加えられていなくてもプロジェクトがリビルドされる場合があります。   (*1) "プロジェクト参照" とは、あるプロジェクトから、同一のソリューションに含まれる別のプロジェクトを参照する参照方法であり、被参照側プロジェクトに変更があると、そのプロジェクトだけでなく参照側のプロジェクトもビルドが必要とみなされます。複数のプロジェクトを 1 つのソリューションで同時に開発する場合に便利な参照形式です。 これに対し、DLL を直接参照する "アセンブリ参照" は、サードパーティから提供されている DLL や、社内共通の共通ライブラリとして提供されている DLL など、対象のプロジェクトと被参照 DLL が別々に開発される場合に利用される参照方法です。   原因 本現象は Visual Studio の想定された動作に基づく制限事項です。 プロジェクト参照を含むソリューションでは、Visual Studio がビルドの要否を判断するロジックの制約から、直前にビルドされたソリューション構成から変更が生じた場合に、プロジェクトを参照している側のプロジェクトに対してリビルドが行われます。(*2) なお、"直前にビルドされたソリューション構成" の情報は、Visual Studio の起動中は Visual Studio 内に記憶され、Visual Studio の終了後は .suo ファイル (*3) に保持されます。ここで、.suo ファイルが存在しない状態では、"直前にビルドされたソリューション構成" としては既定の設定 (Debug) が適用されるため、.suo ファイルが存在しない状態で Release 構成のビルドを行うと、常に、"直前にビルドされたソリューション構成から変更が生じた" 状態と判断されるため、プロジェクト参照しているプロジェクトに対してリビルドが行われます。 このため、特に、直前に Release 構成でビルドを行った状態を保持した .suo ファイルが存在しない状態で、Visual Studio のコマンドライン ツールである devenv.exe を利用して Release 構成でソリューションのビルドを行うと、毎回、リビルドが行われてしまうといった状況が起こりえます。   (*2) 本動作は Visual Studio 2017 より前のバージョンの Visual Studio で確認されています。Visual Studio 2017 では IDE 上からのビルドでは本動作は改善されています。 (*3) .suo ファイルは、Visual Studio の終了時に自動的に出力される隠しファイルで、ユーザーによる設定などの情報を保持しています。Visual Studio 2013 の場合は ***.v12.suo、Visual Studio 2015 の場合は拡張子のみで .suo といった形で、バージョンによってファイル名が異なります。   <実行例 : .suo ファイルなし> devenv.exe で Release 構成を指定して 2 回続けてビルドを行っていますが、更新不要とならずにビルドが実行されています。
c:\temp\VS2013\ConsoleApplication1_vb2013>devenv.exe /Build "Release|Any CPU" ConsoleApplication1_vb2013.sln Microsoft Visual Studio 2013 Version 12.0.40629.0。 Copyright (C) Microsoft Corp. All rights reserved. ------ ビルド開始: プロジェクト:ConsoleApplication1_vb2013, 構成:Release Any CPU ------ ========== ビルド: 1 正常終了、0 失敗、1 更新不要、0 スキップ ========== c:\temp\VS2013\ConsoleApplication1_vb2013>devenv.exe /Build "Release|Any CPU" ConsoleApplication1_vb2013.sln Microsoft Visual Studio 2013 Version 12.0.40629.0。 Copyright (C) Microsoft Corp. All rights reserved. ------ ビルド開始: プロジェクト:ConsoleApplication1_vb2013, 構成:Release Any CPU ------ ========== ビルド: 1 正常終了、0 失敗、1 更新不要、0 スキップ ==========
  対処策 対象のソリューションを、一度、Visual Studio で開いて Release 構成でビルドし、Visual Studio を終了して .suo ファイルが出力された状態とすることで、devenv.exe を使用して Release 構成でビルドを行う場合でも、不要なリビルドを避けることができます。 <実行例 : Release 構成でビルドして終了した際に出力された .suo ファイルあり>
c:\temp\VS2013\ConsoleApplication1_vb2013>devenv.exe /Build "Release|Any CPU" ConsoleApplication1_vb2013.sln Microsoft Visual Studio 2013 Version 12.0.40629.0。 Copyright (C) Microsoft Corp. All rights reserved. ========== ビルド: 0 正常終了、0 失敗、2 更新不要、0 スキップ ========== c:\temp\VS2013\ConsoleApplication1_vb2013>devenv.exe /Build "Release|Any CPU" ConsoleApplication1_vb2013.sln Microsoft Visual Studio 2013 Version 12.0.40629.0。 Copyright (C) Microsoft Corp. All rights reserved. ========== ビルド: 0 正常終了、0 失敗、2 更新不要、0 スキップ ==========
  プロジェクトの規模が大きくできる限り不要なリビルドを避けたい場合など、上記内容がお役に立てましたら幸いです。 ]]> Visual C++ 2015 以降のバージョンの再頒布可能パッケージにおけるインストールの前提条件 https://docs.microsoft.com/archive/blogs/jpvsblog/ucrt-prerequisite Tue, 27 Feb 2018 20:49:57 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2275 こんにちは、Visual Studio サポート チームです。 今回は、最近多くのお客様からお問い合わせをいただいている Visual C++ 再頒布可能パッケージのインストールに必要な前提条件についてご案内します。   以前のブログ記事でもご案内していますが、Visual C++ 2015 以降のバージョンの C ランタイム (CRT) は、汎用 C ランタイム (UCRT : Universal C Runtime) とそれ以外のランタイムで構成されています。Visual C++ 2015 再頒布可能パッケージをインストールすると、これらのランタイムがすべてインストールされます。 ここで、UCRT は Windows 10 以降の OS は既定でインストールされているものになりますが、Windows 10 より前の OS にインストールするためには、対象の環境に前提となる KB が適用されている必要があります。 このため、例えば、新規にセットアップしたばかりの Windows 8.1 に Visual C++ 2015 再頒布可能パッケージをインストールしようとすると、UCRT の前提条件となる KB が適用されていないために、インストール エラーとなることが想定されます。 Visual C++ 2015 以降のバージョンの再頒布可能パッケージをインストールされるご利用者様や、製品に再頒布可能パッケージを含めることをご検討されている開発者様は、KB の事前インストールが必要となる可能性がある点についてご注意ください。

  なお、OS の更新プログラムがロールアップ モデルに移行したことに伴い、UCRT や、UCRT の前提となる KB も最新の累積更新プログラムに含まれています。このため、Windows 7 や Windows 8.1 の環境でも、Windows Update で最新の状態としていただけましたら UCRT もインストールされた状態となり、Visual C++ 2015 再頒布可能パッケージをインストールしていただくことが可能となります。 この他、Windows Update によって既に UCRT が適用されている環境に対して、UCRT を単独でインストールしようとした場合に、既にインストール済みであるために発生するエラーについてお問い合わせいただくことがありますが、その場合は UCRT を改めてインストールしていただく必要はありませんのでご安心ください。 上記のとおり、インストール対象の PC が Windows Update で最新の状態になっている場合は、UCRT や前提 KB のインストールを意識する必要はありません。そうでない場合は、UCRT のインストールに必要となる前提について、以下の内容をご確認ください。   Windows 10 および Windows Server 2016 以降の OS の場合 このバージョンは UCRT がインストール済みのため、対応は特に必要ありません。   Windows RT 8.1、Windows 8.1 および Windows Server 2012 R2 の場合 1. もし、KB2919442 が適用されていない場合には、適用します。

KB2919442: 3 月の 2014 年まで Windows 8.1 および Windows Server 2012 R2 の更新プログラムのサービスを提供 https://support.microsoft.com/ja-jp/help/2919442/march-2014-servicing-stack-update-for-windows-8-1-and-windows-server-2

  2. 続いて KB2919355 を適用します。

KB2919355: Windows RT 8.1、Windows 8.1、および Windows Server 2012 R2 の更新プログラム: 2014 年 4 月 https://support.microsoft.com/ja-jp/help/2919355/windows-rt-8-1--windows-8-1--and-windows-server-2012-r2-update-april-2

  Windows 7 および Windows Server 2008 R2 の場合 Windows 7 Service Pack 1 および Windows Server 2008 R2 Service Pack 1 が適用されていない場合は、以下よりダウンロードし適用してください。

Windows 7 Service Pack 1 および Windows Server 2008 R2 Service Pack 1 に関する情報 https://support.microsoft.com/ja-jp/help/976932/information-about-service-pack-1-for-windows-7-and-for-windows-server

  Windows Server 2008 の場合 Windows Server 2008 Service Pack 2 が適用されていない場合は、以下よりダウンロードし適用してください。

Windows Vista Service Pack 2 および Windows Server 2008 Service Pack 2 に関する情報 https://support.microsoft.com/ja-jp/help/948465/information-about-service-pack-2-for-windows-vista-and-for-windows-ser

]]> ClickOnce アプリケーションのインストールや更新の後に発生する場合があるアプリケーション起動時のエラーについて https://docs.microsoft.com/archive/blogs/jpvsblog/clickonce-error Tue, 20 Feb 2018 10:29:48 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2245 こんにちは、Visual Studio サポート チームです。 今回は、ClickOnce アプリケーションのインストールや更新後に発生する場合がある、アプリケーション起動時のエラーとその対処方法についてご案内します。 当ブログの下記の記事でも ClickOnce アプリケーションの起動時のエラーについて取り扱っていますが、今回は、この他によくお問い合わせをいただく既知の問題についてご案内しています。

ClickOnce 起動時のエラーについて https://blogs.msdn.microsoft.com/jpvsblog/2011/08/05/clickonce/

  現象 ClickOnce アプリケーションをインストールした場合や更新した場合に、以下のようなエラー ダイアログが表示され、アプリケーションの起動に失敗する場合があります。

"詳細" ボタンを押下すると、エラーの状況に応じて以下のようなエラーの詳細が記録されている場合があります。 ※ 当記事の原因に該当する場合、多くのケースではスタック トレース上に ComponentStore.ActivateApplication が現れますが、スタック トレースの内容など詳細は .NET Framework のバージョンにより異なる可能性がございます。また、代表的なエラー メッセージを挙げており、すべてのパターンを網羅するものではございませんので予めご了承ください。 必要なレジストリ キーが見つからなかった場合

この操作中に次のエラーが検出されました。 * [2018/02/19 14:35:33] System.ArgumentException - 値が有効な範囲にありません。 - ソース:System.Deployment - スタック トレース: 場所 System.Deployment.Application.NativeMethods.CorLaunchApplication 場所 System.Deployment.Application.ComponentStore.ActivateApplication 場所 System.Deployment.Application.SubscriptionStore.ActivateApplication 場所 System.Deployment.Application.ApplicationActivator.Activate 場所 System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation 場所 System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker

ClickOnce キャッシュのマニフェスト ファイルが破損していた場合

この操作中に次のエラーが検出されました。 * [2018/02/19 14:33:55] System.Deployment.Application.DeploymentException (Activation) - Windows Side-by-Side エラーにより認証に失敗しました。イベント ログにこの失敗に関する詳細が含まれている可能性があります。 - ソース:System.Deployment - スタック トレース: 場所 System.Deployment.Application.ComponentStore.ActivateApplication 場所 System.Deployment.Application.SubscriptionStore.ActivateApplication 場所 System.Deployment.Application.ApplicationActivator.Activate 場所 System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation 場所 System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker --- 内部例外 --- System.Runtime.InteropServices.COMException - このアプリケーションのサイド バイ サイド構成が正しくないため、アプリケーションを開始できませんでした。詳細については、アプリケーションのイベント ログを参照するか、コマンド ライン ツール sxstrace.exe を使用してください。 (HRESULT からの例外:0x800736B1) - ソース:System.Deployment - スタック トレース: 場所 System.Deployment.Application.NativeMethods.CorLaunchApplication 場所 System.Deployment.Application.ComponentStore.ActivateApplication

ClickOnce キャッシュのファイルが部分的に欠落している場合

この操作中に次のエラーが検出されました。 * [2018/02/19 14:28:20] System.Deployment.Application.DeploymentException (Activation) - ライセンス認証に失敗しました。 - ソース:System.Deployment - スタック トレース: 場所 System.Deployment.Application.ComponentStore.ActivateApplication 場所 System.Deployment.Application.SubscriptionStore.ActivateApplication 場所 System.Deployment.Application.ApplicationActivator.Activate 場所 System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation 場所 System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker --- 内部例外 --- System.IO.FileNotFoundException - 指定されたファイルが見つかりません。 (HRESULT からの例外:0x80070002) - ソース:System.Deployment - スタック トレース: 場所 System.Deployment.Application.NativeMethods.CorLaunchApplication 場所 System.Deployment.Application.ComponentStore.ActivateApplication

ClickOnce キャッシュの EXE ファイルが破損していた場合

この操作中に次のエラーが検出されました。 * [2018/02/19 14:31:41] System.BadImageFormatException -  は有効な Win32 アプリケーションではありません。 (HRESULT からの例外:0x800700C1) - ソース:System.Deployment - スタック トレース: 場所 System.Deployment.Application.NativeMethods.CorLaunchApplication 場所 System.Deployment.Application.ComponentStore.ActivateApplication 場所 System.Deployment.Application.SubscriptionStore.ActivateApplication 場所 System.Deployment.Application.ApplicationActivator.Activate 場所 System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation 場所 System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker

  原因 ClickOnce はアプリケーションの情報や構成を、ユーザー プロファイル配下のファイルとレジストリの両方で管理しています。

ユーザー プロファイル : %userprofile%\AppData\Local\Apps\2.0 レジストリ キー : HKEY_CURRENT_USER\Software\Classes\Software\Microsoft\Windows\CurrentVersion\Deployment\SideBySide\2.0

  何らかの理由によりこれらの整合性に問題が生じた場合、ClickOnce アプリケーションはエラーにより起動できない状態となります。ファイルとレジストリの整合性に問題が生じる状況となる原因としては、例えば下記のような状況が考えられます。
  • ClickOnce アプリケーションのインストールまたは更新中に、電源障害などによる予期しないシャットダウンが発生した場合
  • ClickOnce アプリケーションのインストールまたは更新中に、コンピューターの電源を切るなどによる予期しないログオフが発生した場合
  • ClickOnce アプリケーションのインストールまたは更新中に、ClickOnce ローダー プロセス (dfsvc.exe) が強制終了した場合や未知の問題などで異常終了した場合
  • バックアップ ソフトウェアなどの復元機能で、レジストリもしくはファイルのみに対して復元が行われた場合
  • 移動プロファイルが使用されている場合 (ClickOnce は移動プロファイルをサポートしていません。)
  • ウィルス対策ソフトウェアなどが、ファイルやレジストリのアクセスを阻害した場合や問題があるファイルとして除去された場合
  整合性に問題が生じる状況に至った原因は、ファイルとレジストリの整合性に問題が生じた後に得られる情報 (ClickOnce ログや、ユーザー プロファイルやレジストリ配下の ClickOnce キャッシュ一式など) から調査を進めることは困難です。このため、ファイルやレジストリに不整合が生じる事象を再現させ、引き金となったプロセスの処理などを解析して特定する必要があります。もし特定の手順で問題が再現できる場合には、Visual Studio サポート チームで調査させていただきますので弊社へお問い合わせください。 なお、この種のエラーについては ClickOnce アプリケーション側に何等かの問題があるわけではなく、対象の環境で利用されているサードパーティ製品の動作や予期しない操作などに起因していることがほとんどです。アプリケーション側の実装や配置の仕方で対処することはできませんので、この問題が発生した場合には後述の対処方法を実施して復旧することをご検討ください。万が一対処方法を実施して解決しない場合には、ClickOnce キャッシュの破損以外の原因が考えられるため、下記の情報を取得していただき弊社へお問い合わせください。   対処方法について オフラインでも実行可能なアプリケーションの場合は、アプリケーションを一度アンインストールして再度インストールを行ってください。オンラインのみで実行可能なアプリケーションの場合、もくしは上記で解消されない場合は、ユーザー プロファイル配下の ClickOnce キャッシュを削除してください。(レジストリ キーを削除する必要はありません。) なお、恐れ入りますが特定のアプリケーションのみの ClickOnce キャッシュを選択して削除することは出来ません。ClickOnce キャッシュの削除後は、問題が発生しているアプリケーション以外の他のアプリケーションの再インストールも必要となりますが、各アプリケーションの起動を試みた際に自動的に再インストールが行われますのでご安心ください。再インストールが必要となる場合は、インストール確認画面が表示される場合がございますので、この点はご注意ください。   参考情報 英語の公開技術情報となりますが、ClickOnce アプリケーションの更新の失敗についての原因と対処については以下の KB でもご案内しておりますので、あわせてご確認ください。

ClickOnce Application Fails to Update https://support.microsoft.com/en-us/help/2713442/clickonce-application-fails-to-update

  なお、弊社では ClickOnce アプリケーションの堅牢性の向上について継続して取り組んでおり、.NET Framework 4.7 以降では ClickOnce キャッシュの破損を検出した場合に自動的に復元を試みる機能を追加しております。現状では ClickOnce キャッシュの破損により発生するエラーのすべてを回復できるものではございませんが、より新しいバージョンの .NET Framework をご利用いただくこともご検討いただけますと幸いです。ClickOnce キャッシュ破損の回復機能については下記のブログでご案内しておりますので、あわせてご確認ください。

Announcing the .NET Framework 4.7 - Store Corruption Recovery https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/

]]> OLE パッケージ オブジェクトを含むドキュメントを開くと GDI オブジェクトが増加する https://docs.microsoft.com/archive/blogs/jpvsblog/olepackage-gdi Fri, 16 Feb 2018 22:11:17 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2225 こんにちは、Visual Studio サポート チームです。 今回は、OLE パッケージ オブジェクトをプログラムから利用した場合に発生する問題についてご案内します。   現象 アプリケーションから OLE パッケージ オブジェクト (*1) を含むドキュメントを開いて閉じる操作を繰り返すと、アプリケーションの GDI オブジェクトの使用量が増加します。 増加量は僅かであるため、ほとんどのアプリケーションではこの問題が影響することはありませんが、パッケージ オブジェクトを含むドキュメントを、開いて閉じる動作を繰り返すようなアプリケーションでは、GDI オブジェクトの総量がプロセスごとに割り当てられた上限 (既定で 10,000) に達し、それ以降の GDI オブジェクトの生成に失敗して描画処理に問題が生じる場合があります。   (*1) パッケージ オブジェクトは、他のファイルやプログラムなどを OLE オブジェクトとしてドキュメントに挿入できるようにするためのオブジェクトです。  

パッケージ オブジェクトの挿入

原因 本現象は、OLE パッケージ オブジェクトを管理する Windows OS のパッケージ管理コンポーネント (packager.dll) の不具合に起因するものです。 本コンポーネントでは、パッケージ オブジェクトごとにタイトルを表示するためのフォント オブジェクトを生成しますが、ドキュメントを閉じてもこのフォント オブジェクトが解放されないため、ドキュメントを開いて閉じる操作を繰り返すとフォント オブジェクト (GDI オブジェクト) が増加し続ける結果となります。   対応状況 マイクロソフトでは米国本社の開発部門でも本不具合を確認していますが、現時点では修正プログラムなどは提供されておらず、提供の予定はありません。 パッケージ オブジェクトは OLE 1.0 で導入されましたが、本不具合に起因する問題の報告がこれまでなかったことや、修正を行った場合の影響範囲の大きさなどを考慮して、修正が見送られている状況です。 ご利用のお客様にはご不便をおかけいたしまことお詫び申し上げます。   対処策 前述のとおり、GDI オブジェクトの増加量は僅かであるため、ほとんどのアプリケーションでは特別な対応は必要ありません。 プロセスを再起動せずに、パッケージ オブジェクトを含むドキュメントを頻繁に開いて閉じるようなアプリケーションでは、対策が必要となる場合があります。 ここで、パッケージ管理コンポーネントが内部で使用しているものであることから、アプリケーション側からこれを解放することはできず、本不具合による GDI オブジェクトの増加を抑止することはできません。このため、GDI オブジェクトの総数が、プロセスに割り当てられている GDI オブジェクト数の上限値 (既定値 10,000) に達する前の段階で、プロセスを安全に再起動させたり、ユーザーにアプリケーションの再起動を促すような対応をご検討ください。   参考情報 プロセスが使用している GDI オブジェクトの数は、GetGuiResources 関数を使用して取得可能です。GetGuiResources 関数の詳細については以下のドキュメントをご参照ください。

GetGuiResources function (英語原文) https://msdn.microsoft.com/en-us/library/windows/desktop/ms683192(v=vs.85).aspx (日本語訳) https://msdn.microsoft.com/ja-jp/library/cc429120.aspx

  また、プロセスごとに割り当て可能な GDI オブジェクトの数の上限は既定で 10,000 となっています。GDI オブジェクトの上限に関しては、以下のドキュメントをご参照ください。

Windows の限界に挑む: USER オブジェクトと GDI オブジェクト – 第 2 部 https://technet.microsoft.com/ja-jp/windows/mark_17.aspx

]]> 以前のバージョンの Visual Studio 2017 インストーラーについて https://docs.microsoft.com/archive/blogs/jpvsblog/vs2017-previous-installer Fri, 15 Dec 2017 08:29:22 GMT https://blogs.msdn.microsoft.com/jpvsblog/?p=2206 こんにちは、Visual Studio サポート チームです。 Visual Studio 2017 も先日バージョン 15.5 が公開されました！ (※2017/12現在) 弊社としては、不具合の修正やセキュリティの強化が適用されている最新版のご利用を推奨しており、製品サポートも基本的には最新版にて承っています。   しかしながら、様々なご事情で以前のバージョンを入手したいというお問い合わせもいただいており、このようなご要望を受け、その時点でリリースされている「最新バージョンのひとつ前のバージョン」をご利用いただけるように以下のページで公開しています。

Installing an earlier release of Visual Studio 2017 https://www.visualstudio.com/en-us/productinfo/installing-an-earlier-release-of-vs2017 ※ 新しいバージョンがリリースされた場合には公開バージョンが変更されますのでご留意ください。

  なお、各バージョンのインストール パッケージを保存される場合には注意が必要です！ Visual Studio 2017 のインストーラーは、インターネット上から最新版のパッケージをダウンロードしてインストールする仕組みとなっています。このため、以前のバージョンのインストーラーを保存してあっても、インストール実行時には最新版のパッケージが取得されます。 これを防ぐためには、インストーラーのみを保存しておくのではなく、その時点のバージョンのオフライン パッケージを作成しておく必要があります。お手数とはなりますが、特定バージョンの Visual Studio 2017 インストーラーを保存されたい場合には、予め以下の手順でオフライン インストーラーを作成してくださいますようお願いいたします。   特定バージョンのオフラインインストーラーの作成手順 オフライン インストーラーの作成手順は以下のページでもご案内しています。

Visual Studio 2017 のネットワーク インストールを作成する https://docs.microsoft.com/ja-jp/visualstudio/install/create-a-network-installation-of-visual-studio#how-to-create-a-layout-for-a-previous-visual-studio-2017-release ※「以前の Visual Studio 2017 リリースのレイアウトを作成する方法」をご参考ください。

手順 1) 該当バージョンのセットアップファイル (例 vs_professional.exe) を入手します。 2) インストール イメージを保存するフォルダーを作成し、以下のコマンドでイメージをダウンロードします。

コマンド例) Visual Studio Professional を c:\vs2017offlineに展開する場合 vs_professional.exe --layout c:\vs2017offline

作成したインストーラーにバージョン名を付与するなどして保存してください。   インストール時の事前準備 オフラインなどで Visual Studio 2017 のインストールに必要な証明書がダウンロードできない環境の場合は事前に以下の手順で適用してください。

オフライン環境での Visual Studio のインストールに関する特別な考慮事項 https://docs.microsoft.com/ja-jp/visualstudio/install/install-visual-studio-in-offline-environment ※ 「Visual Studio オフライン インストールに必要な証明書をインストールする」をご参考ください。

  証明書をインストールまたは更新するには 3 つのオプションがありますが、個人のお客様はオプション 1 の手順が簡易です。

オプション 1 - レイアウト フォルダーから手動で証明書をインストールする オプション 2 - エンタープライズ環境で信頼されたルート証明書を配布する オプション 3 - Visual Studio のスクリプト化された展開の一部として証明書をインストールする

  本稿が、特定バージョンの Visual Studio 2017 のインストーラーを保存する必要がある開発者様のお役に立てましたら幸いです。 ]]>