既存アプリのファイルを確実に上書きインストールするmsiを作成するには

本記事は、Visual Studio Installerプロジェクトで作成したmsiファイルで、既存のファイルのファイルバージョンが新しくても上書きインストールする方法について記述しています。

This article is about the msi created by the Visual Studio Installer project How to overwrite an existing file with a newer file version in a file This section describes the

[EN]日本語原文は下にあるのでスクロールしてね

When you use Visual Studio Installer to create an msi file, you can usually upgrade the version of the installer project by upgrading the file version of the EXE itself, which allows you to install updates to existing applications.

However, if the version of a dll that has already been installed is new and you want to put it back, the installer does not overwrite the dlls in question, resulting in a version mismatch and a missing dll error.

This can be caused by the installer's overwriting strategy, which can result in a "file doesn't exist or an older version of Reinstall only if the file exists. This is because the file does not exist.

So let's try to solve the child problem by rewriting the msi file that was built and created using orca.

Where is orca?

C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86  

In the x86 execution folder of the latest SDK, there is an "Orca-x86_en-us.msi" file. Once installed, it is ready to run.

Rewriting msi files with orca

After starting orca, select the Property.

The REINSTALLMODE property is not set by default, so add it with ADD ROW.

The default value is "omus", where "o" means "the file doesn't exist or the version is old". Perform reinstallation only if the file exists. Therefore, "d" = "The file does not exist or a different version of the file Perform a re-installation if a "dmus" is present. Set dmus as "dmus", save and close it.

Double-clicking the msi file without closing it will result in an error, so be sure to close it.

Confirmation of operation

• New Installation
  → success 
• Installing an update to an older version (some DLL file versions are newer)
  → Success (the new DLL file was also overwritten by the one in the msi file)
• Double-click on the same msi file after installation
  →You can choose to repair or delete.
• Deleting some dll files after installation and launching the application
  →Installer repaired it and it's OK to start

 That doesn't seem to be a problem.

[JP]

Visual Studio Installerを使ってmsiファイルを作成したときに、通常は、EXE自体のファイルバージョンをあげて、インストーラープロジェクトのVersionをあげることで、既存アプリの更新インストールが可能になります。

しかし、既存インストール済の一部のdllのバージョンが新しくなっていてそれを戻したいときなどは、該当のdllが上書きされず、結果、バージョンが一致せずにdllがないようなエラーが出てしまうときがあります。

これは、インストーラーの上書き戦略が「ファイルが存在しない、またはバージョンの古いファイルが存在する場合のみ再インストールを実行します。」となっているからです。

そこで、ビルドして出来上がったmsiファイルをorcaを使って書き換えることで、子の問題を解決してみましょう。

orcaはどこにいる？

C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86

最新のSDKのx86実行フォルダに「Orca-x86_en-us.msi」があるので、インストールすると実行できます。

orcaでmsiファイルを書き換える

orcaを起動したらPropertyを選択します。

REINSTALLMODEプロパティはデフォルトでは設定されていないのでADD ROWで追加します。

デフォルト値はomusで、ここの「o」が「ファイルが存在しない、またはバージョンの古いファイルが存在する場合のみ再インストールを実行します。」の意味になりますので、「d」=「ファイルが存在しない、またはバージョンの異なるファイルが存在する場合再インストールを実行します。」としてdmusを設定し、保存してクローズします。

クローズせずにmsiファイルをダブルクリックするとエラーになりますので必ずクローズしましょう。

動作確認

■新規インストール

→成功 

■古いバージョン（一部のDLLファイルバージョンは新しい）への更新インストール

→成功（新しいDLLファイルもmsiファイル内のものに上書きされていた）

■インストール後に同じmsiファイルをダブルクリック

→修復と削除が選べる

■インストール後に一部のdllファイルを削除してアプリ起動

→インストーラーが修復してくれて起動OK

問題なさそうですね。

Microsoft MVP for Windows Developmentを再受賞しました。

 おかげさまで、Microsoft MVPを再受賞することができました。

今期も引き続きよろしくお願いいたします。

今期は、Azure KinectとかCognitive Serviceなどのアウトプットを引き続きしていこうと思います。

2008年から12回連続の13年目となります。よろしくおねがいします。

NVIDIA RTX Voiceでの周辺ノイズ削減効果について

本記事は、デルアンバサダープログラムのモニタープログラムで１か月お借りしているNew ALIENWARE m15を使って、NVIDIAのGPUを使ったノイズリダクションについて試した記事となります。

This article is about testing noise reduction with NVIDIA's GPU using a New ALIENWARE m15, which I am borrowing for a month under the Dell Ambassador Program monitoring program. 

[EN]日本語原文は下にあるのでスクロールしてね

The Effectiveness of Surrounding Noise Reduction with NVIDIA RTX Voice

Ambient noise inevitably gets in the way of speech recognition.

The speech recognition engine does some noise removal, but I could remove it before putting it into the engine. It's not a bad idea, and that's where NVIDIA RTX Voice comes in, and how much noise it eliminates. of. I checked with just the noise.

About NVIDIA RTX Voice

NVIDIA RTX Voice is a tool that uses NVIDIA (essentially a GPU) for real-time noise reduction. 

www.nvidia.com

About New ALIENWARE m15 

Processer	第9世代 Core i7-9750H
OS	Windows 10 Home 64bit
Memory	16GB 2666MHz LPDDR4x
Storage	512GB SSD
GPU	NVIDIA GeForce RTX 2070 8GB GDDR6 Max-Q
Display	15.6 inch 3840x2160
Weight	2.16kg
Size	厚さ:17.9～20.1mm 幅:360.5mm 奥行:276mm

It's still the GPU that is unique. This is truly a laptop where you can test out the NVIDIA RTX Voice.

About the effect of noise reduction

 youtu.be

It's obvious in the video.

You can see that the buzzing surrounding sounds have stopped with a snap.

The noise of m15 itself

For such high performance, the m15 itself is really quiet.

The exhaust noise from the rear and sides is also not a concern. And yet, it never gets too hot, which is the great thing about the CRYO-TECH V3.0! The great thing about thermal technology is that it doesn't get too hot.

Easy to type on a keyboard

Due to the fact that it is a 15-inch model, the keyboard key layout is straightforward and easy to type.

Real-time voice recognition allows you to quickly and easily correct minor typos when creating subtitles.

summary

In the new way of living and working, telework is one of the keys to the new way of working.

And an important part of telework is web conferencing.

With New ALIENWARE m15, not only is the noise level low, but in combination with NVIDIA RTX Voice, other ambient noises can be reduced, making the meeting easier for the other party to hear.

[JP]

NVIDIA RTX Voiceでの周辺ノイズ削減効果について

音声認識をするうえで周辺ノイズってどうしても邪魔になります。

音声認識エンジン側でもノイズ除去はやってくれるけど、エンジンに入れる前に除去できるのに越したことはないわけで、そこで、NVIDIA RTX Voiceでどれくらいノイズが消えるのか。ノイズだけの状態で確認しました。

NVIDIA RTX Voiceとは

NVIDIA RTX VoiceはNVIDIA (要はGPU）を使ってリアルタイムにノイズ削減を行うツールです。

www.nvidia.com

New ALIENWARE m15について 

Processer	第9世代 Core i7-9750H
OS	Windows 10 Home 64bit
Memory	16GB 2666MHz LPDDR4x
Storage	512GB SSD
GPU	NVIDIA GeForce RTX 2070 8GB GDDR6 Max-Q
Display	15.6 inch 3840x2160
Weight	2.16kg
Size	厚さ:17.9～20.1mm 幅:360.5mm 奥行:276mm

やはり特徴的なのはGPUですね。まさにNVIDIA RTX Voiceが試せるノートパソコンと言えるでしょう。

ノイズ削減の効果について

youtu.be

動画を見ると一目瞭然ですね。

ざわざわした周辺の音がぴたっと止まっていることがわかります。

m15自体の騒音について

これだけ高性能なのにm15自体が発する音は本当に小さいです。

後方と側面からの排気音も気になりません。それでいて熱くなりすぎるということもないのが、CRYO-TECH V3.0サーマルテクノロジーのすごいところです。

打ちやすいキーボード

15インチモデルということもあり、キーボードのキー配列は素直で打ちやすいものです。

リアルタイム音声認識で字幕作成時のちょっとした誤変換を直す時も、ささっと素早く対応できます。

まとめ

新しい生活様式、働き方改革のなかでは、テレワークが一つのキーになってきます。

そして、テレワークで重要なのはWEB会議です。

New ALIENWARE m15ならば、騒音が小さくだけではなく、NVIDIA RTX Voiceと組み合わせてそのほかの周辺ノイズも削減出来て、相手にとって聞きやすい会議が実現できるのではないでしょうか。

GitHubのmasterブランチはmainブランチ？

[JP]The English translation is next to the Japanese. Please scroll down.

GitHubのmasterブランチはmainブランチ

GitHubのmasterブランチは、そのソースコードの大元のブランチです。

git-flowなどの流儀では、masterブランチは直接変更せず、developブランチを切って、更に変更内容ごとにfeatureブランチを切り、そこで変更が終わったらdevelopブランチにマージして、さらにリリースするときにはreleaseブランチにマージしリリース作業をします。

そして、リリースしたらreleaseブランチから、masterブランチとdevelopブランチにマージしてみたいな感じにします。

もちろん、ここでいう「master」は、masterディスクとかmasterファイルとかと同じ意味の「master」です。

マスターファイルは日本語で言えば、原簿とか基本ファイルと呼ばれているので（というかマスターファイルで通じるけどね）、あえて、masterブランチを日本語化するならば、原分岐とか基本分岐とかになるのでしょうか。

それくらい大切なmasterブランチですが、最近の流れでは「master」ではなく「main」と命名することがあるようです。

例：

github.com

これ、docsの方はmasterブランチで引用していて、ことごとくリンクが404になってしまうので、最近変わったようです。

EssentialsのShareのdocsで気づいてプルリクしたけど、これ、shareだけじゃなくて、Essemtials関係のdocs全部ですね。

docs.microsoft.com

ほぼすべてのページで、最後にAPI Source codeでgithubのmasterブランチを引用しています。

「main」ブランチでもいいといえばいいのですが、この「master」は、master/slaveのようなslaveと対をなすものではないので、そのままでもいいような気もしなくもないです。でも、masterからmaster/slave想像しちゃうっていうのならば変えるのがいいのかな（この部分を議論したい訳じゃないので、深追いをするつもりないです）。

ただ、私見ですが、先ほどの日本語訳からの逆翻訳した「original」ブランチの方が「main」ブランチよりもしっくりくるかなー。

あとは、「base」ブランチとかかな。

[EN]

From now on, will the master branch on GitHub be called the main branch?

The master branch on GitHub is the main branch in its source code.

In the "git-flow" style, you don't change the master branch directly, but instead use the develop branch, and then cut a feature branch for each change, where the change is done, and then and merge it into a develop branch, and release it when you release more. branch and work on the release.

Then, when you release, you merge them into the master branch and the develop branch from the release branch, and so on.

Of course, the "master" here is the same as the master disk and the master file.
In Japanese, the master file is called "original file" or "basic file", so if you were to Japaneseize the master branch, it would be "original branch" or "basic branch". 

Although the master branch is that important, it is sometimes called "main" instead of "master" in recent years.

For example:  

github.com

 This seems to have changed recently, as the docs are quoted in the master branch, and the links are 404 at every turn.

I noticed this in the Share docs in Essentials and pulled it, but it's not just share, it's all the Essemtials-related docs, not just share. 

docs.microsoft.com

Almost every page cites the master branch of github in the API Source code at the end.

I wish I could say that the "main" branch is fine, but the "master" is the master It's not a counterpart to a slave like /slave, so I think it's fine as is. It's not impossible. But if you're going to imagine master/slave from master, then changing it is a good idea.

If you're going to imagine master/slave from master, I'd change it (I'm not trying to argue this part, so I won't pursue it).

But in my opinion, the "original" branch, back-translated from the Japanese translation above, feels better than the "main" branch.

Then there's the "base" branch and so on.

Xamarin Forms の ListView でコンテキストサイズを変更しても行の高さが更新されない

[EN]

Xamarin Forms ListView Row Height Does Not Update When Changing Context Size

I've been having trouble creating iOS apps in Xamarin. It is.

That's why, in ListView and elsewhere, you can increase the number of characters in each element, and so on, to make the content more interesting by repetition. The problem of keeping the height of the ListView rows the same when the height is dynamic is.
This only occurs on iOS and the same XAML definition, and the same code, but on Android. This does not happen.

The problem is that when displaying a list with different content heights in a ListView, the This is confused with the issue of not being height per content. This problem can be solved on iOS by setting it to true with the HasUnevenRows property. 

docs.microsoft.com But the problem is when each element seems to change after it's displayed. As far back as 2015 or so, we've been asking questions in stackoverflow and Xamarin's It existed as a GitHub issue. The following is a clear description of the issue.

github.com

A valid method of targeting that we are currently able to see is to add an ItemSource to the ListView's The idea is to execute the following two lines when the binding element is changed (on iOS, the Only!) 

            if (this.Parent is ListView list)
            {
                list.HasUnevenRows = !list.HasUnevenRows;
                list.HasUnevenRows = !list.HasUnevenRows;
            }

However, if you use this method, when you change the HasUnevenRows property and revert back to The entire ListView is flickering.

However, there is a bit of hope for solving this problem.

You can find this as a "To do-High impact" on GitHub at Xamarin.Forms The issue was posted 5 days ago on. 

github.com

github.com

 I hope this will help you work things out.

[JP]

Xamarin Forms の ListView でコンテキストサイズを変更しても行の高さが更新されない

Xamarin.FormsでiOSアプリを作成しているときにずっと困っていることがあります。

それが、ListViewなどで、各要素の文字数を増やすなどして折返しによりコンテンツの高さがダイナミックに変わるようなときにListViewの行の高さが変わらないという問題です。

これは、iOSでのみ発生して同じXAML定義、そして同じコードでもAndroidでは発生しません。

この問題は、異なるコンテンツの高さをもったリストをListViewで表示したときにコンテンツごとの高さにならないという問題と混同されます。この問題はHasUnevenRowsプロパティとtrueにすればiOSでも解決します。

docs.microsoft.com

しかし、問題は表示した後に各要素が変化するようなときです。古くは2015年くらいからstackoverflowでの質問やXamarinのGitHubのissueとして存在しました。その中で、問題の説明がわかりやすいものが次のものです。

github.com

現在確認できている有効な対象方法は、ListViewのItemSourceにBindingしている要素に変更があったときに次の２行を実行することです(iOSのときだけ！)

            if (this.Parent is ListView list)
            {
                list.HasUnevenRows = !list.HasUnevenRows;
                list.HasUnevenRows = !list.HasUnevenRows;
            }

しかしこの方法を採用した場合、HasUnevenRowsプロパティを変更して戻すときにListView全体がちらついてしまいます。

しかし、この問題の解決に少しだけ希望があります。

Xamarin.FormsのGitHubで「To do-High impact」としてこの問題が5日前に掲載されました。

github.com

github.com

これで解決に向かってくれるといいですね。

iOSアプリビルド用のプロビジョニングプロファイル（Provisioning Profile）が設定できなかった件

iOSアプリを作成するときに、開発用証明書、配布用証明書に加えて、アプリごとのプロビジョニングファイルを開発環境のMacOS上に登録しなければなりません。

それぞれのファイルはダウンロードしてダブルクリックすれば所定のアプリに連携されて、キーチェーンストアに登録されていきます。

それぞれ１年という期限もあるので、毎年同じ時期にApple Developerのサイトで再作成してダウンロードしなければなりません。

ちょうど６月が更新タイミングだったので（いつも手順を忘れかけたころにやってくる）作業していたのですが、どうしてもプロビジョニングファイルだけが登録されません。

プロビジョニングファイルはXcodeが登録を担うので、Xcodeを入れなおしたり、手動で登録しようとしたりしましたが、上手くいきません。

サイトを調べてみてもプロビジョニングファイルをダブルクリックすれば、キーチェーンストアに登録されるという簡単仕様である以上の情報はなかなか見つかりませんでした。

もう、ダメで元々と、プロビジョニングファイルを作り直そうかとしていたときに気づきました。

なんど、Certficatesに「Xcode11以上」という選択肢があるではありませんか。

急いで、そちらに変更してセーブしてダウンロードしてダブルクリックしたところ、無事に登録されて、また、Visual Studio for Macでビルドができるようになりました。

Xamarin.Androidで必要なXamarin.Android.Supportライブラリが大幅に少なくなった件

起

事の発端は、Xamarin.Forms 4.4だったXamarin.AndroidなプロジェクトをXamarin.Forms 4.6に上げたときにエラーが発生したことでした。

なお、Xamarin.iOSなプロジェクトはすんなりとXamarin.Forms 4.6にビルドエラーなく移行できておりましたので、本当になぞで２日ほど（途中、ACE COMBAT 7やWorld of Warshipなどをやりながら）かかりっきりでした。

承

そもそもとして、Xamarin.Forms 4.4まではTargetFrameworkとしてAndroid 8.1が指定できましたが、Xamarin.Forms 4.5以降ではTargetFrameworkの最小値がAndroid 9.0に変更になっていたため、もろもろの関係でしばらく上げられずにいたのですが、準備が整ったのでXamarin.Forms 4.6にnugetでさっと上げてみたのです。

するのなんということでしょう。さらに多くのライブラリを入れる必要を示唆されるではありませんか。

でも必要だっていうのだから仕方がありませんね。[OK]を押して追加しましょう。

GItの機能を使って修正前の状態に何度も戻しながら試しました。

しかし。

クリーンしてからリビルドしてもビル度エラーは取れません。

Visual Studioを終了して、プロジェクト配下のbinフォルダとobjフォルダを削除してプロジェクトを再度開いてビルドしてもビル度エラーは取れません。

これは、TargetFrameworkをAndroid 9.0（ビルドエラー調査の途中で4.4のまま9.0にする分にはビルドエラーにならないことは発見）にするだけで、Xamarin.Formsは一生4.4で生きていくしかないのかとあきらめかけました。

転

しかしそんなとき、滝沢先生の「お前ら4.4か！4.4な人間なのか！いつ何をやるのもいい加減にして、一生4.4のまんま終わるのか！それでいいのか！お前らそれでも男か！悔しくないのか！」と叱咤される声が脳裏に響きました。

「くやしいです！」「よーし！何がんでも4.6にしてやるぞ！」「でもどうしたらいいだ」

そうだ、初心だ！。私たちにはVisual Studioの新規プロジェクト作成のテンプレートがあるじゃないか！

しかし、ここで問題が発生しました。Xamarin.Formsプロジェクトは共有プロジェクトとしてXamarin.iOSプロジェクトとXamarin.Androidプロジェクトから共有したかったのですが、Visual Studio 2019の新規プロジェクト作成では、以前はあったPCLプロジェクトか共有プロジェクトかの選択チェックボックスがありません。

しかたがなしにこのまま進めると、Xamarin.Forms部分はPCLではなく.NET Standard 2.0プロジェクトとしてソリューションが作られます。

しかし、希望もありました。明らかにXamarin.Android.Support関連のライブラリが少ないのです。でも、油断は禁物です。もしかしたら、共有プロジェクトではないからそうなっているのかもしれません。

結

Xamarin.Formsなテンプレートではなく、Xamarin.Androidなテンプレートで作成し、後から共有プロジェクトとしてXamarin.Formsプロジェクトを確認してみましょう。

するとどうでしょう。あれだけあったXamarin.Android.Support関係のライブラリがたった２つだけになってしまったではありませんか。

Xamarin.Formsをいれても、たったの３つ。

最初、Xamarin.Forms 4.6に上げたときに要求された追加のライブラリも必要ありません。 

もちろん、デザインによっては追加でnugetするものも増えるかもしれません。

しかし、Xamarin.Formsを使ってそれなりのデザインを作っていた元のソリューションに移植してみて実機動作を確認してみても、この３つだけで、きちんと実機で動作確認ができました。

意図せずnugetで取得必要なライブラリの整理もできて（つまり実行モジュールサイズが小さくなって）無事に意図したXamarin.Forms 4.6化も完了しました。

やはり、時々はミニマムサンプルで最新のお作法を振り返ってみる必要がありますね。

追記：

なお、重要なのは新しく作ったXamarin.Androidプロジェクトのcsprojファイルの内容を使うことになります。つまり、（既存と同名で別フォルダに）新しいXamarin.Androidプロジェクトを作成して、既存のXamarin.Androidプロジェクトから要素をコピーして新しい状態をつくり保存したら、csprojファイルを既存のプロジェクトフォルダの方の同名ファイルに上書き保存することです。