> ターゲットフームで違いがあるとは知りませんでした。
下記も参考にしてみてください。
.NET Framework から移行する場合の、API の非互換性についてまとめられています。
https://learn.microsoft.com/ja-jp/dotnet/core/compatibility/fx-core

今見てみると、この資料の最初の項目が今回の UseShellExecute の件ですね…！


> 共有ディスクに保存したファイルをアプリで管理できるような仕組みを考えおります。
共有ディスクに管理しているのであれば、
>>> c:\users\ownerではなく、UNC パスなどで記録されるはずでは……?

それと、OpenFileDialog からだと指定する方法をそのまま用いた場合、
そのままだとリムーバブルメディア（CD-ROM や USB メモリーなどのパス）が
記録されてしまうといった懸念もあります。

とはいえ、LocalDB によるスタンドアロン構成のアプリなどであれば、たとえば先のように
c:\users\owner\ なローカルのフルパスを記録する形式を用いることもあるので、
どういう管理方法をとるのかはケースバイケースであるとはいえます。

しかし一般的なデータベースで記録する場合、特定の PC に依存した情報で記録すると
他環境からの接続に対しての移植性が失われます。可能であれば、複数のクライアントから
接続可能なデータ設計をあらかじめ検討しておいた方が良いでしょう。


> 一般的にはデータサーバーにファイルをコピー、
> そのパスをデータベースに保存、読み出しのイメージですか？
ファイルの保存先が Windows Server なら「データ重複除去」の恩恵も得られますので、
クライアント ローカルで保持するよりは、ちゃんとした「サーバー」にファイルを集約した方が良いと思います。
（こうした重複除去機能をもったファイルシステムは、Windows 以外にもあります)
https://learn.microsoft.com/ja-jp/windows-server/storage/data-deduplication/overview


とはいえ、そのためにデータベース サーバーにファイルをコピーするのが一般的かというと、
必ずしもそうとは限らないです。

もちろん、データベース ローカルに持たせておくのも選択肢の一つではありますが、
パス情報ではなく「ファイルのバイナリそのものをデータベース上に保存する」方式が使われたり、
他にも「データベース サーバー以外の共有保存先」に集約するという選択肢もあるでしょう。

バイナリ保存の場合、たとえば SQL Server であれば、VARBINARY(MAX) FILESTREAM や LOB を使うことができます。
この場合、先ほど書いた「リムーバブル メディアの情報」であっても、問題なく保持することができますし、
ファイルシステムとデータベースの情報が不一致になることがなく、データの一元管理ができます。
その分、データベースのストレージ消費は増えるのでバックアップ計画は考慮する必要がありますし、
そのファイルを保存/取り出すための仕組みを構築する必要はありますけれどね。

データベースサーバー以外に補完する場合、たとえば AD 構成があれば、
DFS (分散ファイルシステム)を併用するのも良いでしょう。これならば、
自分自身に保存しようと他のサーバーに保存しようと、あるいは複数台で保存したとしても、
また、保存先のサーバーが変更になったとしても、UNC パスを変更させる必要がありません。

そうした DFS が使えないような場合は、フルパスを指定する方式の代わりに、
「(基準ディレクトリからの)相対パス」で管理する手法がしばしば取られます。
この場合の基準ディレクトリとは、NAS 上のパスでも構いません。

あるいはファイルをクラウドストレージに保存し、データベースはそのアドレスを保持するとか。

処理系によっては Database FileSystem といった、ファイル管理用の仕組みを持っているケースもありますね。